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.
I see some potential for optimization. Whether or not it is significant I don't
know - that would only emerge with testing, and I haven't implemented
this yet, let alone tested it.
I note, however, that past experience has been that the potential for
optimization with various SMTP extensions has been underestimated fairly
consistently.
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.
Sure, but you can't stop the body from being transmitted in this case.
A header line will be transmitted
only very few bytes later than a SMTP extension. So not an argument.
I disagree.
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.
I never said it did.
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.
Which is exactly what I said it was.
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.
Again, this remains to be seen.
If this is the only advantage, then it is not a real advantage at
all. Why introduce a protocol extension without a real advantage?
Again, I am personally ambivalent about SUBMITTER. My purpose in responding to
you was to point out that (a) Your case against it really isn't that cut and
dried, and (b) I am strongly opposed to the alternative header scheme you
proposed.
Ned