Re: More questions on smail configuration for SMTP/PPP
Jeffrey Ebert writes ("Re: More questions on smail configuration for SMTP/PPP"):
> Richard Kettlewell agrees:
> >Indeed not. AFAIK Smail can't solve this properly without some kind
> >of wrapping - rewrites are not a feature of the program.
> This seems to be a serious indictment of the proposed solution.
> So Ian, before you change the configuration of Smail to make it reject messages
> with bad return path information, you should work on creating a configuration
> that works for most, if not all, ISP configurations. And I would still like to be
> able to send mail to postmaster@ISP.com!
You don't understand. Smail will be changed to reject bad messages
*when another system tries to deliver them to it*. Ie, if you're the
postmaster it will simply stop you having to deal with the crap.
This will only further break the already-broken workarounds that have
been proposed here if the ISP turns on this option - but IMO the ISP
ought to do that already.
Carl V. Streeter writes ("Re: More questions on smail configuration for SMTP/PPP"):
> I think I'm missing something fundamental, here. Isn't the return-path
> supposed to be set by the last transport agent that delivers the message?
> (RFC 822)
> If so, then why won't rewriting the From field make that happy? (or does it
> use the received data or something else?)
> Is there an RFC (later than 822) that I should be looking at?
Read RFC821. The return path is the SMTP envelope from information,
carried in the SMTP dialogue's MAIL FROM:<...> line.
Most MTAs copy this information into a Return-Path header during final
delivery; with a sendmail-a-like MTA you can only set the return path
information with the -f flag, which requires privilege.