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

Re: [Asrg] Question on Message-ID


On Wed, 9 Jun 2004, Richard Welty wrote:

On Wed, 9 Jun 2004 04:40:32 -0700 (PDT) "william(at)elan.net" <william at elan.net> wrote: 
I have a somewhat quick question needed for the draft I'm starting to write.
I want to know if in the current mail practice Message-ID is ever changed
when email is in transit, i.e. do intermediate MTAs ever enter their own
new Message-ID. By intermedia MTAs I mean absolutely any MTA in any
complex email path, including maillists, forwarders, normal relays,
anti-spam firewalls relays, etc.


if you haven't already read RFC2822, 3.6.4, you really should do so
before writing any more of your draft.

Read it many times...

be aware that Message-ID is a SHOULD, not a MUST, and many MUAs
do not generate one, leaving it to the first MTA that's paying attention to
put one in.

The reason I'm asking is specifically that it says "SHOULD" in RFC2822 and I wanted to know common behavior. Actually for purposes of my draft not having MessageID is fine, I'll insert the line in the draft that says that
if MTA supports this security exteions and email it received has no
MessageID, then it MUST add it itself.

If Message-ID is changed, can somebody provide me example as far as which
software does it and how this practice is.

it's not supposed to be done, but some MTAs reportedly do this. i don't have
I'm going to have to assume that this practice is wrong and non-conformant with existing standards for purposes of what I'll propose.

any examples for you. there is langauge in RFC2822 3.6.4 that specifically
addresses this.


Related question is if bounced emails autogenerated by MTA software ever
have same Message-ID as original email, if so which MTAs use this
practice and how common is it?


now this shouldn't happen. a bounce is a new message, originating at at
the bouncing MTA. if it does, it's definitely out of conformance.

This is actually an even more important question for me, because where as if MessageID has changed, it would not be fatal flow (although it would kill the security extension usefullness) but if bounce has the same MessageID, then it would not verify and would cause the bounce to be rejected before
it possibly reached the user.

There is a workaround that requires adding new header, but I dont want to bother if the above is very uncommon and against current standards (but I can't find any word in RFCs that it is).

---
William Leibzon
william at completewhois.com

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg