Bastian Blank a écrit :
> On Sun, Feb 08, 2009 at 11:13:53AM -0500, Sahil Tandon wrote:
>> On Sun, 08 Feb 2009, Bastian Blank wrote:
>>> Yes. It will break the complete mail handling of the client. _Never_
>>> ever touch a message id.
>> Do explain how adding/replacing a valid Message-ID only to submitted mail 
>> will "break the complete mail handling of the client".
> 
> I mean replacing or deleting already set Message-Id headers. And it will
> break MUA driven thread handling 

- very few people put their Sent mail in the same folders as received mail
- even then, MUAs have heuristics to cope with such situations.

> and similar things which is based on
> the original submitted ID.
> 

other than spam filters that try to detect forged mail, the original
message-id, if replaced by the MSA, is irrelevant.

and if a spam filter blocks/discards/quarantines mail because of this,
it is the filter that should be blamed.

after all, the practice of hiding private infos is not new. whether it
is called "security by obscurity" or "an additional layer of security",
it's there.

I might give this a try and see what happens...

>>                                                         And how do you
>> reconcile your last sentence with section 8.3 of RFC 4409?
> 
> Please read the RFC again. This sentence only speaks about _adding_ this
> header, not about replacing or deleting it. There is however no other
> point which allows arbitrary modifications to the messages.
> 

correction: The rfc speaks about _replacing_ the message-id if it is
malformed. (and what Sahil wants to do is replace the MUA generated
message-id with one generated by postfix).

while this doesn't say anything about replacing a well formed
message-id, it indirectly acknowledges the fact that message-id's may be
replaced. and such things do happen.

In case you missed it: Sahil wants to _replace_ the message-id generated
by the MUA by one generated by postfix. He uses the fact that postfix
will add a message-id if one is missing.

Reply via email to