[Top] [All Lists]

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

2013-08-23 14:15:50
keld(_at_)keldix(_dot_)com 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?

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:


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.

ietf-smtp mailing list