On 2003-11-13 at 15:44 +0000, Philip Hazel wrote:
> OK. This is a complete mess.
Given the amount of work which went into RFC2822, the amount of voices
all being heard, etc, I'm amazed at how _little_ a mess it is.
(May I never again need to program for DCE).
> I do not want to have to implement a whole pile of dodgy heuristic logic
> to try to do "better" in cases like this.
*phew*
> I am prepared to do the
> following:
>
> (1) Turn off the code that tries to fix up headers when Resent- headers
> are present.
>
> (2) Ditto, but only if there are non-contiguous Resent- headers.
>
> I would far prefer (1).
So would I. Perhaps the code should be left in for the "exim -t" case,
and _only_ then?
That restores the situation to the MTA (as opposed to the submission
agent, even though history conflates the two on Unix) only prepending
the some headers or perhaps double-checking content of some, if
possible, but otherwise being agnostic.
On a related note, is it worth considering an option to either use a
different format Message-Id: header when putting one on a mail received
via SMTP or to just not add one? Preferably done as a source-host ACL,
always on for non-SMTP injection?
Situation: internal mailhub is both internal smarthost and primary MX;
currently, some inbound mails, primarily spam, end up with message-ids
looking just the same as those for mail sent internally. It'd be a
wonderful spam heuristic if we could change this. :^) Either no
Message-Id: at all, or something like:
<normal-text.NORECEIVEDMSGID@???>
For customer smarthosts, we'd not want this, although I might consider
it too for servers handling inbound mail -- but merely the presence of
those hostnames in the Message-Id:, in anything except status emails to
us, is probably enough of an indicator for most customers.
--
2001: Blogging invented. Promises to change the way people bore strangers with
banal anecdotes about their pets. <
http://www.thelemon.net/issues/timeline.php>
