[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: