At this point, it looks like the message-id header is a red-herring (or an indication of a different path on their side), the problem is a bug in the proxying mail server (haraka) issuing multiple EHLO commands after STARTTLS, but only expecting a single reply... so when it issues the rest of the mail transaction, it maps the replies to the extra commands to the commands it thinks it issues, and thus doesn't see us give them an error response for bad pipelining and thinks the message was successfully delivered.
Frankly, looking at the haraka code involved, I would be very careful using that code. I'm not familiar enough with node and javascript to find the bug (or the code on github doesn't match), but the async code involved is way underspecified in terms of state machine and validation (ie, it basically assumes any response not starting with 4/5 is ok, instead of looking for specific codes... and therefore thinks a 250 is an ok go ahead for DATA, and doesn't log the error or the fact the server closed the connection on it) Also, apparently we have a bug where we don't error out if EHLO commands are pipelined (they are also sync points in RFC 2920 3.1), which would have at least made a visible failure their code would have seen. (God I'm thankful we converted our servers from async to threaded, https://www.youtube.com/watch?v=bzkRVzciAZg, get off my lawn ;) Brandon On Thu, Oct 10, 2019 at 9:13 PM Michelle Sullivan via mailop < [email protected]> wrote: > Aaron C. de Bruyn via mailop wrote: > > On Tue, Oct 8, 2019 at 1:51 PM Bill Cole via mailop <[email protected] > > <mailto:[email protected]>> wrote: > > > > Not exactly garbage: if it exists, it needs a '@' and the legal > > content > > is slightly less permissive than the 'addr-spec' definition (i.e. > > email > > addresses.) Also, it must be unique, so using a real fully qualified > > hostname (i.e. one that no one else will use) is useful. OR: use > > none, > > and have your gateway generate one. > > > > https://tools.ietf.org/html/rfc5322#section-3.6. > > > > > > Yeah--I should have been clearer when I said 'garbage'. > > I was pretty sure vaguely-readable line-noise separated by an @ > > qualifies. :) > > > As far as I am aware the 'domain side' of the @ in a message ID has no > requirement to be a valid domain. The message id should be unique - but > remember that is not just across your email system it is also across any > destination email systems (any email system where the email might reach > either as destination or transit) so using your own domain is a good > thing. Using <anything>.local is more likely to collide with other mail > servers not using their own domain names. All that said, message > servers that generate .local message ids are usually configured to see > .local internally and will often communicate internally with '.local' so > it could be the same messages were reporting 'helo' fields of > 'hostname.local' which is often a sign of something internal > misconfigured or malicious... and many systems will use heuristics on > received lines/components for weighting towards spam. > > Regards, > > Michelle > > -- > Michelle Sullivan > http://www.mhix.org/ > > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
