Expiry Bot email: increased spam score due to invalid message-id

rspamd is increasing the spam score on the LE expiry bot emails due to an invalid message-id:

Jan 20 18:11:54 myhostname postfix/cleanup[18438]: B94119E08DB: message-id=<20160121T001153.4915656585517594901.Let's Encrypt Expiry Bot <expiry@letsencrypt.org>> Jan 20 18:11:55 myhostname rmilter[800]: spamdscan: scan qid: <B94119E08DB>, mid: <20160121T001153.4915656585517594901.Let's Encrypt Expiry Bot <expiry@letsencrypt.org>, 0.195007, localhost, metric: default: [4.190000 / 15.000000], symbols: RWL_MAILSPIKE_POSSIBLE(0.00), FORGED_SENDER(0.29), RCVD_IN_DNSWL_NONE(0.00), R_SPF_ALLOW(-1.50), URIBL_GREY(1.50), R_DKIM_ALLOW(-1.10), INVALID_MSGID(5.00)

At first glance, the extra <> and whitespace may be an issue per RFC 2822. Fortunately, the email is below spam threshold so the LE bot isn’t being flagged as spam, but it would be nice to reduce the probability of getting flagged. Thanks!


Logcheck made me aware of the broken (or at least unusal) message-ids.

RFC2822 says:

Semantically, the angle bracket characters are not part of the
msg-id; the msg-id is what is contained between the two angle bracket

So my interpretation would be that the usage of angle brackets in the message-id should be avoided.

IMHO the message-id should look like this:


I'm pretty sure there are more parsers out there (beside spamassassin) that will stumble across this "unique" form of message-id.

1 Like

This is indeed an invalid message-id per the RFC. Each part of the message-id (the bits on either side of the ‘@’) may be composed of one or more “dot-atom-text” characters, which are defined as any alpha or numeric character, or a finite list of punctuation; whitespace is not permitted, nor are the <> characters.

Incidentally, Google’s servers re-write this invalid message-id:
Message-ID: <56a4fa1f.8151250a.816e0.746aSMTPIN_ADDED_BROKEN@mx.google.com> X-Google-Original-Message-ID: <20160124T162151.6591568688987624325.Let's Encrypt Expiry Bot <expiry@letsencrypt.org>>
They’re very opaque on what goes into deciding what is or is not spam, though, so I have no idea if this bumped the score up at all or not; the two notifications I’ve so far received, though, were not flagged as spam, so that’s something.

In any case, though, absolutely this should be fixed.

Opened boulder #1446 for this issue.

As good as LE (hopefully) is as a CA, it’s frightening how little they know about a primordial matter such as mail. A message-id in that form? Anyone who has looked at complete mail headers more than a handful of times knows that can’t be right.

LE, if you don’t know about a technology, why are you rolling your own and not using one of the thousands of mail implementations?

boulder #1197 was in the same league. These are not simple bugs. These are lacking fundamental knowledge.

I can only hope you know your crypto better than you know mail.