Re: TLD blocking revisited

[@lbutlr]

On Tue Sep 20 2016 18:40:17 Sebastian Nielsen    said:
> 
> 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)

[Bill Cole]

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

[Wietse Venema]

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

[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.

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 Coates  wrote:

> 
> 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

[Allen Coates]

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

[Jim Reid]

> On 21 Sep 2016, at 01: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.

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.

Re: TLD blocking revisited

[lists]

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

[Bill Cole]

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

[Jim Reid]

> 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

[@lbutlr]

On Tue Sep 20 2016 14:10:17 li...@lazygranch.com 
said:
> 
> ‎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

[Benny Pedersen]

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

[lists]

‎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

[lists]

‎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

[Alice Wonder]

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

[li...@lazygranch.com]

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 Pedersen  wrote:

> 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

[Benny Pedersen]

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

[lists]

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

[Michael J Wise]

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

[lists]

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

[/dev/rob0]

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

[Benny Pedersen]

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