lots of freemail spam
Hi, Lately, I notice we are getting a fair amount (10-12 per day per client) of spam coming from freemail users (FREEMAIL_FROM triggers). Usually the Subject is non-existent or empty, and the message is always just an URL Is there a good rule for flagging these as possible spam? I understand that there may be some legit e-mails that would hit all 3 factors, so I would score the rule low. Thoughts? Regards, Lawrence
Re: lots of freemail spam
On 30/12/10 19:15, Lawrence @ Rogers wrote: > Lately, I notice we are getting a fair amount (10-12 per day per client) > of spam coming from freemail users (FREEMAIL_FROM triggers). Usually the > Subject is non-existent or empty, and the message is always just an URL I see a fair amount matching that description, and corresponding complaints. In the past few weeks there seems to be a shift from Hotmail/MSN/Live to also use cracked Yahoo and AOL/AIM accounts. Someone at the freemail providers should know if passwords are obtained by phishing (such as tabnabbing) or a keylogger or even by a dictionary attack. There's no text to match Bayes or body rules; because the URL is on a cracked site, URIBL_* isn't usually appropriate; because it's from a cracked account, the headers are fine and it may even reach users who've chosen to only accept email from friends/contacts. More of the originating IPs should hit deep-parsing RBLs than actually do. So it could be argued that the nest response is not to block, but to let owners of cracked accounts know they need to change their password and secret questions (or close the account if it can't be recovered), and also to report the cracked sites and originating IPs, possibly by educating users about SpamCop. > Is there a good rule for flagging these as possible spam? I understand > that there may be some legit e-mails that would hit all 3 factors, so I > would score the rule low. > > Thoughts? Something like: meta FREEMAIL_PHARM_PROB((FREEMAIL_FROM + MISSING_SUBJECT + LINK_NR_TOP) >=3) describe FREEMAIL_PHARM_PROBLooks like simple link from cracked account score FREEMAIL_PHARM_PROB 2.5 LINK_NR_TOP is the only additional element needed, to indicate message length: rawbody LINK_NR_TOP /^.{0,20}http:(?http://sourceforge.net/projects/ixhash/> seems to hit a greater percentage than other body checksums (the body being empty or very short). Also there are short-lived patterns in the abusive file uploaded: uri FREEMAIL_PHARM1 /\/mtxtsx\.htm/ describe FREEMAIL_PHARM1Particular link on cracked site, Jan 2011 score FREEMAIL_PHARM1 8.0 uri FREEMAIL_PHARM2 /\/(?:2011\.php\?\w+=\w+$|foto2011\.php|clickhere\.php|important\.php|mywork\.html)/ describe FREEMAIL_PHARM2Particular link on cracked site, Jan 2011 score FREEMAIL_PHARM2 4.0 uri FREEMAIL_PHARM3 /\/\/[a-z0-9A-Z.-]+\/images\/[A-Za-z0-9\-]+\.(?:php|htm)/ describe FREEMAIL_PHARM3Top-level images folder, php or htm extension score FREEMAIL_PHARM3 0.1 HTH CK
Re: lots of freemail spam
I've been thinking, perhaps we should consider making a "Freemail Realtime BL" that lists not IP addresses, but rather ID's at the Freemail provider. 1) I am assuming that ID's you see in headers of mail from Yahoo is always from an authenticated user? 2) Traps and user reports can quickly list a new Freemail user ID. 3) Subsequent spam from that user ID is more easily blocked because the RBL has the ID listed. 4) The RBL feed can be automated to be sent to the provider (like Yahoo) so they can more quickly enforce locking down compromised accounts or enforce their ToS. Warren
Re: lots of freemail spam
On søn 02 jan 2011 13:59:22 CET, "Warren Togami Jr." wrote I've been thinking, perhaps we should consider making a "Freemail Realtime BL" that lists not IP addresses, but rather ID's at the Freemail provider. emailbl was better coded for this purpose imho freemail as is, is perfect as it is now, since its easy to add freemail domain, its easy to whitelist the non spam senders -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: lots of freemail spam
On 2011-01-02 13:59, Warren Togami Jr. wrote: I've been thinking, perhaps we should consider making a "Freemail Realtime BL" that lists not IP addresses, but rather ID's at the Freemail provider. Search the list archives for emailbl 1) I am assuming that ID's you see in headers of mail from Yahoo is always from an authenticated user? 2) Traps and user reports can quickly list a new Freemail user ID. 3) Subsequent spam from that user ID is more easily blocked because the RBL has the ID listed. 4) The RBL feed can be automated to be sent to the provider (like Yahoo) so they can more quickly enforce locking down compromised accounts or enforce their ToS. Search the list archives for emailbl
Re: lots of freemail spam
If I understand that thread correctly, that is for e-mail addresses in body text? I'm suggesting looking only at authenticated UID's in headers from specific providers like Yahoo who are notorious for spam, but their MTA's also send a significant amount of ham so we cannot DNSBL block them. Given that we know the UID's cannot be spoofed (if we verify the delivery with DKIM), such a BL can be safely populated in an automated fashion using spam traps. So this might be more of a "Authenticated User RBL". Warren