(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. "
RFC 2821 does NOT require an MTA to accept an entire message if it is going to
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.
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.)
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.
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.