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 "SMTP protocol violation, see RFC 2821". We only return this when there's an SMTP protocol violation, ie sending commands when you're not allowed. Mostly this is because the sender is trying to use PIPELINING, but it's disabled. The only message that is "OK <some id> - gsmtp" is our 250 OK response when we accept a message. If you can send me the details and the case id #, I can take a look. As for message-ids, they do have a format that's required, and we do replace them when they're not properly formatted, and that replacement can be a signal to the spam engine, as can the domain of the message-id. Everything about the message is fair game for the spam pipeline. Brandon On Tue, Oct 8, 2019 at 12:59 PM Aaron C. de Bruyn via mailop < mailop@mailop.org> wrote: > 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 message from our mail gateway and delivering it to Inbox > or Spam > * Accepting the message from our mail gateway and disappearing it (nothing > in GSuite logs either) > * Rejecting the message with "451 4.5.0 OK <some id> - gsmtp" > > After doing a bunch of testing and finding nothing wrong, I chatted with > GSuite. > > The first tech kept insisting I sign in to gmail and get him mail headers > from the messages that were magically disappearing. I finally convinced > him to escalate me. > > 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 renamed one of the copiers to use our external domain and suddenly it > worked perfectly. > > The moment it was fixed, the tech said the problem was solved and closed > the case. > > 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. > > Can someone at Google shed some light on this? I don't think the correct > fix for this is to spend days updating copiers and fax gateways at tens of > locations...and I'm suspicious that the Message-Id domain is the root cause. > > -A > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
