[Top] [All Lists]

Re: [ietf-smtp] test for port 25 of sending MTA - for spam detection

2013-08-23 05:30:18
On Fri, Aug 23, 2013 at 08:16:28AM +0000, Martijn Grooten wrote:
On Fri, 23 Aug 2013, keld wrote:
Just a thought I had for spam detection: what about testing if you could 
connect to port 25 on the sending MTA? Zombies behind a NAT would not be 
able to be reached. I think there are some web-based mailers that could 
be hurt, but maybe one could make a whitelist for those. Is this a known 
scheme, and what are the pros and cons?

I think it's far more common than you think that a sending MTA isn't 
listening on port 25.

But even if all sending MTAs were listening on port 25, or if there was an 
RFC that told them to do so, there are probably more effective ways to 
fight spam from zombies. Methods that work even if the zombie isn't behind 
a NAT. DNSBLs, for example.

Thi idea was to use it as a check in addition to DNSBL etc. 

The advantage over DNSBL is that for DNSBL you first need to register the 
site with DNSBL. The callback is instantaneous. And the call back function 
on circumstances that a spammer is not likely to control, such as port 
on a router, and allowing connections from outside to port 25. Apart from the 
spamer also
delivering a functional MTA, I think this is rare - this is
relying on missing features of the spamming software ala greylisting.

I don't think it adds interoperability issues, as it was something to
optionally add to validity checks.
My idea was to first test it as a score for deciding whether the mail was spam 
or not.
a hack for spamassassin - or maybe postfix .

The whitelisting could also be dynamic, and rely on eg MX records or some other 
DNS records,
again building on reesources that the spammer seldomly has access to control.
In addition some DNSBL positive registrations could also be used.

What do you think? Has this been done before?

Best regards
ietf-smtp mailing list