On 4/3/2004 8:03 PM, Gordon Fecyk sent forth electrons to convey:
(As I submit this just one day before the deadline! eek!)
No the 04 is short for 2004 - A chair said " Please note that the dates
listed in the milestones are months of the year not days of the month. "
Confusing, and vague indeed. I hope we don't see that again!
2822 From:
RFC 2821 requires a MTA to receive an entire message if it is going to
receive a message at all. Any verification of this header can occur only
after the MTA receives the message. At the least, bandwidth is still used
should the MTA reject the message based on verifying the From header. At the
most, this breaks routing bounces to special addresses, as many mailing list
applications use.
RFC 2821 does NOT require an MTA to accept an entire message if it is going to
receive a message at all. Sending a failure code in response to the end of
data command does NOT break routing bounces.
A reader could easily, but incorrectly infer otherwise from what you said.
My own experience is those who control the network infrastructure, and thus
control .arpa, are LAZY in identifying components of the infrastructure and
in delegating responsibility for identifying components downstream.
Just a general comment prompted by this. We must be cognizent of the
realities that a large minority (if not a majority) of admins (or their
managers) even if they aren't spammers, are lazy and selfish, and any
solution we agree on must work despite these conditions. (E.g. AOL
publishes SPF records, but they keep posting a 5 year old FAQ to usenet,
and accepting mail they then bounce, and fighting good antispam
legislation.)
We also ask that participants consider and list the following
ramifications regarding deployment issues:
1) Amount of change in software components (MDA, MTA, MUA,
DNS servers, DNS resolvers).
I would add
Amount of change in configurations of these software components by users.