Most of the problems involve perspective: The people who decide the
value of a trade-off -- that is, _us_ --
Actually the only people who get that choice are the people who write
the filters and the people who insert the records. We don't actually
have all that much influence unless they happen to like our trade offs.
Internet technology has been easy to upgrade when it has paid
very, very careful attention to protection of the installed
base. It has been very difficult to upgrade when that attention
has been insufficient.
The issue is not the level of pain it is where it is felt. Is it going
to be felt by people who are likely to change? Is it going to be
felt by a constituency essential for adoption?
In this case the pain felt by postcard services does not seem very important
to me since they are not a constituency that is critical to the success
of the spec, the value of the information they send is generally considered
to be very very low and so there is little downside for the receivers. The
postcard services won't be able to exist unless they change, it is easy
for them to do so, therefore they will do it.
In this particular case there is a very easy fix for the postcard sites,
they just use their own name, not a random name that someone entered
into a web form. they should have done that all along.
Fixing other forwarding relationships is a little trickier but not
all that hard.
I think that the layout of the draft should be:
1. Definition of terms
2. Statements of the requirements addressed
3. Semantics of the DNS record entry (Normative)
How to specify the set of outgoing mail server IP addresses
By value (IPv4, IPv6)
By reference (mx record, domain name, address lookup)
Other authentication information
STARTTLS always offered
S/MIME always used
Certificate validation
Other server attributes
Accreditation
Frequent phishing target
4. Hints for filter writers (NON-Normative)
At the gateway MTA
Verifying HELO
Verifying RFC 821 From
Implications of forwarding services
At other points
MUA considerations
MTA considerations
Verifying RFC 822 From, Sender, Reply-to
Implications of forwarding services
5. Hints for writers of mail services (NON-Normative)
How to send postcards that get through every time
How to forward email and get through every time
6. Security Considerations
Email address spoofing
IP spoofing (unlikely)
DNS spoofing (preventable)
DNS security issues
7. Acknowledgements
8. References
Phill