ietf-mxcomp
[Top] [All Lists]

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

2004-08-05 11:02:09

On Thu, Aug 05, 2004 at 10:11:33AM -0700, 
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:

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

Really? I don't see significant potential for optimizations. 

And even if you do need this you can rely on the fact that the 
message header is transmitted before the message body. If you want to
optimize nobody keeps you from evaluating the message header before
completion of the message transfer. A header line will be transmitted
only very few bytes later than a SMTP extension. So not an argument.




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.


Not convincing. The main cases will be authorized and unauthorized. 
I doesn't make sense to extend the SMTP protocol just for the case of
misconfiguration. It does not make sense to invent a protocol
extensions with major disadvantes just to prevent some bytes of
transmission in case of misconfiguration.









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.



I don't see that there will be a significant number of idiots sending
messages while they know that the receiver is MARID aware and will
discard the message anyway if they could do better without SUBMITTER.
Even a spammer has to pay money and time for transmission. If a
spammer sees a MARID aware MTA and knows that the message will be
discarded it is logical to go to the next victim instead of wasting
time and money. So this is not a relevant case.







The only advantage SUBMITTER has is temporal in nature - it
delivers the information sooner.


Not significantly sooner than a header line. Nobody forces you to wait
for completion of transmission before to look at the header. 

If this is the only advantage, then it is not a real advantage at
all. Why introduce a protocol extension without a real advantage?




Hadmut