On Thu, 26 May 2005, Terry Fielder wrote:
The domain names in my EHLOs is completely disjoint from the set in my
MAIL FROM and mail headers. How is SPF going to handle that?
I believe you will find that the EHLO/HELO is only checked if the MAIL FROM
fails.
Why? Doing EHLO check is useful no matter if MAILFROM fails or passes!
And it does not make any sense to delay it until MAILFROM when EHLO is
the first identity parameter email server receives and this identity
that has very few failure cases with SPF (unlike MAILFROM)
Also note that MAILFROM identity corresponds to original recipient
(unless every forwarder starts using SRS and you change its semantics,
but that is unlikely) where as EHLO name corresponds to the mail system.
As John proper said, they are disjoint and should not be mixed.
I think I have heard of other implementations where:
If the EHLO fails, you check the MAIL FROM, and if that passes then it gets
an SPF pass.
Unless I'm mistaken SPF pass is specific per scope/identity checked and
there is no overall SPF pass.
Either way, it doesn't matter if your EHLO fails (it does on many, maybe even
MOST systems), because as long as your MAIL FROM is SPF PASS, then your mails
SPF response on the whole is a PASS, and is not negatively affected.
PS This is from memory, one of the developers are better qualified to answer
this question, if you don't trust my answer, but the generalization is at
least correct, AFAICT.
When it comes time to using the authorization to compare to domain
black/white listing, then the MAIL FROM domain and the EHLO/HELO domain could
be used as a query to the lists.
You should not query different identities on the same reputation service,
I believe that is a possibility for unpredictable and incorrect results
and reputation systems must be setup for each specific identity in question.
----
BTW, for those who do not participate at spf-discuss and don't know -
I'm writing paper on email identities and how they are used in path and
cryptographic authentication methods (i.e LMAP and MASS) for anti-spoofing
protection. This is very much on the topic of what has been discussed here
and on ietf-smtp about good and bad points of each proposal.
You can find the latest public draft at:
http://www.elan.net/~william/emailsecurity/path_and_cryptographic_authentication-draft-limited-07.htm
Comments on the content, especially if I got anything wrong are appreciated.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net