On Tue, 2004-09-14 at 13:27, Alan DeKok wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
You describe that as authenticating the MTA, but what this operation is
doing is validating the MTA as authorized to send a message containing
the MAIL FROM.
<sigh> The recipient (SMTP server) is authorizing the MTA (SMTP
client) as an MTA authentically within the domain named in MAIL FROM.
From the Latin authenticus- coming from the real author, of original or
first-hand authority. It would be a mistake to apply this term to a
second-hand authority, as is the case with SPF or Sender-ID. It would
be safer not to describe the real author (the mailbox domain at least)
as authenticated. Rather, this mailbox domain has authorized
second-hand parties to act on their behalf and claim this authorization
has been validated.
There are two things needed as independent steps. One, authenticate the
name of the MTA to allow safe reputation assertions.
And that's where I disagree. For me, the point of MAIL FROM
authentication is not about reputation assertions, it's about the
ability of the domain named in MAIL FROM to control the use of it's
name.
e.g. example.com & example.org share an outgoing MTA:
out.example.com. In SMTP conversations, it announces itself as "EHLO
out.example.com". It may then say "MAIL FROM: user(_at_)example(_dot_)org".
Nothing in SMTP today permits the recipient to determine if
"out.example.com" is a valid outgoing MTA for example.org. My goal in
this area is to provide a way to make that determination. Stopping
spam, and reputation services, are interesting, but not something I
find to be practical.
If the EHLO name had been authenticated and the authorization validated,
as possible with CSV, then to assert which MTAs are authorized to send
mail on behalf of a mailbox domain only requires a very simple list of
PTR records. This list can be obtained from a single DNS query and not
require any subsequent lookups to ascertain related addresses. The
addresses will have already been checked by the "no-added overhead" CSV
operation.
i.e. If MAIL FROM authentication records in DNS stop other people
using my name in vain, that's great. I don't care how other people
restrict (or not) the user of their names: that's up to them. For me,
the issue isn't that authentication will stop other people from
spamming me, it's that it will stop other people from claiming that
I'm spamming them.
From an overhead standpoint, this goal of stopping spoofed mail is
better done using two steps. One is CSV, and the other is MPR. CSV
does not add to the DNS overhead at all. MPR only requires a highly
deterministic single query to obtain authorization lists and the level
of the assertions. This has the added advantage of not providing a spam
exploit where these authorization list are claimed to offer (bogus)
"authentication" of the MTA.
But neither SPF nor Sender-ID properly identify the MTA.
For some meaning of the word "properly".
It is not proper to claim an MTA, authorized to send messages with
my-small-business mailbox domain, is the same as being administered by
my-small-business.com. With SPF or Sender-ID, don't suggest
second-party servers for big-isp.com are administered by
my-small-business.com simply because an SPF or Sender-ID record granted
big-isp.com authorization to send messages. To say that SPF or
Sender-ID authenticate big-isp.com as "being" my-small-business.com only
confuses the issue. The risk from this muddled thinking is that these
identities may be employed to unfairly establish reputations.
Blocking by the mailbox domain may unfairly block innocent victims
of spoofing, but blocking by the MTA EHLO name will safely block the
MTA with the problem.
You then label everyone at the MTA with a broad brush. Sure, the
MTA is ultimately responsible, but if a recipient can use "MAIL FROM"
to tell that a subset of domains via that MTA are "bad", then it would
be imprudent to label *all* domains at that MTA "bad", just because
you authenticated the MTA via EHLO.
When the MTA administrator does not revoke access to abusive accounts,
why consider any message from this MTA to be valid? The MTA may be
compromised or not checking SPF or Sender-ID records. To block some
mailbox domain coming from a suspect MTA will also block this mailbox
domain from all other MTAs. When the problem was with the MTA in
question, blocking the mailbox domain currently being spoofed will only
cause great harm to that domain and not stop the problem, as the abuser
will simply spoof the next mailbox domain (victim).
The reputation service is unable to determine what is being checked at
the MTA. The reputation service does not know the source of the message
as you wish to imply. The reputation service would be making a grievous
error assuming the MTA was being properly administered and the mailbox
domain was actually the source of the message. Again, the mailbox
domain was not authenticated as you imply.
-Doug