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.
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.
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.
So what sense does it make to introduce this new extension? Could have
done the same thing better based on header checks after transmission
of message. An additional header entry is much easier to implement or
configure.
There is absolutely no value and considerable harm in using an additional
header field. The only advantage SUBMITTER has is temporal in nature - it
delivers the information sooner. This is lost with a header that's delivered at
the same time as all the others. And in order to be effective the field has to
be compared with the value derived from other other header fields, so the same
amount of work has to be done in either case.
Even worse, when there's a header present containing this information there are
bound to be lazy implementations that will not perform the check. This opens a
security hole. Of course SUBMITTER has a similar hole, but the liklihood
of someone bothering to implement SUBMITTER and not do the header check
seems a lot smaller than the liklihood of someone just using a header
value without the check.
The only sense I can see is a smooth transition: E.g. allow both -
submitter and header based checks - until Dec-31 2005 and require
everyone to support it by then. But if this is desired, then this is a
completely wrong way.
In such a case the MARID group should not hide the smooth transition
in a SMTP extension. Instead it should mark this all as a "temporary
ad hoc solution to fight spam and crime now", and reengineer a better
solution then.
Yesterday's answers to my question didn't convince me. On the
contrary. It caused doubts whether this is really a well planned
solution or rather a workaround that does not really work around.
Wouldn't it be better to allow a new header entry line instead?
Absolutely not. I don't especially care if SUBMITTER happens or not - I can
implement it and I can live without it. But I'm strongly opposed to a header
equivalent of SUBMITTER.
Ned