Subscribing to Haraka mailing list

[sriccio]

Hello Haraka community.

While looking for a place to discuss Haraka things, I registered to the mailing list (successfully) and then tried to post a message to the list (with less success).

When trying to post to the list I get the following NDR:

<[[email protected]](mailto:[email protected])>: host bodger.sergeant.org[216.168.111.245] said: 550
    [C3E7F520-2717-41F1-9146-C27F0E21AEAC.1@ms1vm01] 3397323e.com domain
    registered within the last 15 days; see
http://spameatingmonkey.com/lookup/3397323e.com (in reply to end of DATA
    command)

At first it looked strange to me that the antispam at the target MX is doing some checks on such a domain 3397323e.com.

Then after looking at the headers of the mail sent to the mailing list, I've noticed this "fake" domain is referenced in the Message-ID header and it is generated by the mail client I use (emClient).

Message-ID: <[email protected]>

It looks like emClient (and probably other clients) generate Messages-ID with random "right part" that matches a <[email protected]> pattern to match the recommendation, but where the domain.tld is generated randomly, so doesn't, or at least shoudln't match an existing domain.
https://forum.emclient.com/t/does-em-client-create-the-message-id/56025/6

While it's maybe not the best idea, I find it surprising that the antispam here is checking the domain specified in Message-ID as afaik there are a lot of bogus Message-ID generated here and there from mail clients.

Shouldn't this antispam check be done on on Return-Path / From fields ?

Kind regards.
Sébastien

[msimerson]

Shouldn't this antispam check be done on on Return-Path / From fields?

I would assume the Return-Path and From fields are also being tested. Also, while some ancient (1998) texts did specify an alternate form for Message-ID, only a domain name (recommended: the domain portion of the email address) has been RECOMMENDED for the RHS since RFC 5322:

   The message identifier (msg-id) syntax is a limited version of the
   addr-spec construct enclosed in the angle bracket characters, "<" and
   ">".  Unlike addr-spec, this syntax only permits the dot-atom-text
   form on the left-hand side of the "@" and does not have internal CFWS
   anywhere in the message identifier.

      Note: As with addr-spec, a liberal syntax is given for the right-
      hand side of the "@" in a msg-id.  However, later in this section,
      the use of a domain for the right-hand side of the "@" is
      RECOMMENDED.  Again, the syntax of domain constructs is specified
      by and used in other protocols (e.g., RFC1034, RFC1035,
      RFC1123, RFC5321).  It is therefore incumbent upon
      implementations to conform to the syntax of addresses for the
      context in which they are used.

In this case (SMTP), the context is the public internet, so I'd expect your email client to generate Message-IDs in the recommended format.