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
offending
site with DNSBL. The callback is instantaneous. And the call back function
relies
on circumstances that a spammer is not likely to control, such as port
forwarding
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
keld
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp