On Tue, 17 Aug 2004, David Woodhouse wrote:
> On Tue, 2004-08-17 at 14:06 +0100, Jethro R Binks wrote:
> > Anyway, aside from issues like an MUA like Outlook should be submitting
> > mail to the Internet through an MSA which should be fixing up a lack of
> > Message-ID: header, it seems from what you say David that you'd be
> > refusing mail from any user of the relevant Outlook version.
>
> You're right -- if it comes through an MSA (like Exchange) it tends to
> have a Message-Id added.
Yes, I forgot to add that. Exchange adds its own Message-Id (and maybe
obliterates anything a different version of the Outlook client added? Or
maybe just if there is none? Not interested enough to see really)
> In fact, if Outlook uses my system as an MSA then it'll get a Message-Id
> added too. It's only for incoming non-submission SMTP that I reject for
> lack of it. I should have made that clearer, perhaps.
That is our situation here, at present anyway.
> > While I agree that the RFC does specify that there SHOULD be a Message-ID:
> > header, it is not strictly a violation to not have one.
>
> RFC2119 says:
>
> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course.
>
> I've never had anyone explain a valid reason for ignoring the part of
> RFC2822 which says you SHOULD include a message-id header, and explain
> how they carefully weighed the implications and decided to omit it. I've
> only ever known it be omitted by accident, which _is_ a clear violation
> :)
Disagree. MS may very well have had a valid reason and considered the
full implications. I don't know if they did or didn't, and it may be
their interpretation of 'valid' is different from that of other people.
Nevertheless, the spec permits there not to be a Message-ID:, as long as
due consideration has been taken.
Fundamentally, I do actually agree that it is stupid for a message not to
have a Message-ID: header; but I am not answerable for MS' broken (in my
opinion) client. However I feel I can't claim that brokenness according
to the RFC on present evidence.
> OK, if you really want a reason to omit it, there's the fact that
> RFC2822 says if you include one it _MUST_ be unique, and that in fact
> it's actually impossible to guarantee that it's unique in the presence
> of someone actively trying to cause collisions by guessing what
> message-id you might use next... hence by implication you MUST NOT
> include one. But that's too silly :)
>
> > [In my case recently, one of my users' mail was being
> > rejected by one site as they considered the lack of a Message-ID: header
> > to be a sure sign of spam, which I disputed].
>
> But you fixed it and now they have a Message-ID? That's a perfectly
> acceptable 'false positive' from my point of view -- in fact I don't
> even think of it as false positive. You weren't obeying the rules; you
> are now.
Actually not; I'm not operating as an MSA in the case to hand, so the
messages continue to be sent with no Message-ID. I simply advised my
local user pretty much of what we just said (especially the comments about
not relying on it as a sole spam indicator) and he was going to pass them
on to the remote site. I don't know what the next move will be .. but
medium term I should really start operating the MTA with an MSA function
(the end clients have to relay(submit) anyway, they can't send direct,
so I do have some control).
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services
University Of Strathclyde, Glasgow, UK
