We've been using these headers for over a year with the previous ESP. it is nothing inherent to the headers per se, it's a correlation of these headers and other factors. but one of these headers does seem to carry a penalty or otherwise skews detection.
and here's where catch-22 strikes: when removing postmaster IDs and list-ids, we're denying ourselves of one of the best resources to get feedback on our email activity (the yandex.ru and mail.ru postmaster consoles). and since this is an ESP migration, SNDS indicators have yet to stabilize for the IPs and a lot of our toolset has yet to be migrated or developed... but at least we know we have a significant problem needs pursing, so we have that going for us which is nice. sorts of. Regards, Gil Bahat, DevOps/Postmaster, Magisto Ltd. On Sun, May 31, 2015 at 6:27 PM, Al Iverson <aiver...@spamresource.com> wrote: > Well, I think you're going to have to narrow it down to which headers are > actually causing it, if that's actually the case. > > Almost all ESPs add a list-unsub header. We know that alone doesn't cause > Gmail blocking. > I also add X-Auto-Response-Suppress and auto-submitted headers to some > automated reporting output that gets sent a few hundred times a day and I > know that those aren't getting blocked by Gmail. > So there's the first few to remove from your testing protocol. > > Regards, > Al Iverson > > On Sun, May 31, 2015 at 8:44 AM, Gil Bahat <g...@magisto.com> wrote: > >> Hi all, >> >> In the process of changing ESPs, we have turned off some ancillary >> headers until the new backend code supported them. >> The headers we used (among others) included: list-id (requested by >> yandex.ru postoffice console, auto-submitted (suggested on this list to >> quiesce automatic responses), X-Postmaster-Msgtype (requested by mail.ru >> postmaster console), list-unsubscribe (recommended by gmail best practices) >> and X-Auto-Response-Suppress (alternative standard for MS systems and >> clients to quiesce automatic responses) >> >> the moment these have been re-instated, google started throwing (at least >> part) of our emails visibly in MTA logs: >> >> 550 5.7.1 [XX.XX.XX.XX 12] Our system has detected that this message is >> likely unsolicited mail. To reduce the amount of spam sent to Gmail, this >> message has been blocked. Please visit >> http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for >> more information. >> >> this is baffling. has anyone else ever encountered this situation? why >> would adding any of these have such a dramatic impact on whether a given >> e-mail is spam or not? >> >> Regards, >> >> Gil Bahat, >> DevOps/Postmaster, >> Magisto Ltd. >> >> _______________________________________________ >> mailop mailing list >> mailop@mailop.org >> http://chilli.nosignal.org/mailman/listinfo/mailop >> >> > > > -- > Al Iverson | Minneapolis, MN | (312) 725-0130 > aliverson.com | spamresource.com | @aliverson > > _______________________________________________ > mailop mailing list > mailop@mailop.org > http://chilli.nosignal.org/mailman/listinfo/mailop > >
_______________________________________________ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
