ietf-mxcomp
[Top] [All Lists]

preserving desired functionality at the cost of changing implementations

2004-03-18 18:22:26

On Thu, Mar 18, 2004 at 10:13:24AM -0800, Mark C. Langston wrote:
| 
| On Thu, Mar 18, 2004 at 11:20:22AM -0500, Meng Weng Wong wrote:
| > 
| > 1) I believe that it is important to protect the RFC2821 MAIL FROM from
| >    illegitimate spoofing, independent of the RFC2822 header From:.
| > 
| > 3) I believe that it is also important to protect the RFC2822 header From:
| >    from illegitimate spoofing, independent of the RFC2821 MAIL FROM.
| > 
| 
|   Could you provide us with en example of what you view as legitimate
| spoofing of RFC2821 MAIL FROM and RFC2822 header From:?

Legitimate spoofing of RFC2821 MAIL FROM:
- web-generated email (I log in to eBay and send mail using eBay's web
  UI to another eBay member; I want to see bounces.)
- verbatim forwarding (a(_at_)a(_dot_)com sends mail to b(_at_)b(_dot_)com 
which forwards to
  c(_at_)c(_dot_)com; if c(_at_)c(_dot_)com is undeliverable, 
a(_at_)a(_dot_)com should get the bounce.)

Legitimate spoofing of RFC2822 header From:
- My mother comes to me and asks me to email my father with a note
  to buy milk and eggs on his way home.  I send mail using a mail client
  that lets me edit the From: header field so I change it to her
  email address; I put my email address in the Sender: header.

| Do you believe that the pursuit of points 1 and 3 should override the
| preservation of these legitimate spoofs?

Yes; legitimate spoofing is by definition very hard to distinguish from
illegitmate spoofing.

  ... all experience hath shewn, that mankind are more disposed to
  suffer, while evils are sufferable, than to right themselves by
  abolishing the forms to which they are accustomed.

If breaking the current implementations of the above legitimate spoofing
scenarios means we can solve the forgery problem, then I think we should
break them, and expect the community to respond by working around.

The functionality is what's important: in the future, I still want to be
able to send mail to another eBay member and get the bounces if the mail
is undeliverable.  I want to be able to mail b(_at_)b(_dot_)com and get the 
bounces
if c(_at_)c(_dot_)com is undeliverable.  If SRS makes it into MTAs, the average
email admin won't have to do anything more than upgrade his MTA --- and
that's if he wants to support email forwarding.  If he doesn't do
forwarding, he doesn't have to do anything.

I want to be able to send mail to my dad on behalf of my mother.  (If
per-user crypto is used, I may not be able to forge my mother's From:
unless she gives me her passphrase and private key, so that changes
behaviours a little bit.  If per-domain crypto is used, I can do the
spoof if we happen to have the same ISP.  But maybe this kind of
spoofing will have to come to an end: I may have to just say "Hey, Dad,
it's me; Mom wanted you to know: ...")

The important thing is that the functionality that people care about can
be preserved, albeit at an added cost in implementation complexity
(eg. SRS for forwarders and web-generated email).

So, in this future, we do break backward compatibility; but the places
where it breaks are well defined.  The number of people who have to do
work to get around the breakage is relatively small: basically it's the
email admins who have to deal with change, and that's OK, because it's
their job to do that.  That's better than requiring a change in
behaviour from absolutely everybody.  And that's better than going on
with things as they are today.

Choosing an effective, timely solution that has well-defined breakage
whose workarounds are the responsibility of (professional)
administrators just sounds to me like good engineering.

I have a slideshow that makes the above argument more visually.  Click
on the RHS of the image to step forward.

  http://spf.pobox.com/slides/apcauce2004/7000.html


<Prev in Thread] Current Thread [Next in Thread>