On Tuesday, January 20, 2015 22:55:58 Terry Zink wrote: > >7208 actually recommends that the HELO string be evaluated every time. > > > > http://trac.tools.ietf.org/html/rfc7208#section-2.3 > > They do say to check it both times but I don't agree with the rationale > provided. Expanding on the excerpt that Laura provided: > > 2.3. The "HELO" Identity > > It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" > identity but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > <sender>. Checking "HELO" promotes consistency of results and can > reduce DNS resource usage. > > [tzink] How does this reduce DNS resource usage? Aren't we now checking two > domains instead of one?
Note: This point was actively discussed during the SPFbis working group. HELO records are virtually always very simple: zero or one additional DNS lookup. If you get a fail result and choose to reject as a result, you never have to even retrieve the Mail From record, let alone do all the lookups triggered by the terms in the record. This is for SPF on it's own and not particularly relevant if you want to feed SPF results into DMARC. > If a conclusive determination about the > message can be made based on a check of "HELO", then the use of DNS > resources to process the typically more complex "MAIL FROM" can be > avoided. > > [tzink] Disagree here, especially the case of shared hosting environment > like Office 365. Customers relay spam through us and sometimes that spam > will fail SPF checks. Yet, if you checked the SPF record on the HELO string > (e.g., na01-bn1-obe.outbound.protection.outlook.com), that would pass an > SPF check every time whereas the @paypal.com in the MAIL FROM would fail > SPF. Seems like you can only be sure you can trust the HELO when you are > sure the sender locks down the outbound mail infrastructure, and that is > not the case everywhere. Agree. The only definitive result you can get from SPF HELO checks is reject. It'll never tell you something is good. > Additionally, since SPF records published for "HELO" > identities refer to a single host, when available, they are a very > reliable source of host authorization status. Checking "HELO" before > "MAIL FROM" is the RECOMMENDED sequence if both are checked. > > [tzink] They are for a single host but not necessarily for a single > organization or even a series of organizations with the same set of > policies. It seems like this RFC does not have a mult-tenant hosted > environment in mind, and that is becoming more common. It doesn't matter. The HELO name is (should be) particular to that host so it works regardless. Recall that for SPF there's no notion of alignment so there's no requirement that the HELO name have anything to do with any other identity in the message. To read RFC 7208 as intended, you have to forget DMARC exists. It was written to stand alone. It's up to DMARC to explain how it wants to be built on top of SPF. Scott K > -- Terry > > > 7208 actually recommends that the HELO string be evaluated every time. > > http://trac.tools.ietf.org/html/rfc7208#section-2.3 > > > > "2.3. The "HELO" Identity > > > > It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" > > identity but also separately check the "HELO" identity by applying > > the check_host() function (Section 4) to the "HELO" identity as the > > > > <sender>. Checking "HELO" promotes consistency of results and can > > reduce DNS resource usage." > > > > laura > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
