E2E spam argument (was Re: [e2e] latest spate of cruft
postings to e2e)
Mark J. Baugher
mbaugher at rdrop.com
Sun Nov 16 08:19:26 PST 2003
hi,
At 01:03 AM 11/15/2003, Jon Crowcroft wrote:
>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...
Ok. There are some questions about what "email client to first hop SMTP
relay" is, for example, in this message that I'm sending to you:
mbaugher at rdrop.com via Cisco's (outbound) MTA/MSA/relay. For many users,
it's more important when getting mail from a strange address to know that
it came from a reputable mail operator, cisco in this case. I guess it's
okay to think of mira-sjc5-e.cisco.com as an extension of my email
endpoint. It's more than a performance enhancement, however, if
mira-sjc5-e.cisco.com rewrites my mail headers, and/or performs SMTP auth,
and/or vouches for the mail, etc. If the ASRG consent framework turns out
to be widely useful, then a receiver may feel comfortable "opting out" of
an email sender's list that came via a reputable mail operator even if the
sender is a stranger. This is not exactly end-to-end. This has some
peer-to-peer services that complement end-to-end. Am I all wet on this point?
>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
One of the ASRG documents I read recently speculated that new mail
protocols might do any number of things differently from RFC 2821/2822 such
as make it so a receiver never exchanges mail with strangers. I'd like
that for my child. This idea was not developed in the document, but it can
in principle be done today with PGP mail (maybe complemented with receiver
filtering). I don't think that end-to-end secure email scales, however, to
most present and future users of electronic mail. PGP mail can make
identity-theft a far more serious problem if the user's end systems is
own3d by malicious code, possibly under control by one or more
attackers. In this case, some private keys will likely become own3d as well.
>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)
By "usual digest stuff" do you mean something like end-system PGP mail, or
something like MD5 hashes on messages received from a peer, such as a peer
router, or an SSL connection between mail relays that uses symmetric
message authentication?
Would you agree that mail transfer is a p2p routing system? I do. I think
that a p2p routing system, moreover, can use p2p security that is
independent of or that complements end-to-end measures.
Mark
>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
More information about the end2end-interest
mailing list