Re: Mailing lists - assumptions

On Saturday, April 19, 2014 15:33:52 Ned Freed wrote:
> > 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.

Since whatever scheme is used for rewriting Mail From only matters locally, 
there's not a lot more to say from an interoperability perspective.  We 
discussed this in the working group and concluded that was sufficient.

If someone feels a need for more specification of exactly how to do that, then 
I think they ought to write a draft specifying how to do SRS and get it 
published.  Throwing another roadblock in front of 4408bis now is not the 
right way to handle it.

It's also unrelated to the DMARC/mailing list problem (in most cases).  
Generally mailing list managers use their own mail from, so the original 
senders SPF doesn't enter into it.  SPF only gets mixed in due to DMARC 
insisting on identity alignment.  That's nothing to do with SPF.

Scott K

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