E2E spam argument (was Re: [e2e] latest spate of cruft postings to e2e)

[Mark Baugher]

At 10:16 AM 11/14/2003, Ted Faber wrote:
>bd78ac3.jpg
>  E2E spam argument (was Re [e2e.ems<file://D:\Documents and 
> Settings\mbaugher\My Documents\email\Attach\E2E spam argument (was Re 
> [e2e.ems <0880.0002>>
>*** PGP SIGNATURE VERIFICATION ***
>*** Status:   Good Signature from Invalid Key
>*** Alert:    Please verify signer's key before trusting signature.
>*** Signer:   Ted Faber <faber at lunabase.org> (0xE65FF97B)
>*** Signed:   11/14/2003 10:16:36 AM
>*** Verified: 11/14/2003 10:48:10 AM
>*** BEGIN PGP VERIFIED MESSAGE ***
>
>On Fri, Nov 14, 2003 at 07:20:05AM -0800, Mark Baugher wrote:
> > Spamassassin breaks my mail connectivity in at least one important 
> way:  It
> > throws away my mother's email unless it is explicitly white listed.
>[ details of the false positive causes deleted ]
> >         False positive but an annoying one for me and would have been much
> > worse if I did not call her every week.
> >
> > Such problems abound.  Curbing spam is a middle-to-middle problem and not
> > and end-to-end problem IMHO.
>
>I don't understand how your example supports your conclusion.

I'd expect that the problem should be solved at the mail relay and not by 
my Mom - that's what I told the mail operator.


>The two ends of your mail connection (your Mom's mailer and yours) are
>the points that need to be configured to get the mail through.  Only the
>endpoints have the information to correctly remove the false positive.

A mail relay is really not needed for this application and it would be 
silly to expect my Mom to have to reconfigure her email machine for this to 
fix this.  She would not be in this bind if her mail operator did not do 
the following:

Received: from vtcomm-5.homerelay.com (HELO yahoo.com) (209.75.47.220)
   by 0 with SMTP; 13 Nov 2003 14:57:42 -0000

...and use yahoo.com in the mail-from it is sourcing.

>That information is that your Mom's forged address is acceptable to
>your end, and probably only your end.  Only an end-to-end solution seems
>possible at all, though information from internal nodes of the network
>might be used as a performance enhancement.  That sounds like a classic
>end-to-end argument to me.

You filtered my argument in your note:

> > Spamassassin breaks my mail connectivity in at least one important 
> way:  It
> > throws away my mother's email unless it is explicitly white listed.
>[ details of the false positive causes deleted ]

Should be:

>>Spamassassin breaks my mail connectivity in at least one important 
>>way:  It throws away my mother's email unless it is explicitly white 
>>listed.  So if someone wants to spam me, all they need to do is use my 
>>mother's email address in the from address.

So the end-to-end filtering is broken in this case.


>Have you picked different ends or am I missing something?

I think you're missing the mail relay, i.e. the SMTP mail transfer agent 
that accepts mail from one domain and delivers it to a third 
domain.  Although this is useful for mail operators that don't have 
uninterrupted connectivity (e.g. use dialup services), it makes no sense 
for homerelay.com to operate like this.  But the feature and practice is 
their, so it does.


>[Hmmm.  I guess you could do the filtering at, say, your ISP's mail hub.

No, I would not do that.  I think that the right way to do it would be to 
[1] reconfigure the MTA to be a yahoo.com MTA and use SMTP auth.  Or [2] 
reconfigure the email machine to go to a yahoo.com MTA. Or [3] Or 
re-configure the email machine to go through a homerelay.com mail 
submission agent that re-writes the from and reply-to - I think this is 
compliant with SMTP standards-track documents (too late for my 
problem).   [4] Or we could use some kind of ASRG-like reverse MX DNS 
extension.  In other words, none of the solutions necessarily use filtering 
and can run m2m, e2m, or m2e.

>I don't think that makes spam detection less of an end-to-end issue, because
>
>         1. Not all mail follows that model, and an end-to-end solution
>            is required to handle mail that doesn't.  (In other words the
>            hub is a performance enhancement.)

According to IETF standards-track documents it is more than a performance 
enhancement (ftp://ftp.rfc-editor.org/in-notes/rfc2476.txt).


>         2. Even if all users have a mail hub, it seems meaningful to
>            talk about the communication as being mailbox to mailbox, in
>            which case filtering at the hub is doing the work at the
>            endpoint.  We may not agree on that definition of endpoint as
>            mailbox, but I think that considering mail delivery to end at
>            a mailbox (on the hub) and reading of mail to be accomplished
>            by remotely accessing that mailbox (from a workstation) to be
>            a reasonable model.  YMMV.

According to IETF standards-track documents, anything but filtering at the 
endpoint violates mail-system integrity:  Only the endpoint can accept and 
discard mail and not the mail transfer agent, which returns a 5yz or 4yz 
return code if it does not agree to deliver the mail.  So,  "I think that 
considering mail delivery to end at a mailbox (on the hub) and reading of 
mail to be accomplished by remotely accessing that mailbox (from a 
workstation) to be a reasonable model" is not true in my view.

Mark
>]
>
>--
>Ted Faber
>http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
>Unexpected attachment on this mail? See 
>http://www.isi.edu/~faber/FAQ.html#SIG
>
>
>*** END PGP VERIFIED MESSAGE ***