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

From: [email-masked]
Date: Fri, 23 Aug 2013 03:27:47 +0200

Hi

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?

best regards
keld

---

From: Martijn Grooten <[email-masked]>
Date: Fri, 23 Aug 2013 08:16:28 +0000 (UTC)

On Fri, 23 Aug 2013, keld wrote:
> 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 

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.

Martijn.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 23 Aug 2013 08:29:45 +0100

> scheme, and what are the pros and cons?

I've often wished SMTP had the equivalent of "dial back" that is in XMPP.  But it's too late to be worrying about that now, because it means an extension, and now you've got the whole problem of interoperability … again.

Cheers,
Sabahattin

---

From: [email-masked]
Date: Fri, 23 Aug 2013 12:30:05 +0200

> 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

---

From: Martijn Grooten <[email-masked]>
Date: Fri, 23 Aug 2013 12:31:21 +0000 (UTC)

On Fri, 23 Aug 2013, keld wrote:
> The advantage over DNSBL is that for DNSBL you first need to register 
> the offending site with DNSBL.

Not necessarily. See for instance http://www.spamhaus.org/pbl/

FWIW, I just checked the sending IP addresses a bunch of spam emails that 
weren't listed at Spamhaus ZEN at time of delivery. A significant minority 
of them (~ 40%) was listening on port 25.

At the same time, several IP addresses that were sending legitimate email 
weren't.

Perhaps, if you do it very carefully, adding a tiny score for emails 
delivered from an IP address that wasn't listening on port 25 will improve 
your filter's performance by 0.03%.

Or perhaps it won't.

Martijn.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 23 Aug 2013 07:45:59 -0400

>> I think it's far more common than you think that a sending MTA isn't

I believe it's common for companies with large mail volume to separate
the inbound and outbound mail to different servers.  A result of that
may be that their outbound servers don't listen on port 25.

That said: have you done a feasibility study on this?  Have you tried
putting into your inbound SMTP server, recorded the results, and
analyzed them to determine the effectiveness and false-positive rate?

Barry

---

From: Bart Schaefer <[email-masked]>
Date: Fri, 23 Aug 2013 07:35:58 -0700

Have we already forgotten the craze for this kind of thing a few years
ago?  Here's an illustrative blog post I pulled up with a quick search
on "smtp callback":

http://spam-vs-freedom.blogspot.com/2006/11/one-more-way-spammers-damage-email.html

AOL was in fact doing "call back to port 25 on the sending IP" for a
while, I still have a rack of mail servers that ought to be outbound
only but which are EHLOing (and then rejecting everything) on port 25
because of this foolishness.

---

From: "John Levine" <[email-masked]>
Date: 23 Aug 2013 14:38:50 -0000

>connect to port 25 on the sending MTA?

So long as you don't want to get any mail from Yahoo, Google, Hotmail,
AOL, Comcast, or anyone else who uses separate inbound and outbound
servers, it should work great.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Fri, 23 Aug 2013 09:23:31 -0700 (PDT)

> At the same time, several IP addresses that were sending legitimate email

This is actually very common, and the larger the provider the more likely it's
going to be. Large providers use different systems for inbound versus outbound
versus submission versus AS/AV. Separation of function makes all sorts of sense
when you're talking about deployments with hundreds or even thousands of
individual systems.

> Or perhaps it won't.

A wash if you're lucky.

				Ned

---

From: [email-masked]
Date: Fri, 23 Aug 2013 19:18:32 +0200

> when you're talking about deployments with hundreds or even thousands of

Yes I understand that large organisations have separate receiving and sending MTAs.
As they are large, they can probably be identified in some way.
Maybe by the block owner of the IP address. Or some reverse lookup.
 I do recoqnise that this is probably the hard part.
A DNSWL  (DNS White List ala DNSBL) would probably be a part of the system.

I am not talking about sender address verification, but rather
something like sender MTA verification.
And I did not want to see if the MTA is SMTP compliant, I just want to
see if port 25 is open, a ping would do.

Oh, I see there is dnswl.org. So simple solution: Ping sender IP, if Open then OK, 
if not then ask dnswl.org. Would that do it? Has it been done?

Best regards
keld

---

From: "John Levine" <[email-masked]>
Date: 23 Aug 2013 17:25:17 -0000

>As they are large, they can probably be identified in some way.

My mail system is tiny, and it uses separate inbound and outbound IPs.

This is a Known Bad Idea.  Really.

R's,
John

PS: I guess I should add it to the wiki at wiki.asrg.sp.am.

---

From: [email-masked]
Date: Fri, 23 Aug 2013 20:33:45 +0200

> analyzed them to determine the effectiveness and false-positive rate?

Not yet, I need to have enough spam mail to test on. For the good mail
I could probably just use my mail archive.

Best regards
Keld

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Fri, 23 Aug 2013 11:58:10 -0700

> I could probably just use my mail archive.

Last I checked this (four years ago, as part of a broader survey on best 
practices), I was startled by the number of zombies that listened on 
port 25 and answered an EHLO response. Open relays, same problem. It 
wasn't huge, but it was enough that I'd never consider using it for 
whitelisting.

The range of legit senders that split their inbound and outbound 
traffic, OTOH, is enormous. Besides the Big Guys, you'd need to include 
every legit ESP I know of, including most of the cloud-based filter 
services.

<csg>

---

From: Hector Santos <[email-masked]>
Date: Fri, 23 Aug 2013 15:15:36 -0400

> scheme, and what are the pros and cons?

What IP would you be using?  The connecting IP? Would you be testing 
for connectivity or lack thereof?

It doesn't mean much because both situations exist. As more companies 
begin to lower their TCO, they scale up and put all three SMTP roles 
in the same box:

    Receiver
    Router
    Sender

But not having a receiver on the same sender IP does not mean anything.

The only callback you can attempt is against the SMTP required valid 
return path
address (MAIL FROM) domain.  A SMTP receiver MUST exist (expected) at 
the return path domain mail host(s) in order to be capable of 
receiving (DSN, BOUNCES).  Thats a SMTP requirement.

But today with faster, multi-core, multi-threaded operations, you can 
find all SMTP roles under the same computer box with worker threads 
servicing thousands of connections.   Our own WCSMTP package works 
this way out of the box so the odds are very high that in our small to 
mid range customer installations, most will have inbound & outbound 
setup on the same IP (box).

In addition, I believe Google has this "best guess" idea for SPF where 
it uses the concept of sender/receiver SMTP roles are under the same 
IP and MX address.   This could be reflecting the idea that more and 
more systems are scaling up and moving towards a single box.

That said, I don't think you can use this as a valid rule for 
anything, and in fact, the current SPFBIS WG concluded that this 
proposed Best Guess idea will not be added to 4408BIS.

At best, it can only show the scaling up trend in my opinion.

--
HLS

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Aug 2013 10:41:14 -0400

> scheme, and what are the pros and cons?
That's an extremely bad idea.  There's never been a requirement that the
sending MTA listen to port 25.

In general, when people (here or elsewhere) invent arbitrary new
requirements in the hope of filtering spam, the result is to harm the
reliability of email delivery.   Stupid spam filters have made email so
much less reliable that (as far as I can tell) most people actually
don't expect email to work the first time between two new correspondents
unless they're both from the same domain.

Keith