On 1/21/2015 10:50 AM, Michael Jack Assels wrote:
On Tue, 20 Jan 2015 16:14:32 CST,
Franck Martin <[email protected]> wrote:
[...]
Your confusion on HELO is may be related to the fact that the
HELO string is only used when the MAIL-FROM: is empty?
There is some text here:
http://trac.tools.ietf.org/html/rfc7208#section-10.1.3
The HELO string is not evaluated all the time, it is more like
a fall back.
It's already been pointed out that
http://trac.tools.ietf.org/html/rfc7208#section-2.3
RECOMMENDs checking the HELO string first; hence our confusion.
Implementators should know this would be a high DNS waste and overhead
suggestion.
The optimized approach is to delay any DNS query applications and
first capture the SMTP process field parameters to determine what
augmented DNS applications apply, what needs be queried and
calculated. For example, SMTP has offered guidance in this area for
delaying the reverse-path (MAIL FROM) processing until the
forward-path (RCPT TO) is known:
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.
HELO/EHLO has historically been known to be incorrect for many
reasons. At best, the receiver can perform a field syntax check
including a required bracketed IP Domain literal check to make sure it
matches the connection IP address before doing anything else and
allowing the next SMTP state to continue.
The reality is that SMTP receivers are not going to know the DMARC
status of an incoming anonymous client until the DATA payload is
received. It doesn't need DMARC information for SPF -ALL rejection
policies. SPF -ALL policy SHOULD be processed immediately before
DATA. But I think DMARC wants you further delay SPF processing until
DATA payload is received (for reporting reasons I suppose).
Since it can be potentially high overhead of getting a payload with no
DMARC information, SPF receivers may not wait until DATA is received
to process SPF.
Incidentally, SENDER-ID [1] resolve this DATA overhead potential
issue with the SUBMITTER optimization [2] where the PRA (Purported
Responsible Address) [3] was passed to the MAIL FROM state:
MAIL FROM:<return-path> SUBMITTER=pra
This tells the SPF processor that the pra DOMAIN is the lookup domain.
DMARC can borrow from such ideas to pass the 5322 Author Domain (DMARC
domain), and better yet even pass the policy as well to help optimized
the receiver:
MAIL FROM:<return-path>[ DMARC=author-domain[ DMARC.P=reject]]
This DMARC ESMTP idea would probably only work if there is a TRUST
that the that payload is DKIM signed correctly using the problem
5322.From address.
--
HLS
[1] https://tools.ietf.org/html/rfc4406
[2] https://tools.ietf.org/html/rfc4405
[3] https://tools.ietf.org/html/rfc4407
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
