First, some comments:
Alas, due to the way ESMTP extensions work, there is no way to know if
the client supports the extension unless it uses it. For one reasons
I'm not aware of, the current state of the draft allows four states:
The client doesn't understand SUBMITTER
1) there is no SUBMITTER=
The client does understand SUBMITTER and:
PRA == MAIL FROM and
2) the client leaves SUBMITTER= off
or 3) the client includes SUBMITTER= anyway
PRA != MAIL FROM
4) the client includes SUBMITTER=
Alas, there is no way to distinguish state 1 from 2.
I was about to point this out... Thanks for doing the analysis.
Sure, things
would be tighter if we disallow state 2. I'm not sure this is a big
deal. If you leave state 2 in, then many environments where PRA always
equals MAIL FROM needn't change any software and can claim compliance.
Of course, I'm not sure there are really any such domains.
Mailings lists are pretty common.
I also tend to agree that any language about what might happen if we
require SUBMITTER in the future should be left out of the draft unless
we actually agree on what will happen, and when we will do it.
Second, In the language of pseudo-code, Here are is what I think
combined Sender-ID and SUBMITTER requires an MTA to do:
accept body of message
extract PRA from headers
if the client supplied SUBMITTER= {
if SUBMITTER != PRA { exit with fail }
}
r0 = check PRA against the Sender-ID record
exit with r0
Of course, this doesn't gain any possible advantage from SUBMITTER.
This is what an aggressive MTA can do:
if client supplies SUBMITTER= {
r1 = check SUBMITTER against its Sender-ID record
if r1 is pass {
if SUBMITTER is on your white-list, or has a high enough reputation
score {
accept body of message
exit with pass, no further checks needed
}
}
else if r1 is fail {
reject mail (still prior to DATA)
exit with fail
}
-- r1 is either unknown or error at this point --
Nit: r1 can also be pass at this point.
accept body of message
extract PRA from headers
if PRA != SUBMITTER { exit with fail }
if PRA == SUBMITTER { exit with r1 }
}
else client supplies just Mail From {
r2 = check MAIL FROM against its Sender-ID record (hoping it will be same
as PRA)
As you note below, this part isn't exactly required, but it does offer the
highest degree of operational overlap.
accept body of message
extract PRA from headers
if PRA == MAIL FROM { exit with r2 }
r3 = check PRA against its Sender-ID record
exit with r3
}
This is more convoluted than the draft requires because it is trying to
stave off as much work as possible. Specifically, if the reputation is
high, or is on a white-list, then the PRA extraction from the headers
can be skipped (as your local mail policy essentially trusts that
domain's machines (as authorized via Sender-ID) to do the right thing.)
This code also tries to get as much going in parallel as possible. Not
only is it getting the SUBMITTER (if present) check going quickly; a
site can speculatively try MAIL FROM (in the absence of SUBMITTER), in
hopes that by the time it gets the headers, the result will be back,
and MAIL FROM will match PRA.
If we change the spec to eliminate state 2 above (where a client that
understands SUBMITTER omits it if PRA == MAIL FROM), then really,
NOTHING in the above code changes. An MTA can't be any more
aggressive.
In summary (did you ever think I'd get to one?):
- I think Meng's interpretation is wrong.
Agreed.
- Removing the ability to omit SUBMITTER if PRA equals MAIL FROM
doesn't really matter
Agreed.
- As defined, this all works to save processing time for a receiver if
it a) the MTA can take advantage of starting Sender-ID checks in
parallel with receiving the DATA, and/or b) the receiving domain has a
white-list or a reputation system it trusts.
Yep.
Ned