Thanks Brandon, We actually just got to that realization as well, and in hindsight it looks pretty trivial:
We indeed separate different email product functions by different list identifications. when we re-activated them, we immediately 'aided' gmail (and others) back to discerning our misbehaving functions from our more well-behaving ones. So, this is actually very good for us, as we can now tell which functions are possibly less desired by our users, or causes redundant e-mails, etc. it actually makes a case for reactivation - there's no need to risk more broad blocks just to push through undesired/problematic e-mails. >From a technical standpoint, I'd imagine any of these headers could possibly trigger it but I'd assume that list-id is a solid choice for a silo differentiator. I'll follow-up off-list from here. Regards, Gil Bahat, DevOps/Postmaster, Magisto Ltd. On Mon, Jun 1, 2015 at 8:54 PM, Brandon Long <bl...@google.com> wrote: > I would imagine that list-id or list-unsubscribe would allow for > discrimination by the type of mail sent by a sender. Ie, a host like > Google Groups or Yahoo Groups has millions of different silos, and it would > make sense to treat those differently. > > And we definitely combine signals in multiple ways. You've stripped any > identifying information from that response, so I can't investigate more to > know what's actually going on, but feel free to contact me off list with > more information and I can take a look to see if we have an issue. > > Brandon > > On Mon, Jun 1, 2015 at 7:35 AM, Gil Bahat <g...@magisto.com> wrote: > >> 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 >> >> >
_______________________________________________ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
