Ah, I have got the idea. However, you might want to consider to discuss
in your draft:
(1) Section 1 is confusing since it is about "Forged Headers".
(2) How serious is the problem of "Sender Address" compared to
the "Forged Headers"?
These are the same problem. "Forged headers" (okay, I admit it might
be clearer to say "forged sender addresses") refer to the sender creating
invalid data, not someone in the middle changing valid data to invalid
data. (dictionary.com, from Webster's: forge, v.t. [...] 4. To make
falsely; to produce, as that which is untrue or not genuine; to fabricate;
to counterfit, as, a signature, or a signed document.)
(3) Why use a complicated cryptographic challenge mechanism? AFAIK, it is
quiet common for a current receiving MTA to reject emails that come
from a host with no reverse "in-addr.arpa" information.
Some valid MTAs (achurch.org, for example) don't have reverse DNS
mappings, and I already have enough trouble with over-paranoid mail system
why not use the MS RR to list the MTAs who are allowed to use the
sender address of the domain?
I think I went over this once, but this was the approach I took in
earlier versions, and I rejected it because the administrative burden
becomes significant with dynamic IP addresses and other cases in which
the IP address of an allowed MTA can change.