Splitting this out as a separate topic.
wayne [wayne(_at_)midwestcs(_dot_)com] wrote (in part):
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of wayne
Sent: Sunday, April 11, 2004 6:35 AM
To: IETF MXCOMP
Subject: Re: Microsoft submitting Caller ID as draft RFC
To be sure, the Caller ID mechanism could be used to
validate the 2821
MAIL FROM. In fact we actually had the 2821 MAIL FROM as the first
identity on our list, ahead of the 2822 headers, in early drafts of
Caller ID. In the end we dropped it because it either
added no useful
information that was not already contained in the 2822
headers or led
to incorrect or misleading conclusions from an end user
perspective.
In other words, 2821 MAIL FROM adds nothing useful so why use it?
I am not convinced that the RFC2821 MAIL FROM adds nothing
useful. In particular, I think it is very important for
email reliability to make sure a bounce gets generated to
email that has been rejected.
Silently dropping email that doesn't pass certain tests is,
IMHO, a very big problem.
Rejecting a message at MAIL FROM or at end of DATA are equally effective
mechanisms for ensuring that bounce messages get generated. RFC2821
MAIL FROM offers no advantage in that regard.
Please note I'm not suggesting that performing checks on the RFC2821
MAIL FROM is entirely useless and should be stopped. On the contrary,
there are a number of very useful things that can be done here such as
allow/deny lists, etc. By all means let's continue doing those things
and if we can reject the message with a 4xx or 5xx code at that point,
great!
What I am saying is that for the purposes of this discussion under the
MARID charter, MAIL FROM doesn't add any information not already
available in the 2822 headers. That's why we dropped it from Caller ID.
Thanks.
Harry