Return-path header control

[Oleg Derevenetz]

Henrique de Moraes Holschuh wrote:

>>>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.

All right, may be, I think so because I use deliver that rewrites 
envelope... So I always set up MTA to add the Return-Path header to mail 
messages. For LMTP delivery probably first behaviour is the best choice.

>>>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.

To avoid problems with message import from other mail storages wich 
mostly do not have such strict checks. Or there should be an utility 
that will verify message headers and correct them if necessary.

There is a good principle for software - to be much more conservative 
and restrictive in output and liberal in input.