Re: [mailop] Google and the Message-Id Header

On 12/10/2019 02:35, Aaron C. de Bruyn via mailop wrote: > By the way...any pointers for watching packets after STARTTLS has been > issued? Wireshark doesn't appear to support decrypting SMTP packets. This depends on your TLS library. With either GnuTLS, or enough application-programming and Ope

Re: [mailop] Google and the Message-Id Header

On Fri, Oct 11, 2019 at 4:55 PM Brandon Long wrote: > 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 e

Re: [mailop] Google and the Message-Id Header

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 m

Re: [mailop] Google and the Message-Id Header

Aaron C. de Bruyn via mailop wrote: On Tue, Oct 8, 2019 at 1:51 PM Bill Cole via mailop > 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

Re: [mailop] Google and the Message-Id Header

On Tue, Oct 8, 2019 at 1:51 PM Bill Cole via mailop 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. on

Re: [mailop] Google and the Message-Id Header

> 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.) some sources (aliexpress!) generate message-id lacking '@' (also '<' and '>') so removed that as a hard-requirement when filtering here

Re: [mailop] Google and the Message-Id Header

I looked through the logs. No duplicate message IDs over a 7-day period. -A On Tue, Oct 8, 2019 at 1:33 PM Chris Wedgwood wrote: > > The second tech arrived at the conclusion that it was the Message-Id > > header. Messages that were delivered had an externally-resolvable domain > > as part of

Re: [mailop] Google and the Message-Id Header

On 8 Oct 2019, at 15:57, Aaron C. de Bruyn via mailop wrote: [...] Maybe I'm getting old and forgetful, but I seem to recall the RFCs saying the Message-Id was nothing more than a tracking identifier and could be complete garbage. Not exactly garbage: if it exists, it needs a '@' and the leg

Re: [mailop] Google and the Message-Id Header

So, nothing disappears, and the logs should definitely have something... though, it might not reach the GSuite logs if the SMTP conversation doesn't reach a point where we can identify the relevant customer (ie, RCPT TO). Also, the only message we give with 451 4.5.0 doesn't start with OK, its "SM

Re: [mailop] Google and the Message-Id Header

> The second tech arrived at the conclusion that it was the Message-Id > header. Messages that were delivered had an externally-resolvable domain > as part of the Message-Id header. Messages that were 'disappeared' had our > internal domain (i.e. whatever.local) as part of the Message-Id. > > I r

[mailop] Google and the Message-Id Header

We have a bunch of satellite offices that relay through our corporate mail gateway. The mail gateway handles things like scan-to-email from copiers, email from our internal fax gateway, etc... Starting Monday morning-ish Google has been one of a few things apparently at random: * Accepting the me