Why marked as spam, although in address book?

[Mugwhamp]

Basically my situation is that I'm required to use a work-related domain by my employer. Up to now, I've been forwarding received work email to my FM account and using a work-related identity for sending from FM's servers. As in the OP's case, some whitelisted email is being directed to my Junk folder. I mostly use FM's web interface and the iOS app.

What I'm confused about is whether, for the purposes of spam protection and whitelisting, it makes more sense to continue forwarding from the work account or to POP from the same. The 5 minute POP interval makes no difference to me. I apologize if this has been answered earlier in the thread, but my layman's reading of responses leads me to believe that it might not have been.

[n5bb]

Originally Posted by Mugwhamp

... What I'm confused about is whether, for the purposes of spam protection and whitelisting, it makes more sense to continue forwarding from the work account or to POP from the same. The 5 minute POP interval makes no difference to me...

I believe that in your case that POP3 retrieval is a better choice.

• If whitelisted mail is filed into your Fastmail junk folder, it probably means that the original sender's domain specified DMARC related DNS records restricting which servers are allowed to send for their domain. This is to prevent someone from spoofing their domain and sending phishing and other spam which improperly appear to come from that domain.
• Your work-related email provider classifies these messages properly if they make use of SPF, DKIM, and/or DMARC. If they are properly sent by the correct server for the sender From domain to your work domain and they pass any DKIM encrypted signing, they are accepted as good messages by your work domain email system.
• But forwarding these messages to your Fastmail account can cause the trust to fail for one or both of these two reasons. If the DMARC policy is violated, Fastmail will not allow addressbook whilelisting, since this looks like a spoofed fake message.
  • The SPF check will fail by default, since the server sending to Fastmail is now not one specified by the domain SPF DNS records. There is a possible fix for this (Sender Rewriting Scheme) in some cases, but DMARC requires alignment of the SMTP MAIL FROM domain with the From header. So forwarding will always cause SPF to fail as used by DMARC.
  • The DKIM encrypted signing can fail if the message headers are altered in certain ways during forwarding. If the message is not improperly altered, messages properly signed with DKIM can pass DMARC after forwarding. So forwarding does not always cause DMARC to fail, but it makes it much more likely.
• POP3 retrieval solves these problems. The message is accepted by Fastmail with the reputation established by your company's email system. Fastmail assumes that those checks I mentioned earlier have probably been done, and only applies the normal spam filter. If the From address is whitelisted, then the spam filter results aren't even used.

Bill

[Mugwhamp]

Originally Posted by n5bb

I believe that in your case that POP3 retrieval is a better choice.

• If whitelisted mail is filed into your Fastmail junk folder, it probably means that the original sender's domain specified DMARC related DNS records restricting which servers are allowed to send for their domain. This is to prevent someone from spoofing their domain and sending phishing and other spam which improperly appear to come from that domain.
• Your work-related email provider classifies these messages properly if they make use of SPF, DKIM, and/or DMARC. If they are properly sent by the correct server for the sender From domain to your work domain and they pass any DKIM encrypted signing, they are accepted as good messages by your work domain email system.
• But forwarding these messages to your Fastmail account can cause the trust to fail for one or both of these two reasons. If the DMARC policy is violated, Fastmail will not allow addressbook whilelisting, since this looks like a spoofed fake message.
  • The SPF check will fail by default, since the server sending to Fastmail is now not one specified by the domain SPF DNS records. There is a possible fix for this (Sender Rewriting Scheme), but it must be correctly used, and isn't always reliable.
  • The DKIM encrypted signing can fail if the message headers are altered in certain ways during forwarding.
• POP3 retrieval solves these problems. The message is accepted by Fastmail with the reputation established by your company's email system. Fastmail assumes that those checks I mentioned earlier have probably been done, and only applies the normal spam filter. If the From address is whitelisted, then the spam filter results aren't even used.

Bill

Fantastic news and information, Bill. Thank you.

[lane]

And to all, see the extensive discussion of these issues in today's advent calendar blog:

https://blog.fastmail.com/2016/12/24/spf-dkim-dmarc/