A future-proof list that complies with GDPR would automatically rewrite the To header, leaving the list address only. Any other recipient will still receive it from the original sender.
On Thu, Feb 28, 2019 at 20:29, Mike Marynowski <mi...@singulink.com> wrote: > Unfortunately I don't see a reply-to header on your messages. What do > you have it set to? I thought mailing lists see who is in the "to" > section of a reply so that 2 copies aren't sent out. The "mailing list > ethics" guide I read said to always use "reply all" and the mailing list > system takes care of not sending duplicate replies. > > I removed your direct email from this reply and only kept the mailing > list address, but for the record I don't see any reply-to headers. > > On 2/28/2019 2:21 PM, Bill Cole wrote: >> Please respect my consciously set Reply-To header. I don't ever need 2 >> copies of a message posted to a mailing list, and ignoring that header >> is rude. >> >> On 28 Feb 2019, at 13:28, Mike Marynowski wrote: >> >>> On 2/28/2019 12:41 PM, Bill Cole wrote: >>>> You should probably put the envelope sender (i.e. the SA >>>> "EnvelopeFrom" pseudo-header) into that list, maybe even first. That >>>> will make many messages sent via discussion mailing lists (such as >>>> this one) pass your test where a test of real header domains would >>>> fail, while it it is more likely to cause commercial bulk mail to >>>> fail where it would usually pass based on real standard headers. >>>> (That's based on a hunch, not testing.) >>> >>> Hmmm. I'll have to give some more thought into the exact headers it >>> decides to test. I'm not sure if my MTA puts in envelope info into >>> the SA request or not. For sake of simplicity right now I might just >>> ignore mailing lists, I don't know. What I do know is that in the >>> spam messages I'm reviewing right now, the reply-to / from headers >>> set often don't have websites at those domains and none of them are >>> masquerading as mailing lists. I haven't thought through the >>> situation with mailing lists yet. >>> >>> I'm new to this whole SA plugin dev process - can you suggest the >>> best way to log the full requests that SA receives so I can see what >>> info it is getting and what I have to work with? >> >> The best way to see far too much information about what SA is doing is >> to add a "-D all" to the invocation of the spamassassin script. You >> can also add that to the flags used by spamd, if you want to punish >> your logging subsystem >>
