--Harry Katz <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:
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?
Er, with respect, that suggests you haven't tried very hard.
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:
It's a bit disingenuous to suggest that 2821 MAIL FROM has problems with
forwarding, while 2822 From:/Sender: do not. Of course they have different
solutions, SRS/VERP vs. adding acceptable headers. You say potayto, I say
potahto.
Also, there are other ways to handle forwards besides SRS/VERP. Check out
the SPF FAQ, it should be there... I seem to recall there are at least two
others. In particular, you may not want the returns to go back to the
original author (such as this list).
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.
In that case, here is an easy one: altavista.com. It sends NO mail, so
therefore it is safe to block ALL mail claiming that MAIL FROM without
examining any headers.
Here is another one: Anyone who is interested in MS-CID's directOnly
feature would probably also want receivers to drop mail not coming from a
specified IP. Does directOnly have a valid reason for existing? Could you
not then concede that some domains will want strict 2821 checking also?
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.
That's the spirit! Hopefully I am not alone in rising to the challenge.
If you get a satisfactory response, does that mean you will hop to it
eagerly when MS-CID and its ilk are challenged?
However, just because someone can't prove to YOUR satisfaction that 1. MAIL
FROM is important, and 2. bandwidth savings is the primary reason, and MAIL
FROM is not useful without bandwidth savings, that doesn't mean we should
drop it from consideration. In other words, if a fellow team member SAYS
it's important to him, I will take him at his word, I probably won't need
to challenge them to a duel if I disagree.
For me, bandwidth savings is actually not the #1 or even #2 reason for
insisting on MAIL FROM validation. My #1 reason is that I don't want to
receive bounces from crap I didn't send.
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>