ietf-mxcomp
[Top] [All Lists]

Re: Solution For Trojans

2004-08-19 10:33:59

On Thu, 2004-08-19 at 08:07, Alan DeKok wrote:
"Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org> wrote:

The technique of using RFC2822 content to identify the MTA will lead to
errors and is based upon a premise such content has not been spoofed
between MTAs.  There is no means within this standard to hold a particular
MTA accountable.

  I agree.  It's only hop-by-hop accountability.

With Sender-ID, EHLO and MAIL FROM are ignored.  Sender-ID has no
concept of the hop, but rather considers a distribution that _may_ be
part of a merged set of domains, or even of an "open" set.  As example,
with Sender-ID, the message may initially be identified as being outside
the "open" set, but if introduced into the merged set, it will be
promoted to being validated as being inside the "open" set. : (

With Sender-ID, the entity accountable for traffic emerging from a hop
is _not_ identified.  CSV, however, clearly identifies this entity and
thus provides an identity that may safely be held accountable.  These
are important nits from the perspective of enforcement with repudiation,
reputation, or accreditation.  Once considering the likely evolution of
Sender-ID, where ISPs resort to using Resent-From, the PRA is not
substantially different than <From:EHLO*>.  With BATV, <MAILFROM:EHLO>
would be just as good as Submitter. (The reason for indicating BATV use
in MPR.)

  CSV-CSA isn't any different, in that regard.

CSV is very different from Sender-ID in that regard.  It seems we agree
on major points, so I am confused how you can hold this view.

CSV-CSA deals directly with the entity sending the mail, and not
indirectly based upon RFC2822 content.

  For similar reasons, my interest in this area has always been RFC
2821 content, alone.

I agree 2821 EHLO and MAIL FROM should be the focus, if to curtail spoof
bounces, Trojans, and spam.  I provided the MPR draft to illustrate how
the channel could be related to the From Mailbox Domain using a single
DNS reference, to afford protections for institutions being phished, as
example.  Sender-ID however does not offer an effective protection in
this area, while it breaks much of the current mail, hammers DNS, and
ignores UDP back-off requirements.  I see such Mailbox Domain/Mail
Channel restrictions as the exceptional case.  Perhaps over time, this
exceptional case would be better accommodated by things like BATV. : ) 


*Authenticated. 

-Doug