Greg Connor <gconnor(_at_)nekodojo(_dot_)org> wrote:
OK, some folks may see this as a weakness, but I see it as a strength. By
that I mean specifically that I want to protect my domain name when it is
used in MAIL FROM (to send me bounced-forged mail) AND when used in From:
or its relatives (to impersonate me and earn me negative replies from real
people). AND, I feel strongly that I should be using the same mechanism to
do it, rather than setting a 2821 and 2822 policy two different ways.
Also, to be clear: the MAIL FROM and From: fields comprise
identities which can be deconstructed into two portions. The portions
are mailbox within that domain (username portion), and domain portion.
The method of validating MAIL FROM and From: identities can involve
3 distinct combinations of identities:
1) domain only
2) username only
3) username(_at_)domain
The first involves validating that a domain accepts accountability
for a message. The second is meaningless outside of the domain
context, and the third involves validating that users exist at a
domain, which has privacy issues.
Note also that concentrating on validating the domain portion only
means that the method is dealing with essentially only MTA's (~10^5
world-wide), versus users (~10^8 world-wide). That helps
significantly with scaling.
1. Single domain, single policy
I want to protect my domain.
I use the domain as a 2821 return path and 2822 From: address.
My MTAs will be the same in 2821 and 2822 context.
I publish the LMAP info, and it can be used in either context.
I imagine there's a lot of these. e.g. My vanity domains. Those
names can't be used in MAIL FROM, EHLO, or From: without my personal
consent, meaning that pretty much only one IP will ever send traffic
using those names in those fields of SMTP. I should be able to
express this policy.
If you really want to force the receiver to use 2821 and not 2822 checking,
or vice versa, I think you could accomplish that by using two different
domains.
As is the case with mailing list.
MAIL FROM checking is important so that I don't get bounces from mail I
didn't actually send.
See a recent post to ASRG, where I quoted a local University
administrator, who's getting 10^6 bounces a day. That's a significant
cost, and can be viewed as an attack on the SMTP infrastructure. With
10^6 bounces a day, *real* bounces can get lost in the noise, making
the whole bounce system useless.
Alan DeKok.