Re: A new SMTP "3821" [Re: FTC stuff...........]

David Woodhouse <[email protected]> wrote:
> But it seems you were talking of problems with mail in general while I
> was concentrating solely on spoofing, which is a special case -- one of
> the band-aids you mention. I apologise for misinterpreting you and
> attributing to you a belief which is not yours.

  Thank you.  I can't ask for anything more.

> Are you saying you do _not_ believe that in order to fix the spoofing
> problem we must make incompatible changes to the way SMTP works
> universally?

  I've seen no evidence that such a change is required.  However, IF
there are no better methods, then I am prepared to accept that such a
change is required.

  For many discussions I've been involved in, people ignore the "IF",
and go on a tangent.  That's been a serious source of
miscommunication.

> That you believe we can achieve it by only making changes at the
> endpoint sites which want to take advantage of any new scheme?

  I hope that's true.  It certainly looks that way.

> > Therefore, whether people admit it or not, the SMTP model
> > *is* open for changes, and *is* being changed.
> 
> Backward-compatible change within the scope of the existing system, yes.

  Again, who decides what's in scope, and what's not?

  If my domain has no users with ".forward" files at other domains,
then implementing RMX/SPF/whatever doesn't break forwarding for *my*
users.  The argument against those proposals then becomes "We have
.forward files, so we won't be implementing RMX, and we don't want you
to implement it, either".

> [ re: who can propose what changes ]
>
> Indeed -- and it's a very hard one to answer. What we _can_ say is that
> changes which are limited to participating sites are a lot easier than
> changes which must be implemented ubiquitously in order for the system
> to work correctly.

  As a toy proposal, a simple solution to the .forward problem is to
replace the .forward files with a script, which adds a header like:

X-RFC2821-Original-Bounce-Path: <rcpt-to mailbox>:<mail-from mailbox>

  The script can then send the message, using the original "rcpt-to"
as the new "mail-from", and accept the bounces.  When a bounce comes
back, the script can look for it's name in that field, and bounce the
message in turn to the original "mail-from".

  Add some authentication so the field can't be spoofed, maybe some
encryption so it's private, and a site using ".forward" files can
upgrade them all to a functionally equivalent form, which does NOT
require using a third parties name in "MAIL FROM".  No interaction
with other sites is required.  Anyone familiar with Sendmail's rules
could probably add something like that in a few hours, and most users
wouldn't even have to update the contents of their ".forward" files.

  The only reason that people were using .forward files is that it was
easy, it worked, it didn't cause problems for other people until
recently, and there is always resistence to change.

> I'm not arguing with your actual position. To fix spoofing of
> addresses is just a band-aid, as you said. But it's all that's on offer
> right now. I'm saying we can do _that_ without fundamental changes. 

  Yes.  But there has been near-zero discussion about what the "SMTP
mode" really is.  The current SMTP "model" is a collection of RFC's,
implementation decisions, deployment decisions, and other ideas in
peoples heads.  For the model to be clear to everyone, the concepts
have to be written down, and explained for everyone too discuss.

  The alternative is to allow only the people with the "secret decoder
ring" to discuss or update SMTP.

  Alan DeKok