Return-path header control

[Henrique de Moraes Holschuh]

On Tue, 17 Dec 2002, Oleg Derevenetz wrote:
> Henrique de Moraes Holschuh wrote:
> >Well, this Return-path issues got me thinking a bit about the issue...
> >
> >I could write code to add a configuration option to Cyrus so that it
> >has two methods to deal with return-path:
> >
> >1. Override (should be the default one): trash any return-path headers
> >   in the message, and add ours (from -r or MAIL FROM:)
> >2. Add:  Add our return-path header _if_ there ins't already one in there.
> >   Messages with more than one return-path header are in error.
> 
> I think that second behaviour must be by default.

I will follow CMU's judgment on this one.  You do understand that if you use
(2), you must have one MTA in your administrative domain that kills all
possibly-illegal return-paths?   Adding one is optional, but you must not
let false ones through.

So (1) is a safer default, AND it is compatible to what Cyrus tries to do
right now. (2) is to be used by people that know what they're doing, and
need a MTA to do the return-path creation beforehand due to envelope
rewriting, or somesuch.

> >Also, should messages with multiple return-paths be flagged as illegal? The
> >RFCs seem to imply that only _one_ return-path header is allowed.  Doing
> >this could cause severe headaches for people with spools with broken emails
> >with more than one (which I think is a fairly common problem).
> 
> No, they shouldn't.

Why?  I would like answers a bit more elaborate than that, please.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh