I'll admit to not having done this yet, for three reasons: one, given that I found no other references of it here or trawling the web, it's very likely to be a 'last straw' thing and that there's a much deeper root cause which needs to be caught first. two, in relation to one, our toolset is still limited and that includes our ability to shut down specific headers easily. case in point is that just bringing those back to life took effort by itself... and last, I don't want to trouble my users unnecessarily. I don't have enough pristine gmail boxes available that haven't previously interacted with this sender so all testing would have to be done at the expense of users. I'm pretty sure going by that order would yield better results anyway.
I think the right way to go about it is like a glacier - assume this message is representative of x20 more silent rejections and search for a systematic problem. (as an aside, I do have to say it's contradictory to the devops mindset of (tongue-in-cheek) 'monitoring/log entry or it didn't happen' and it's a bit jarring to try and maintain the two together). Regards, Gil Bahat, DevOps/Postmaster, Magisto Ltd. On Mon, Jun 1, 2015 at 5:08 PM, John Levine <jo...@taugh.com> wrote: > >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. > > When you did experiments removing one header at a time to see which one is > causing trouble, what did you find out? > > R's, > John >
_______________________________________________ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
