Dear mr. Santos,
[...]
In my technical view, an anti-probing logic should be for multiple RCPT, not
on the first RCPT and fortunately, the majority of responsible mail systems
don't operate that way. It would kill the system. Look at this way, RFC
2821 says you must accept the local message anyway (for null return paths),
so what's the point of delaying it? All you are doing is hurting innocent
victims.
Who is talking of deliberately delaying the response? My mailhost
receives up to 500 messages a day without any problem and all these
sending systems seem to be able to reach my system and deliver the mail.
Furthermore, I send literally thousands of messages per year to remote
SMTP systems and they are received properly. I can show you the logs.
What make you think that MY system is delaying your CBV? You know
perfectly well that ANY IP system between your system and my system may
be responsible for this delay. It may be your firewall, it may be your
ISP, it may be my ISP, it may be my firewall etc. Given the facts about
traffic mentioned above, I'm confident that my system is not the problem.
If you want to stop the probes, add Multi-line Greeting responses. You will
instantly stop at least 40-50% of your probes.
Finally, of course, the whole point of adding LMAP to CBV systems is to
avoid the CBV as much as possible. So he could of simply added an SPF
record and it would of been a none issue. The point is, the CBV is the
ultimate test to satisfy that return path is valid, and in our design, SMTP
COMPLIANCY is a must, those that fail to comply, will not get in. Its as
simple as that.
My system is compliant with SMTP from day 1 (PMDF has been around for as
long as 1985 or so) and a number of great names has written it (Ned
Freed, co-author of MIME is one of them). Look at the number of RFC's
Innosoft International Inc., vendor of PMDF, has contributed to and
don't tell me that my system is not SMTP compliant.
The timeouts, mentioned in RFC2821, are there not without a good reason.
Expecting each and every SMTP server answering within your 35 seconds
indicates you need a reality check.
And at the end of the day the CBV tells you nothing. See RFC2505:
2.11. SMTP VRFY and EXPN
Both SMTP VRFY and EXPN provide means for a potential spammer to test
whether the addresses on his list are valid (VRFY) and even get more
addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed
to issue these commands. This may be "on/off" or it may use access
lists similar to those mentioned previously.
Note that the "VRFY" command is required according to RFC821, [1].
The response can, though, be "252 Argument not checked" to represent
"off" or blocked via an access list. This should be the default.
Default for the "EXPN" command should be "off".
Many systems won't tell you whether an address is valid or not. I'm not
sure if this is the default, but MS Exchange will check the syntax of
the address, and if the syntax is correct, it will accept all messages
without a check for validity of the recipient address. The fact that
many SPAM MAIL FROM: addresses do not exist does not necessarily tell
you something about the reverse, whether an address that exist is not SPAM.
I don't buy that idea as some have put it "the return path
is only valid when it needs to be used." Well, that doesn't make sense at
all. It is presumed to be valid for a bounce, then it better be valid at the
moment it is presented. Not after the fact.
This particular message to you is still in my mail queues: last attempt
Sat, 13 Mar 2004 12:01:15 +0000 (GMT)
winserver(_dot_)support(_at_)winserver(_dot_)com: smtp;552 Return Path not
verifiable.
I'll remove it right now, as you seem to be convinced your anti-spam
logic is more important than to receive legitimate messages.
/rolf