On 1/20/2015 5:54 PM, Anne Bennett wrote:
Franck Martin <fra...@peachymango.org> writes:
Yes, RFC7208 says evaluate both in parallel, but the result
of an spf=pass/fail is highly constrained on the success or
failure of the MAIL FROM spf test.
Actually, it recommends checking the HELO identity first,
because if you get a definite result from that, you may not
have to evaluate the MAIL FROM identity at all.
However, in practice, optimized receivers will wait for a valid local
RCPT TO (Forward-path) address before exerting any potentially, high
overhead, wasteful DNS application queries.
For remote RCPT TO address, this generally requires
authentication/authorization to relay mail. Under the SUBMIT protocol,
HELO/EHLO can be enforced. Our package does not enforce it (it was
relaxed) for PORT 587 operations because AUTH is required anyway and
in the SOHO market, with NATs around, it was not always possible to
put a proper machine client host name for the EHLO/HELO field or the
Domain IP Literal was incorrect (did not match the connection ip).
But for public port 25 operations, there is a high payoff to wait. We
realized a 60% savings in DNS lookups because 60% of the RCPT TO were
invalid! SMTP RFC5321 even provides insight into using delay strategies:
SMTP Section 3.3 Mail Transactions
.....
Despite the apparent scope of this requirement, there are
circumstances in which the acceptability of the reverse-path may
not be determined until one or more forward-paths (in RCPT
commands) can be examined. In those cases, the server MAY
reasonably accept the reverse-path (with a 250 reply) and then
report problems after the forward-paths are received and
examined. Normally, failures produce 550 or 553 replies.
Overall, all specs are just guidelines. You don't have to follow them
exactly where it doesn't make sense. A RECOMMEND is functionally
equivalent to a SHOULD, it is not a MUST.
As long as the end result is the same, we should be generally ok so we
are basically talking about optimization concepts.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
