Re: Mailing lists - assumptions

> On Sat, Apr 19, 2014 at 11:00:35AM -0700, Ned Freed wrote:
> > You want any downstream delivery errors to be reported to the original sender,
> > so ideally you'd leave the MAIL FROM unchanged. But now an SPF check on the
> > MAIL FROM will fail because alum.mit.edu's IP address isn't going to be
> > allowed list.
> >
> > The usual way this is solved is with a more complex forwarding address,
> > one that incorporates a timestamp and a verifier. As I noted
> > previously the Sender Rewriting Scheme is one way to do this, but of
> > course you can use any encoding you want since only your systems have
> > to understand it.

> You mean like this:

> Return-path: <SRS0=/[email protected]>

> :-)

Yes indeedy. Looks to me like bog-standard SRS.

> Sure, it's a bit ticklish, but it's obviously implementable.

Indeed. But now that we've gotten this far, here's a question...

Given that this issue is a forseeable - and forseen - consequence of using SPF,
and given there's an effective, but not exactly obvious, solution to the
problem, why are we going forward with publication of SPFBIS as a proposed
standard (currently in AUTH48) without a companion document describing this
problem and at least the corresponding solution space, if not going so far as
to document a specific solution?

At present draft-ietf-spfbis-4408bis has this to say about the issue:

 o  Mediators can solve the problem by rewriting the "MAIL FROM" to be
    in their own domain.  This means mail rejected from the external
    mailbox will have to be forwarded back to the original sender by
    the forwarding service.  Various schemes to do this exist though
    they vary widely in complexity and resource requirements on the
    part of the mediator.

Does anyone seriously think this provides the necessary guidance to an
autoforwarder developer/administrator faced with wholesale rejection of their
forwarded mail due to SPF? Because I certainly don't.

				Ned

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822