keld(_at_)keldix(_dot_)com wrote:
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?
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp