Re: TLD blocking revisited
On Tue Sep 20 2016 18:40:17 Sebastian Nielsensaid: > > I would really suggest using DISCARD instead of "500 This TLD sends spam - g > e t lost.". > Thus the spammer dosen't get to know he got stuck in a spam filter and can > update their tools to bypass it. > > DISCARD accepts the mail but throws it into /dev/null The problem is that DISCARD accepts the mail. That is the server has to accept the data connection and receive the data. And there is no evidence that spammers are doing anything other than blasting out, not paying the slightest attention to what is accepted or rejected. I see IPs that have been hitting postscreen for weeks and weeks with no change in the number of connection attempts. Also, this gives me a very specific string to check for to see who is being rejected.
DISCARD vs REJECT (Was: Re: TLD blocking revisited)
On 20 Sep 2016, at 20:40, Sebastian Nielsen wrote: I would really suggest using DISCARD instead of "500 This TLD sends spam - g e t lost.". Thus the spammer dosen't get to know he got stuck in a spam filter and can update their tools to bypass it. Note that in this specific case of junk TLDs, the tool (low-cost domains) is critical to that class of spammer's business model. DISCARD accepts the mail but throws it into /dev/null The debate over this theory of spammer behavior has been going on for at least 20 years and in that time I've never seen convincing evidence that it is more true than an alternative theory that targets which seem to accept spam for delivery (i.e. DISCARD) attract more spam because spammers think they are verified as good targets and peddle their lists of verified deliverable addresses to each other, expanding the number of senders aiming at the apparently unfiltered address. If that behavior dominates, you still get morphing spam making it past content filtering because you have more variety of senders. I have very noisy data collected over 15 years in a smallish spam-heavy domain which suggests that spam sinks (which simply accept and discard all their mail) and spam traps (which feed all their mail into local anti-spam measures) both attract more spam over time at a slightly higher growth rate than aggregate mail or spam for normal addresses in the same domain, but it's not a dramatic or uniform difference. Conversely, dead addresses that reject everything tend to get less mail aimed at them over the long term. In this case, normal users whose mail is either explicitly rejected in SMTP or delivered to their Inbox make up the noisiest subset; attempted spam generally gets worse over time but not always, and delivered spam (false negatives) can go either way. The main conclusion I've reached from that long-term close examination of a small sample and shorter, shallower analyses of much larger systems is that there are no grand universal rules of spam that can apply everywhere to everyone. No one who gets a significant amount of spam aimed at them gets exactly the same spam as anyone else. Some spammers work hard at filter evasion, others do not. Some of those who work very hard at it do so with chronically and ridiculously poor results, at least against *some* common filtering strategies. The balance of competing spammer behavioral theories that form the basis of the REJECT vs. DISCARD argument is close enough overall to be a matter for subjective judgment on any particular mail system, but I think that as a practical matter there are 2 concrete issues that argue for REJECT in all cases where it isn't a recipe for significant backscatter: 1. No anti-spam measures are perfect. If you accept and discard mail that your anti-spam measures deem to be spam, then when they get that judgment wrong and toss out mail you actually would rather have delivered, it may never be noticed as a technical failure by anyone. Internet email is consciously designed to notify senders explicitly of delivery failures, and using DISCARD violates that design. 2. The most effective spam exclusion tactics in a mail system that uses a "defense in depth" model are ones which can detect spam at or before the RCPT command(s), allowing the MTA to reject spam it never actually receives. This spares the MTA from using pointless bandwidth and (more significantly in most cases) from maintaining a session for typically an order of magnitude longer than necessary, just to pipe message data to /dev/null.
Re: TLD blocking revisited
James Reynolds: > I use check_sender_access and DISCARD to throw away about 1500-4000 > messages a day from .top domains (which is about the volume of my > legit email). I looked into it and most of them are registered > to namecheap.com, which appears to sell the names for for $.98 > each. I did a little research into Namecheap's reputation and I > found one thread calling them friendly to spammers. If you have reasons to believe that a certain DNS server is hosting spammer domains, you can use check_client_ns_access, check_helo_ns_access and check_sender_ns_access to block present future spam. It helped me to block a persistent spammer who was constantly changing domain names, but who kept using the same DNS server. Wietse
Re: TLD blocking revisited
I use check_sender_access and DISCARD to throw away about 1500-4000 messages a day from .top domains (which is about the volume of my legit email). I looked into it and most of them are registered to namecheap.com, which appears to sell the names for for $.98 each. I did a little research into Namecheap's reputation and I found one thread calling them friendly to spammers. https://www.webhostingtalk.com/showthread.php?t=700628=4 Not sure what to think about it. James Reynolds On Sep 21, 2016, at 2:31 AM, Allen Coateswrote: > > On 21/09/16 02:35, Jim Reid wrote: > >> Spammers generally don’t pay that level of attention to SMTP responses, far >> less fine-tune their address lists and tools. These morons just find a >> victim host or botnet to blast out crap to a bazillion email addresses, not >> caring if any of them work or not or if their spam makes it as far as >> getting presented to a human victim. > > I will second that. One of my "callers" - blocked by iptables - > has been sending me a couple of packets an hour since 11 August. > > Allen C >
Re: TLD blocking revisited
On 21/09/16 02:35, Jim Reid wrote: > Spammers generally don’t pay that level of attention to SMTP responses, far > less fine-tune their address lists and tools. These morons just find a victim > host or botnet to blast out crap to a bazillion email addresses, not caring > if any of them work or not or if their spam makes it as far as getting > presented to a human victim. I will second that. One of my "callers" - blocked by iptables - has been sending me a couple of packets an hour since 11 August. Allen C
SV: TLD blocking revisited
I have had other experiences with spammers. I suspect there is different spammers out there that spam in different ways. I once got a very irritating spammer that send a lot of spam, that was completely identical, had a identical color in the header and it was really obvious this spammer was the same person/company even if he spammed about lots of different subjects, everything from auto insurance to pills to earn money. Then I blocked his domain (blablabla.tld) in my postfix config, and had it set to reject. Just a day after, he "started" spamming from a new domain, that was very similiar to the first. I knew it was the same person/company of the color. I kept on blocking, and the spammer kept on changing. Then I changed to DISCARD before blocking his new domain. Bam, that spam gone. I got a very few one with the same color in the header (before it was a few mails per hour), but eventually, it vanished. My log however, listed a lot of discards. So I suspect that was a spammer that have got some sort of "verified list" (eg, those high price adress lists that are known to be valid) and spammed a few, propably in the area of hundreds of mails, and had good handling for bans/blocklists/ and propably for greylisting too, to keep their head under the radar. So its just a tradeoff. Spam mails are today pretty small just to not trigger "huge-mail-alerts" so they consume minimal with bandwith and CPU cycles, but causes far much more "damage" in time spent for the user deleting the crap from the inbox. But I agree, that if you get those "regular" spammers that doesn't pay attention to RFCs at all, then its better rejecting it. -Ursprungligt meddelande- Från: Jim Reid [mailto:j...@rfc1035.com] Skickat: den 21 september 2016 03:36 Till: Sebastian Nielsen <sebast...@sebbe.eu> Kopia: Postfix Users <postfix-users@postfix.org> Ämne: Re: TLD blocking revisited smime.p7s Description: S/MIME Cryptographic Signature
Re: TLD blocking revisited
> On 21 Sep 2016, at 01:40, Sebastian Nielsenwrote: > > I would really suggest using DISCARD instead of "500 This TLD sends spam - g > e t lost.". > Thus the spammer dosen't get to know he got stuck in a spam filter and can > update their tools to bypass it. Spammers generally don’t pay that level of attention to SMTP responses, far less fine-tune their address lists and tools. These morons just find a victim host or botnet to blast out crap to a bazillion email addresses, not caring if any of them work or not or if their spam makes it as far as getting presented to a human victim. Then move on to the next victim host/botnet and repeat with the same list of a bazillion email addresses. Or an even bigger list. Once the spam generating software’s fingerprints eventually get spotted by SpamAssassin or whatever, a spammer will just throw that generator away and either tweak it a little or get a new one. Repeat. FWIW I see the same bogus recipient email addresses (which never existed) repeatedly showing up in most of the spam attempts which arrive here. Clearly, those addresses are being swapped/traded by spammers or I have one very persistent spammer who only uses the same addresses over and over again. Either way, they don’t care that RCPT TO fails because they’re trying to deliver to email addresses that have never existed. If spammers did as you seem to think, these addresses would have been deleted from their lists a long time ago. They haven’t. > DISCARD accepts the mail but throws it into /dev/null True. But it means the spammmer still gets to burn your bandwidth and your CPU cycles as they deliver crap to your /dev/null. That does not seem sensible to me. YMMV. Saying "500 This TLD sends spam - get lost” usually kills the SMTP session *well before* the DATA part of the handshake. So you don’t receive the spam payload. The message doesn’t get to your server. You also get the satisfaction of saying something rude back at the scumbag that was sending spam. Which eases the blood pressure even if it has no impact on that scumbag. You’ve made your choices. I’ve made mine. We’re both happy with the ones we made.
SV: TLD blocking revisited
I would really suggest using DISCARD instead of "500 This TLD sends spam - g e t lost.". Thus the spammer dosen't get to know he got stuck in a spam filter and can update their tools to bypass it. DISCARD accepts the mail but throws it into /dev/null -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För li...@lazygranch.com Skickat: den 21 september 2016 02:23 Till: Jim Reid <j...@rfc1035.com> Kopia: Postfix Users <postfix-users@postfix.org> Ämne: Re: TLD blocking revisited Tell ya what. Let's hold the suggestions here. This one looks like something I can handle. (I really need things spelled out.) BTW, the SpamAssassin enlist trick caught about 20% of this flavor of spam. But I'm really OK will killing the TLD. I did some googling on this and some claim Baracuda has this spam style licked, but I don't find that to be the case. I do have Baracuda as my first RBL. I didn't mention it but the odd thing is this .stream spam goes to one email account. Perhaps in a daze I clicked unsubscribe. Thanks all for the suggestions. Original Message From: Jim Reid Sent: Tuesday, September 20, 2016 1:56 PM To: li...@lazygranch.com Cc: Postfix Users Subject: Re: TLD blocking revisited > On 20 Sep 2016, at 21:10, li...@lazygranch.com wrote: > > What is the simplest way to block a TLD? Put the offending TLD in a map and have that map referenced through check_sender_access and/or check_client_access. ie in main.cf: smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/spamsources mtpd_sender_restrictions = permit_mynetworks check_sender_access hash:/etc/postfix/spamsources and in /etc/postfix/spamsources: xyz 500 This TLD sends spam - get lost. smime.p7s Description: S/MIME Cryptographic Signature
Re: TLD blocking revisited
Tell ya what. Let's hold the suggestions here. This one looks like something I can handle. (I really need things spelled out.) BTW, the SpamAssassin enlist trick caught about 20% of this flavor of spam. But I'm really OK will killing the TLD. I did some googling on this and some claim Baracuda has this spam style licked, but I don't find that to be the case. I do have Baracuda as my first RBL. I didn't mention it but the odd thing is this .stream spam goes to one email account. Perhaps in a daze I clicked unsubscribe. Thanks all for the suggestions. Original Message From: Jim Reid Sent: Tuesday, September 20, 2016 1:56 PM To: li...@lazygranch.com Cc: Postfix Users Subject: Re: TLD blocking revisited > On 20 Sep 2016, at 21:10, li...@lazygranch.com wrote: > > What is the simplest way to block a TLD? Put the offending TLD in a map and have that map referenced through check_sender_access and/or check_client_access. ie in main.cf: smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/spamsources mtpd_sender_restrictions = permit_mynetworks check_sender_access hash:/etc/postfix/spamsources and in /etc/postfix/spamsources: xyz 500 This TLD sends spam - get lost.
Re: TLD blocking revisited
On 20 Sep 2016, at 16:10, li...@lazygranch.com wrote: After studying these spam messages, I think postfix blocking via tld is the only solution. The problem is the message is embedded in graphics with brief text regarding "if you can't view this click here". There isn't enough to trip the spam bot. What is the simplest way to block a TLD? A check_sender_access restriction in the smtpd_recipient_restrictions list.
Re: TLD blocking revisited
> On 20 Sep 2016, at 21:10, li...@lazygranch.com wrote: > > What is the simplest way to block a TLD? Put the offending TLD in a map and have that map referenced through check_sender_access and/or check_client_access. ie in main.cf: smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/spamsources mtpd_sender_restrictions = permit_mynetworks check_sender_access hash:/etc/postfix/spamsources and in /etc/postfix/spamsources: xyz 500 This TLD sends spam - get lost.
SV: TLD blocking revisited
Im using the following to block TLDs, but not in helo checks, im using sender checks instead: /\.bid$/ DISCARD /\.top$/ DISCARD /\.xyz$/ DISCARD /\.pro$/ DISCARD /\.date$/ DISCARD /\.faith$/ DISCARD /\.download$/ DISCARD DISCARD blocks the mail without telling the sender the mail was blocked so spammers can't retry until they get the crap through. smime.p7s Description: S/MIME Cryptographic Signature
Re: TLD blocking revisited
On Tue Sep 20 2016 14:10:17 li...@lazygranch.comsaid: > > After studying these spam messages, I think postfix blocking via tld is the > only solution. The problem is the message is embedded in graphics with brief > text regarding "if you can't view this click here". There isn't enough to > trip the spam bot. > > What is the simplest way to block a TLD? This is what I am doing, and it is working (for me) great. helo_checks.pcre: /.*\.(com|net|org|edu|gov|ca|mx|de|dk|fi|uk|us|eu|es|jp|il|it|nl|info|biz|name)$/ DUNNO /.*\.*/ 550 Mail for this TLD is not allowed Obviously, you will need to see what TLDs are used for valid mail on your system, but that list works for me. grep -o "helo=<.*>" /var/log/maillog* | egrep -o "\.[^.]+>" | cut -c 2- | sed 's/[0-9]*\]*>//' | sort -u That will give you all your TLDs without showing if they are valid mail. I am still getting hammered with spammers using .top .stream and .xyz, but if they make it past post screen, they get dropped ny helo_checks. I am probably removing biz from my exclusion list. I do have some valid mail from .biz, but it looks like it is exclusively list mail, so the helo checks would not come into play. I will check the logs again in a couple of months and see how much, if any, is valid.
Re: TLD blocking revisited
On 2016-09-20 22:10, li...@lazygranch.com wrote: After studying these spam messages, I think postfix blocking via tld is the only solution. The problem is the message is embedded in graphics with brief text regarding "if you can't view this click here". There isn't enough to trip the spam bot. What is the simplest way to block a TLD? bind9 rpz
Re: TLD blocking revisited
After studying these spam messages, I think postfix blocking via tld is the only solution. The problem is the message is embedded in graphics with brief text regarding "if you can't view this click here". There isn't enough to trip the spam bot. What is the simplest way to block a TLD?
Re: TLD blocking revisited
Believe it or not, Tellus doesn't support encryption. https://www.reddit.com/r/canada/comments/464glo/psaif_you_use_a_telus_email_account_telus_does/?st=itb9thrx=2a6ed83e I think when Google starts to refuse unencrypted email, it would make sense for postfix to bounce them. Original Message From: Alice Wonder Sent: Tuesday, September 20, 2016 1:49 AM To: postfix-users@postfix.org Subject: Re: TLD blocking revisited On 09/19/2016 05:29 PM, li...@lazygranch.com wrote: > The last time TLD blocking came up, the consensus of the hive was not > to block based on TLD. (You may recall .xyz being used by > Alphabet.) However lately I'm getting a ridiculous number of .stream > SPAM coming through. The RBLs are getting about half. I don't block by TLD but I do have a single mail server that breaks the RFC by rejecting any mail not sent via STARTTLS and interestingly is doesn't get much spam at all. Seems a lot of spammers don't bother with TLS while most legitimate mail does. Maybe (for now) that's a better metric? Legitimate mail that doesn't use TLS tends to be blog notifications, for what its worth.
Re: TLD blocking revisited
On 09/19/2016 05:29 PM, li...@lazygranch.com wrote: The last time TLD blocking came up, the consensus of the hive was not to block based on TLD. (You may recall .xyz being used by Alphabet.) However lately I'm getting a ridiculous number of .stream SPAM coming through. The RBLs are getting about half. I don't block by TLD but I do have a single mail server that breaks the RFC by rejecting any mail not sent via STARTTLS and interestingly is doesn't get much spam at all. Seems a lot of spammers don't bother with TLS while most legitimate mail does. Maybe (for now) that's a better metric? Legitimate mail that doesn't use TLS tends to be blog notifications, for what its worth.
Re: TLD blocking revisited
https://topicdesk.com/downloads/tutorials/spamassassin-filter-for-new-tlds-xyz-info-ninja-etc/ I used this, more or less. It wasn't exactly set up for freebsd. The directory needed is at /usr/local/etc/mail/spamassassin PS: Benny, is that your real email address? I'd like to take this off the list. On Tue, 20 Sep 2016 04:12:48 +0200 Benny Pedersenwrote: > On 2016-09-20 04:08, li...@lazygranch.com wrote: > > OK. Would I score it in SpamAssassin? If not, where? Point me in the > > right direction and I assume Google will be my friend. > > make a tld list in enlist, score that enlist in spamassassin, if need > more help mail me
Re: TLD blocking revisited
On 2016-09-20 04:08, li...@lazygranch.com wrote: OK. Would I score it in SpamAssassin? If not, where? Point me in the right direction and I assume Google will be my friend. make a tld list in enlist, score that enlist in spamassassin, if need more help mail me
Re: TLD blocking revisited
OK. Would I score it in SpamAssassin? If not, where? Point me in the right direction and I assume Google will be my friend. Original Message From: Michael J Wise Sent: Monday, September 19, 2016 6:54 PM To: postfix-users@postfix.org Subject: Re: TLD blocking revisited Block? No. +Score? Yes. But this is the Postfix list, and ... this really belongs elsewhere. > The last time TLD blocking came up, the consensus of the hive was not > to block based on TLD. (You may recall .xyz being used by > Alphabet.) However lately I'm getting a ridiculous number of .stream > SPAM coming through. The RBLs are getting about half. Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause.
Re: TLD blocking revisited
Block? No. +Score? Yes. But this is the Postfix list, and ... this really belongs elsewhere. > The last time TLD blocking came up, the consensus of the hive was not > to block based on TLD. (You may recall .xyz being used by > Alphabet.) However lately I'm getting a ridiculous number of .stream > SPAM coming through. The RBLs are getting about half. Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause.
Re: TLD blocking revisited
Well yeah, they can always buy a .com, etc., but right now .stream has nothing legit. The last time this discussion came up (not initiated by me if it matters), I bought into TLD blocking being bad, but things are different half a year later. I suppose I can find a more effective RBL, but the more you add, the more likely you get false positives. Original Message From: /dev/rob0 Sent: Monday, September 19, 2016 6:11 PM To: postfix-users@postfix.org Reply To: postfix-users@postfix.org Subject: Re: TLD blocking revisited On Mon, Sep 19, 2016 at 05:29:51PM -0700, li...@lazygranch.com wrote: > The last time TLD blocking came up, the consensus of the hive was > not to block based on TLD. (You may recall .xyz being used by > Alphabet.) However lately I'm getting a ridiculous number of > .stream SPAM coming through. The RBLs are getting about half. > > https://www.spamhaus.org/statistics/tlds/ > > I have a hard time believing I will ever get legit mail from a > .stream or a .download. The thing is, I don't think any TLD prescreens its registrants and limits domains to spammers only. Anyone can buy one of the new domains, whether or not a spammer. > FWIW, many of the .stream pass SPF, which is perhaps why the RBLs > are not being as aggressive. Certainly not a factor. Most significant DNSBLs operate on the basis of spamtraps. If a host is hitting a spamtrap, it will be listed; if not it will not be listed. FCrDNS and other niceties are irrelevant. The DNSBL knows that the traffic is spam, because a good spamtrap is an address which was never used. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: TLD blocking revisited
On Mon, Sep 19, 2016 at 05:29:51PM -0700, li...@lazygranch.com wrote: > The last time TLD blocking came up, the consensus of the hive was > not to block based on TLD. (You may recall .xyz being used by > Alphabet.) However lately I'm getting a ridiculous number of > .stream SPAM coming through. The RBLs are getting about half. > > https://www.spamhaus.org/statistics/tlds/ > > I have a hard time believing I will ever get legit mail from a > .stream or a .download. The thing is, I don't think any TLD prescreens its registrants and limits domains to spammers only. Anyone can buy one of the new domains, whether or not a spammer. > FWIW, many of the .stream pass SPF, which is perhaps why the RBLs > are not being as aggressive. Certainly not a factor. Most significant DNSBLs operate on the basis of spamtraps. If a host is hitting a spamtrap, it will be listed; if not it will not be listed. FCrDNS and other niceties are irrelevant. The DNSBL knows that the traffic is spam, because a good spamtrap is an address which was never used. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: TLD blocking revisited
On 2016-09-20 02:29, li...@lazygranch.com wrote: The last time TLD blocking came up, the consensus of the hive was not to block based on TLD. (You may recall .xyz being used by Alphabet.) However lately I'm getting a ridiculous number of .stream SPAM coming through. The RBLs are getting about half. https://www.spamhaus.org/statistics/tlds/ none have being dmarc pass yet imho its maybe time to make url repution in spamassassin ? i have seen spam from dmarc pass google.com what a world to live in
TLD blocking revisited
The last time TLD blocking came up, the consensus of the hive was not to block based on TLD. (You may recall .xyz being used by Alphabet.) However lately I'm getting a ridiculous number of .stream SPAM coming through. The RBLs are getting about half. https://www.spamhaus.org/statistics/tlds/ I have a hard time believing I will ever get legit mail from a .stream or a .download. FWIW, many of the .stream pass SPF, which is perhaps why the RBLs are not being as aggressive. Example: -- SPF record lookup and validation for: recentirn.stream SPF records are published in DNS as TXT records. The TXT records found for your domain are: v=spf1 a mx ip4:104.148.96.0/24 -all Checking to see if there is a valid SPF record. Found v=spf1 record for recentirn.stream: v=spf1 a mx ip4:104.148.96.0/24 -all evaluating... SPF record passed validation test with pySPF (Python SPF library)! - SPF record lookup and validation for: qeonar.stream SPF records are published in DNS as TXT records. The TXT records found for your domain are: v=spf1 a mx ip4:107.173.0.0/24 -all Checking to see if there is a valid SPF record. Found v=spf1 record for qeonar.stream: v=spf1 a mx ip4:107.173.0.0/24 -all evaluating... SPF record passed validation test with pySPF (Python SPF library)! -- Yada yada yada.