On Sun, 2004-09-12 at 18:23, Alan DeKok wrote:
"Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org> wrote:
WHAT "mail channel"? I have described what I think of as the "mail
channel", and given reasons for my conclusions. You haven't.
Mail is normally passed from MTA to MTA on its journey to the destination.
How does that affect MAIL FROM authentication via records in DNS?
There must not be assumptions made regarding mail channel integrity, so
there can not be a conclusion MAIL FROM has been authenticated. The MTA
may be authorized to send on behalf of MAIL FROM, but that is not the
same as authenticating the entity associated with the identity MAIL FROM
as being the originator.
The MTA making the public delivery is often not where the message was
created. The sequence of Mail Transfer Agents carrying the MAIL FROM
identifier is what I had referred to as the mail channel.
None of which is relevant to MAIL FROM authentication via records in
DNS. The previous hops are invisible to MAIL FROM checks.
Although such hops are apparent through the RFC2822 headers, both for
these headers and the RFC2821 MAIL FROM, there is no SPF or Sender-ID
mechanism to allow the authentication of their origin.
You are saying one can not be sure of the origin of the MAIL FROM, but it
is okay to use this identity to assert a reputation assessment against the
actions of the SMTP client.
I'm saying that the recipient may not know the "true" origin, and
that that "true" origin may be un-knowable. The recipient CAN know
that the current hop is authenticated, if the MAIL FROM satisfies
authentication records in DNS.
The current hop is authorized, not authenticated, to act on behalf of
the entity associated with the MAIL FROM identity. SPF or Sender-ID
confirmation does not mean this entity associated with the MAIL FROM
identity had originated the message. This would be making unverifiable
assumptions about the mail channel, whether the MTA is shared, and
whether the list was "open". A check host function will not provide the
nature of the list.
For the recipient, nothing else is verifiable, and therefore nothing
else is relevant.
The EHLO name is verifiable and high relevant when there is to be a
reputation assigned for abusive actions.
All I'm doing here is taking your EHLO argument, and applying it to
MAIL FROM. Your opposition to this process indicates conflict or
confusion somewhere in the conversation.
The assessment of reputation must be assigned accurately to the entity
acting as the cause of the abuse. You are extending the concept of
authorization to be synonymous with having actually acted.
Now you are saying publishers should also expect to be black-listed
when they publish an "open" record as have AOL.
Publishers should expect recipients to do the most curious things,
for the most inane reasons.
What does this mean?
Showing the name being blocked is the entity that actually sent the
abusive mail will greatly aid the defense of the reputation service.
Replace "sent" with "accepted responsibility for", and MAIL FROM
checking is perfectly valid, if all parties agree.
How do you arrive at publishing an SPF record being tantamount to
accepting accountability for all actions of these authorized entities?
If one were to authorize a provider to send mail, and their provider's
system became compromised, would it not be better to accredit the
provider for resulting abuse? Won't this resolve the problem sooner
than causing an innocent party to litigate for protection from a sloppy
reputation assessment? In the case of an "open" record, this would hold
the SPF publisher accountable for any actions within the entire Internet
should they also expect to allow mail to be forwarded.
Why? I've explained why and how MAIL FROM accountability can be
safely applied.
You have not. You simply say you can hold the MAIL FROM entity
accountable because they published with the clear warning within some
discussion within this WG.
No... that's dumb. "MTA's don't read mailing lists".
I assume there is an entity, meaning a sentient being able to read,
associated with the MAIL FROM identity.
In any protocol implementation, all parties involved agree as to
what the information means, and how to interpret it. MARID
implementations are nothing special in this regard. If this WG
publishes standards defining accountability, then it's entirely
reasonable to expect that implementors of the standard have accepted
that accountability.
This extension of SPF authorization into also meaning acceptance of
accountability for the actions of authorized servers should be a warning
made in all capital letters! I think such extension of accountability
rules out a safe use of any "open" list as well as any hope of allowing
forwarding and some list servers to function.
But where does it say publishing an SPF record is accepting
accountability for any message using this mailbox domain coming from
an SMTP client? That is the million dollar question.
That spec isn't under consideration by this group, so any answer
would be out of scope. But in general, I believe close examination of
email scenarios may lead to such statements.
The marid-mpr draft shows how the authentication of the MTA client can
be accomplished separately from the mailbox-domain authorization. By
doing both steps independently, there is no need to hold the mailbox
domain accountable for the actions of the client MTA they authorize.
This allows the administrators of the mailbox domain to decide how they
wish to handle mail forwarding and list servers without the risk of
falsely obtaining a bad reputation.
I am of the opinion these assumptions are caviler and needlessly risky.
This risk will represent the demise of the reputation service.
Which is why I have great skepticism that any reputation system will
work.
Having my ability to run an MTA depend on kissing up to some third
party? Sure... that fits into the freedom, and the "end to end"
nature of the net.
It does not require everyone to use a reputation service for such a
service to be effective in curtailing abuse. Theses services assist
providers in locating problems and fending off enough load as to remain
viable. There is nothing that mandates use of such services, but
adopting a universal means of accurately identifying the MTA client name
is vital for there to be a name based reputation service. SPF and
Sender-ID is worthless with respect to identifying the MTA client.
Making the authenticated EHLO visible within the MUA will provide
superior consumer protections over the PRA algorithm, and affords easier
compliance.
Start out with a nominal list useful for coloring mail. If protocols
like a public version of BATV become prominent, then more may find it
reasonable to declare their lists comprehensive.
-Doug