ietf-mxcomp
[Top] [All Lists]

Re: Solution For Trojans

2004-08-23 10:35:16

On Mon, 2004-08-23 at 07:43, Alan DeKok wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
I agree. The PRA does not authenticate the MTA as a means to identify
those administering polices to control mail.

  I don't think that was it's intent.  It identifies a responsible
party, who may not be the connecting MTA.

It provides an identity based upon many unverifiable assumptions.  These
unverifiable assumptions ensures there can never be certainty with
respect to accountability.  Only when there is certainty, can this
identity be held accountable.  Also, as it stands, such an identity
could possibly come from any MTA in the world.  What does this mean with
respect to accountability?  Sorry, but Sender-ID is not about
responsibility or accountability.  Sender-ID may not relate to any MTA
or relate to hundreds of other unidentified domains with separate
administrations.  If there is a problem, who can take action to curtail
the problem?

If, despite a lack of certainty, this identity is held accountable and
thereby blocked, what recourse would they have?  Which MTA suffers from
a lack of integrity in the case of a spoofed Sender-ID entity?  This
could be an integrity problem with the recipient.  Sender-ID is always
checked by the recipient, and if there is a lapse of checking within a
chain leading to the recipient, why should the entity identified by
Sender-ID be held accountable?  Would there be a blacklist for
complainers and complaints?  Would it be possible to complain, if the
Sender-ID list were "open"?

The EHLO domain entity is granting access to the mail channel and they
have logs to sort out who did what.  If networks are to be protected
from those wishing to abuse the system, only this entity is capable of
taking effective action to abate this traffic.

  Then why do we have MAIL FROM?  The user/domain in MAIL FROM is
claiming some kind of accountability for the message.  They should be
held responsible for something, too.

This is the return path for a delivery error.  By definition, this is 
unrelated to the MTA sending the message.  This MAIL FROM identity, as
it stands, is worthless for determining responsibility.  SPF attempted
to prescribe a mail channel related to the Mailbox Domain.  But that
breaks list servers, mail forwarding, etc.

Sender-ID does not provide author protection, as it makes a false
assumption RFC2822 content is secure 

  Is RFC 2821 content secure?  As we've seen, it's unaccountable, and
untrustworthy.  About the only field in RFC 2821 that you can trust is
RCTP TO, which doesn't mean much.

This overlooks the EHLO domain that can be authenticated and verified to
have been authorized by the domain to act as an outbound MTA.  The RCPT
TO does not indicate any accountable entity.

-Doug