Re: [exim] multiple cc: headers

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Slavko (tblt)
Data:  
Para: exim-users
Asunto: Re: [exim] multiple cc: headers
Dňa 9. mája 2022 11:37:35 UTC používateľ Julian Bradfield via Exim-users <exim-users@???> napísal:

>My error - google autocorrected me to 5322 and I didn't
>notice. (Happens every time...)


No problem, it happens, only to be sure what was the typo, in that case, it was
nice, because one can guess the 5 as typo too (as RFC822 or as RFC2822)

>The "MUST accept" is in the first paragraph of section 4
>
>The "SHOULD combine multiple headers" is in section 4.5.3.


Found it, they both seems to be the same as in RFC2822...

>5322 is dated October 2008, which is 14 years. In something as
>critical as mail, that's a short time.


Sorry, my bad math. But both your citations appears in RFC2822 too, thus
they was deprecated in between your 14 years and my 25 (more precise 24)
years -- 21 years ago.

>Anyway, the point is that (as I've seen), modern MTAs (the message in
>question went through Postfix, then Sendmail) do not rewrite messages
>with multiple addressing headers.


Sure, change message on transport is mostly not OK, especially with DKIM,
but (some) fixing of messages is OK for MSA.

>An obsessively educational sysadmin could send a warning about it,
>but rejecting messages that MUST be accepted remains clearly wrong!


IMO not true. Their MTA = their responsibility = their rules and they cleanly
inform sender what is the problem.

Especially your second citation is SHOULD, thus not strictly required. And
consider, that there can bo other (than MTA) SW involved in (final) delivery
or processing, which simple do not support multiple destinations headers,
which can be reason for reject. But IMO, educating the users is good reason
too.

Consider, from the same RFC5322 section 4:

    ...these (obsolete -- context by me) syntactic forms MUST NOT be
    generated according to the grammar in section 3, ...


Once again, fix client (message generation), instead of asking to support
obsolete things.

regards

--
Slavko