Thinking this can be of public interest, turns out that when enabling tracking headers, a certain class of messages also got an additional "From:" header, making it non RFC2822 compliant. This went past the radar and past a few controls that should have caught it (e.g. an outbound spam filter).
I'd wager this is a rare incident type, but better error reporting with regards or better controls at ESPs are something to consider (my own coding mistake notwithstanding, I admit i'll take any assistance afforded at me to save me from shooting myself at the foot, so to speak) The core of the problem is still poor mailing practices which we're working on rectifying. Thanks to everybody who assisted with this. Regards, Gil Bahat, DevOps/Postmaster, Magisto LTd. On Mon, Jun 1, 2015 at 9:05 PM, Gil Bahat <g...@magisto.com> wrote: > 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
