Re: Malformed List-Id header
On 2/16/2018 12:57 PM, Alex wrote: I think it's a mistake to whitelist (or even deduct significant points) based on a header that can be controlled by a spammer. We see tons of spam that has properly crafted MIDs. If you're using procmail, it sounds like this is on a personal account, so perhaps it's not so bad, but I wouldn't roll this out broadly. It's just for my family domain. If you're going to continue to use this, I'd then suggest at least adding some other qualifiers like SPF or DKIM or !KAM_LAZY_DOMAIN_SECURITY or !FREEMAIL_FROM etc... Agreed. The whitelist rule isn't one I'd spread. It's the other one that catches the malformed header that I mainly want to share. Eventually the bad actors will catch up and fix their header but for now this seems pretty good at spotting "lists" I didn't sign up for. When they DO fix their header, their lists will drop into my Unknown Lists folder and I'll adjust the rule as necessary.
Re: Malformed List-Id header
Hi, On Fri, Feb 16, 2018 at 12:41 PM, Kenneth Porter wrote: > I just put this into service. I'm white-listing mailing lists. Most go to > their own folder via procmail filtering, and unrecognized ones go to the > folder Lists/Unknown until I write a procmail rule. But this rule should > catch lazy abusers. After a bit more experience I'll crank up the punishment > score for those. > > header __KP_LIST_ID_DOMAIN_IN_BRACKETS List-id =~ /<([\w-]+)?(\.[\w-]+)+>/ > > describe KP_LIST_ID_DOMAIN_IN_BRACKETS List-id has domain in angle brackets > meta KP_LIST_ID_DOMAIN_IN_BRACKETS __KP_LIST_ID_DOMAIN_IN_BRACKETS > scoreKP_LIST_ID_DOMAIN_IN_BRACKETS -15.0 > > describe KP_LIST_ID_IMPROPER_FORMAT List-id has improper format > meta KP_LIST_ID_IMPROPER_FORMAT __HAS_LIST_ID && > !__KP_LIST_ID_DOMAIN_IN_BRACKETS > scoreKP_LIST_ID_IMPROPER_FORMAT 0.1 I think it's a mistake to whitelist (or even deduct significant points) based on a header that can be controlled by a spammer. We see tons of spam that has properly crafted MIDs. If you're using procmail, it sounds like this is on a personal account, so perhaps it's not so bad, but I wouldn't roll this out broadly. If you're going to continue to use this, I'd then suggest at least adding some other qualifiers like SPF or DKIM or !KAM_LAZY_DOMAIN_SECURITY or !FREEMAIL_FROM etc...
Re: Malformed List-Id header
I just put this into service. I'm white-listing mailing lists. Most go to their own folder via procmail filtering, and unrecognized ones go to the folder Lists/Unknown until I write a procmail rule. But this rule should catch lazy abusers. After a bit more experience I'll crank up the punishment score for those. header __KP_LIST_ID_DOMAIN_IN_BRACKETS List-id =~ /<([\w-]+)?(\.[\w-]+)+>/ describe KP_LIST_ID_DOMAIN_IN_BRACKETS List-id has domain in angle brackets meta KP_LIST_ID_DOMAIN_IN_BRACKETS __KP_LIST_ID_DOMAIN_IN_BRACKETS scoreKP_LIST_ID_DOMAIN_IN_BRACKETS -15.0 describe KP_LIST_ID_IMPROPER_FORMAT List-id has improper format meta KP_LIST_ID_IMPROPER_FORMAT __HAS_LIST_ID && !__KP_LIST_ID_DOMAIN_IN_BRACKETS scoreKP_LIST_ID_IMPROPER_FORMAT 0.1
Re: Malformed List-Id header
On 2/4/2018 3:35 PM, Kenneth Porter wrote: I've noticed quite a bit of spam lately with a malformed List-Id header. Most notably, the angle brackets are missing, but the contents of the angle brackets when present often don't look like a domain. No dots, for example. <https://www.ietf.org/rfc/rfc2919.txt> It looks like the header has the same format as a To or From header, except that there's no local part or at-sign in the angle brackets. Is there some kind of test already available to validate the format of the to/from headers that I could adapt to validate the List-id header? I don't want to re-invent the wheel and create a new test if one already exists. Ideally I'd like to extract the domain (minus the list name) and run that through the DNSBLs, as well.
Malformed List-Id header
I've noticed quite a bit of spam lately with a malformed List-Id header. Most notably, the angle brackets are missing, but the contents of the angle brackets when present often don't look like a domain. No dots, for example. <https://www.ietf.org/rfc/rfc2919.txt>
