On Wed, 2004-09-15 at 07:13, Alan DeKok wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
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.
I thought we were discussing security terms, not Latin.
We are discussing the difference between send control lists and
authentication.
Rather, this mailbox domain has authorized second-hand parties to
act on their behalf and claim this authorization has been validated.
No. The domain has published authentication information. The
SMTP server then uses this information to decide if it wants to
authorize the SMTP client.
The domain has not published authentication information, as this
information is often not for hosts within their domain. Should the
domain administrator wish mail forwarding to continue to operate, then
these send control lists must encompass the entire Internet. How can
this list be described as authenticating anything? In this case, it
would authenticate the entire Internet being within a domain! This is
abusing the concept of authentication.
The SMTP server cannot authenticate the client, because it doesn't
know who the client is.
The SMTP server knows the SMTP client has claimed to be the EHLO name.
I would think this would be a good starting point.
The DNS server holding the records obtained by the SMTP server
cannot authorize the SMTP client, because the SMTP client isn't asking
that DNS server for permission to do anything.
The SMTP client is asking to send a message.
Security guards authorize people. Corporate IT authenticates them.
Send control lists authorize SMTP routes without authenticating the
identity permitted traversal. Sender-ID or SPF offer an expensive forms
of routing constraints using address based send control lists. When
1000 identities are authorized to traverse an SMTP route, a transaction
may safely carry identification of any of those authorized, depending
upon the unknown configuration of each MTA or the unknown nature of the
send control list. As there are potentially many send control lists
which apply, even the total number of possible identities remains
unknown. Constraining traversal in no way offers authentication of
identity. None what so ever!
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.
Which is why I never said that.
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?
You're contradicting yourself. Previously in this thread, you were
opposed to labeling people with a "broad brush". Now, you're
claiming it's a good idea.
To refresh this point:
http://www.imc.org/ietf-mxcomp/mail-archive/msg04648.html
|> Shared services means shared accountability. If the recipient is
|> unable to distinguish between a "good" party on a shared MTA and a
|> "bad" party, then by definition, both parties fall into the same
|> classification.
|
| Sharing an MTA is a highly effective method used by ISPs to abate abuse.
| Reserve painting this technique with such a broad brush. This wide
| brush never uncovers an MTA that may be compromised or poorly
| administered. Holding those unable to take immediate corrective action
| accountable will cause a most unwelcome backlash. The party that must
| be held accountable is the entity administrating policies of the MTA.
| That party is only identified by an authenticated EHLO domain or the IP
| address.
You are advocating Sender-ID or SPF identities are authenticated. I
still claim this is a misuse of the term authenticate as this presumes
the integrity of the mail channel and the nature of the list. I noted
the hazard making this assumption would cause with respect to harming
reputations of those that, through no action on their part, receive
negative assertions.
There are valid reasons people share an MTA server. I do not think it
is wise to suggest any message which traverses an MTA authorized for a
particular mailbox-domain should claim this MTA is (or is within)
"mailbox-domain." Nor, when the message is spam, treat this event
"as-if" mailbox-domain had actually been authenticated.
This accountability must be seen as a hierarchy. It is not fair or
effective to give mailbox domains a bad reputation when an MTA
administrator fails to check send control lists, or has an MTA that
becomes compromised. Blocking the spoofed mailbox domain does not
correct the problem, but instead makes worse problems for those not in
control of the MTA causing the problem. This would allow a spoofer to
single out a few domains at a time while not disrupting general use of
the problematic MTA. The only recourse for those harmed in this fashion
would be through litigation. The problematic MTA is never blocked.
Thanks. This lets me know your position isn't well-defined.
At least it is not understood. : )
-Doug