As I understand it, the proponents of basing MTA validation on RFC2821 MAIL
FROM believe the main benefit of this approach is that it saves bandwidth.
Specifically, a check of RFC2821 MAIL FROM is believed to allow rejection of
messages before the content is transmitted.
I've been trying to identify the conditions when this is actually possible.
Specifically, when can you reject a message based *only* on a check of RFC2821
MAIL FROM?
Thus far I've come up with exactly zero cases where RFC2821 MAIL FROM by itself
can be used to reject mail.
So I'm asking for your help. When, if ever, can this be done?
Under the current schemes, as I understand them, a validation of RFC2821 MAIL
FROM that fails *cannot* be used to reject messages because there is a high
probability of a false positive, i.e. an erroneous rejection. To whit:
- the sender could be a forwarder who has not implemented SRS or VERP.
- the sender could be a student connected to a college campus network sending
mail from a POP or IMAP client using their ISP's email address.
- the sender could be a salesperson with a Blackberry sending mail over a
carrier's network using their corporate email address.
So, I would like to propose a challenge to the MAIL FROM advocates:
Come up with a scheme or set of conditions that enables receivers to correctly
reject messages based solely on RFC2821 MAIL FROM. This scheme must work in
the face of forwarders who have not implemented SRS, VERP or any similar
mechanisms since they are likely to represent the majority of forwarders for
the foreseeable future and will remain present on the Internet indefinitely.
And just so we don't go into an infinite loop on this, let's set a deadline,
say midnight Pacific time, Friday, April 30, for finding such a scheme.
It would be fantastic if we could reject tons of spoofed mail at MAIL FROM. My
colleagues at Hotmail would be delighted, as would Exchange enterprise
customers. If we can identify such a scheme or set of conditions or whatever,
then I truly believe it will be possible to craft a single validation scheme
that leverages the best of both the RFC2821 and RFC2822 approaches and I will
happily throw my energies into developing a converged algorithm.
If we cannot identify any such scheme or set of conditions, then let's admit
there are unfortunately no bandwidth savings to be had and let's drop RFC2821
MAIL FROM from the list of candidate identities.