ietf-mxcomp
[Top] [All Lists]

Re: Does marid-submitter-02 really make sense?

2004-08-09 23:21:18

At 10:11 AM 8/5/2004 -0700, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:

Does the SUBMITTER parameter really make sense?

Case 1: The sender is authorized by some domain to
send messages. The message will have to be accepted and therefore
to be transmitted. No benefit in checking the parameter before
transmission. Could do this also after transmission.

Maybe, maybe not. Having the information early might in some MTAs allow for
throughput optimizations.

Some other correspondents (thank you Margaret!) have clarified that the 
optimization here is in being able to begin an accreditation/reputation check 
earlier.  But even without Submitter it should be possible to begin this check 
as soon as the last header is received.  This seems like a rather small 
optimization.


Case 2: The sender is not authorized or does not want
to reveal her identity (e.g. spammer). Sender would be stupid
if she gave a SUBMITTER parameter not covering her IP address.
So the sender will certainly do as if she had not yet implemented the
SUBMITTER, i.e. omit it. Message will be transmitted as well.

You're missing cases 3 and 4:

Case 3: The sender should be authorized by some domain but for whatever
reason is not. This extension allows this condition to be detected early
and may avoid transfer of a large message.

Again, I think that the savings are small:  this is presumably an isolated case 
(an "honest mistake", not a bulk mailing) so this would not happen very often.  
Even if the bits need to be transferred, the recipient need not store them once 
a decision has been made not to accept the message.


Case 4: The sender should not be authorized and uses SUBMITTER anyway.
(Even if you assume spammers never do this directly, which may or may
not be true, there are cases where mail is forced through intermediaries
that might not be prepared to do a validation check but would be able to add a
SUBMITTER field.) This again transfer of the message body to be avoided.
This is clearly a corner case, but it needs to be on the
list.

There are actually two cases here:

4a:  The sender should not be authorized and uses SUBMITTER with an address 
that corresponds to the PRA.  Savings do result, but I would not expect bulk 
mailers to do this.

4b:  The sender should not be authorized but uses SUBMITTER with an authorized 
address.  A spammer might do this in order to make sure that, if the message is 
rejected, the recipient has to do as much work as possible to reject it, or 
might not go to the trouble of verifying SUBMITTER against the PRA.  This is a 
reason that, IMO, any SMTP server which implements submitter, MUST verify it 
against the PRA (not "SHOULD" as in section 4.2 of the current draft).

I consider the optimizations provided by Submitter to not be worth the 
additional complexity it introduces.  This is particularly true when there is 
discussion about making it mandatory at some point (not really a "service 
extension" any more but a change to SMTP itself).  At that point not only MTAs 
but also firewalls (which often allow only specific ESMTP options, since others 
are considered "dangerous") will need to change to accommodate this.

-Jim