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

Sat Nov 15 01:03:15 PST 2003

right - so the point is that you have to be able to verify source - i.e. the reverse lookup must work, and the
reverse route must work, hop by hop (if ip, each router must look at the source address and verify the inport is
the one towards source - at SMTP, each relay must verify the previous relay as being the from for the email soruce,
and so long as this can be done back to the first hop, for ip, source host to first hop router, for email, email
client to first outbound SMTP relay, THEN and only THEN can you apply other spam measures...

if you make sure reverse paths are verifiable (traceback for ip etc), then you can impose end2end measures

if you don't do the first step, then the second is open to masquerades, sybil attacks, spoof sources

this is not to say that you have to bind a route to the end2end session ,or that the route must necessarily be symmetric
or that you have to have a long term association between source and destination and route (viz virtual circuits
etc)  - just that some checking can be done

the point here is that (i think)  we all like the IP/internet idea of unsolicited transmission, but we want to
control the amount of it - this means that pseudo-economic means like puzzles and hashcash (or real ones like
payment or legal controls) are not necessary for EVERY thing - if you keep these schemes for unsolicited (martini
advert music) any time anywhere communication, you have to have traceback-  but you need traceback anyhow even for
"solicited" communication (by this i mean that whitelisting is a form of solicitation, but depends on unforegeable
sources, and for network wide control (viz prevention of ddos on a link or router, the unforgeable source has to be
recursive to apply to the previous hop at each link...)

this creates problems for anonimity (or even pseudanonimity) in p2p routing systems.....but then if youi want that,
you have to buy into unsolicited unverifiable source (that donesnt mean yo ucan't verify content seperately through
usual digest signature stuff)

In missive <6.0.0.22.2.20031114124411.03de3e40 at mira-sjc5-6.cisco.com>, Mark Baugher typed:

 >>
 >>-----BEGIN PGP SIGNED MESSAGE-----
 >>
 >>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 ***
 >>
 >>
 >>
 >>-----BEGIN PGP SIGNATURE-----
 >>Version: PGP 8.0.2
 >>
 >>iQEVAwUBP7U+vLNlGkxcmpNTAQGbAQgApFmi2mRduJLhgCVyM/1IgiG3OlGL9nat
 >>cP9wxvKakxR9GfyLFgSTbHaeejJtJ3lnxkB1MqEJf13kGf6uum8DfJaPsxZIwXeS
 >>tUGrDbFvJ+GTMtjPB+uPjomkXS1p/dI19CHFgdjyUGHrjG3/NhmjjYJyDDkfBvto
 >>Ptr0p5X1EjVhWsVo59GwYdXBaNKQrUYyqeVjFsP3Y2SbHD9L/tjloQYuUwaUu+r9
 >>zLWCIzVfIS8WTVMo5wnJdoZS1v6NXODOIUmk70SC4uXfjds7gj1ilt2jp7XoBfeL
 >>zuA5PLKQq8RHrZEBIkieCQU8uIwJIrAcgWheg/oTLgAx/fO5Thdg8Q==
 >>=2r09
 >>-----END PGP SIGNATURE-----
 >>

 cheers

   jon