This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SPF rejection on forwarded email

I have an SPF rejection on an email from a domain with correctly-configured SPF (compsource.com).

 

Compsource.com sends the email to yahoo.com, which arrives at Yahoo and passes SPF checks at yahoo:

X-Apparently-To: adam_g@yahoo.com; Fri, 23 Jun 2017 20:53:32 +0000
Return-Path: <orders@compsource.com> Received-SPF: pass (domain of compsource.com designates 207.170.170.10 as permitted sender) X-Originating-IP: [207.170.170.10] Authentication-Results: mta1658.mail.gq1.yahoo.com from=compsource.com; domainkeys=neutral (no sig); from=compsource.com; dkim=neutral (no sig)

The way I read this is that 207.170.170.10 connected to yahoo.com with EHLO compsource.com, and send an email to adam_g@yahoo.com with a from address of orders@compsource.com.  Yahoo looked up the SPF records for compsource.com, which indicates that 207.170.170.10 is a permitted sender.

I have my yahoo account set to forward received emails to me at an email address for which the MX record points at my UTM.

The UTM mail log has this:

 

Jun 23 16:38:29 192.168.55.55 2017: 06:23-16:38:29 goldberghome exim-in[32075]: 2017-06-23 16:38:29 [74.6.135.148] F=<sales@compsource.com> R=<adam@agp-llc.com> Verifying recipient address with callout
Jun 23 16:38:30 192.168.55.55 2017: 06:23-16:38:30 goldberghome exim-in[32075]: 2017-06-23 16:38:30 id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="74.6.135.148" from="sales@compsource.com" to="adam@agp-llc.com" size="-1" reason="spf" extra="SPF check failed"
Jun 23 16:38:30 192.168.55.55 2017: 06:23-16:38:30 goldberghome exim-in[32075]: 2017-06-23 16:38:30 H=sonic326-22.consmr.mail.bf2.yahoo.com [74.6.135.148]:34118 F=<sales@compsource.com> rejected RCPT <adam@agp-llc.com>: 74.6.135.148 is not allowed to send mail from compsource.com
Jun 23 16:53:33 192.168.55.55 2017: 06:23-16:53:33 goldberghome exim-in[1234]: 2017-06-23 16:53:33 [74.6.129.45] F=<orders@compsource.com> R=<adam@agp-llc.com> Verifying recipient address with callout
Jun 23 16:53:33 192.168.55.55 2017: 06:23-16:53:33 goldberghome exim-in[1234]: 2017-06-23 16:53:33 id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="74.6.129.45" from="orders@compsource.com" to="adam@agp-llc.com" size="-1" reason="spf" extra="SPF check failed"
Jun 23 16:53:33 192.168.55.55 2017: 06:23-16:53:33 goldberghome exim-in[1234]: 2017-06-23 16:53:33 H=sonic301-6.consmr.mail.bf2.yahoo.com [74.6.129.45]:46683 F=<orders@compsource.com> rejected RCPT <adam@agp-llc.com>: 74.6.129.45 is not allowed to send mail from compsource.com

The way I read this is that the UTM received the forwarded email... yahoo.com connected to goldberghome from 76.6.136.148, and attempted to send an email to me from compsource.com, and because compsource.com's SPF records don't indicate that 76.6.136.148 (Yahoo's IP address), it rejects the email.

Is this the correct behavior?   That's kind of confusing, since I haven't noticed this before and I've had my email configured this way for ~7 years.



This thread was automatically locked due to age.
Parents
  • This is exactly how SPF is designed.  The only thing UTM knows for certain is the identify of the server to which it is talking.   Forwarding headers could be true or could be fraudulent.   Yahoo is not authorized to send on behalf of compusource, so the mail is assumed to be fraud.   Every SPF implementation will block forwarded mail.

Reply
  • This is exactly how SPF is designed.  The only thing UTM knows for certain is the identify of the server to which it is talking.   Forwarding headers could be true or could be fraudulent.   Yahoo is not authorized to send on behalf of compusource, so the mail is assumed to be fraud.   Every SPF implementation will block forwarded mail.

Children
  • There is a mechanism caed SRS (Sender rewriting Service) which a,forwarding server can take responsibility for the email to make SPF checks pass at the receiving server.   Probably not something that yahoo wants to support, as it only increase the risks to its reputation

    DKIM attempts to solve this problem by using a signature which should survive the forwarding process.