Indeed it does, since regardless of how desireable it may be to reject
recipient addresses early, it most certainly is not required and is in
cases next to impossible to implement.
Can you share the typical reasons you believe it impossible?
- Legacy software?
- Slow Database I/O?
- Operating in Gateway modes?
In my view, these were all legitimate reasons, especially in the past.
Today, without a doubt, systems understand the importants in not promoting
bouce attacks. We didn't originally offer dynamic SMTP level RCPT local
user validation. It was done by the gateway and hence your accept+bounce
mode of operation.
But as the spam problem grew, coupled with the higher level of bad RCPT
attempts, high bounce attacks, it became painfully obvious more control was
needed at the SMTP level. So it was added, but as a default FALSE option as
to not surprise the sysops who were use to the old style UUCP/gateway mode
When SORBIG hit in 2003, which emphasized on bounce-attacks as part of its
2nd level distribution process, this is when we got huge support calls on
how to solve or reduce the high bounce volume. The answer was simple: "Turn
on the SMTP Local Recipient/Hosted Domain Validation" option. The typical
response was: "Oh, I didn't know this option was there. Thanks."
True enough, although hopefully the CBV system would be
smart enough to tell the difference between "no such user foo"
and "I think you smell and therefore I'm not accepting mail from
you, never mind if the recipient address is valid or not".
But getting all these details right is fairly tricky.
I believe what turned this thread around was the issues surrounding RCPT
limits for NULL return paths and how it was possible. This was related to
the secondary RCPT random address test for an open relay performed by our
I don't think the details are not that tricky at all.
An CBV targets an MDA, the email domain host to simulate a validity of a
proper bounce process to the return path as required by RFC x821.
An MDA can be only operate in 3 modes in the CBV test:
1) Transaction level Forward Path validation
2) Post Transaction Forward Path validation
3) Open Relay (accepts all address, include remote)
Do you see any other? In my last message to bruce, I cited 4, but the
zombie is basically behaving in open relay mode.
Now consider the POSSIBLE state results:
RCPT TO:<return path>
250 - ok
45x/55x - whatever reason.
A negative feedback is 100% deemed a trusted result. Even Exim says the
same its callout description. I don't believe there is any fuzziness here.
With the positive result, you have to decide if this is a OPEN RELAY and by
that I mean, it will accept any address.
So a second test is done to test the open relay:
RCPT TO:<random non-local domain address>
250 - ok
45x/55x - whatever reason.
The negative response code is what we are looking for. The negative result
will pass the CBV test. There is no fuzziness here. This is a perfect
test with today's secured system with no pen relay behavior.
With the positive response code, we have now have what we call an open
Bruce correctly pointed out that this could be a delay validation system
that will accept any address.
I accept that, but the question is, will a system accept ANY random from an
unauthorized address. I don't think so. CBV or NO CBV, the responsible
MSA system today require an authorized session to route mail.
So we ask, what is the purpose of the CBV? To protect you from bad address,
and highly exploited open relay or zombie systems that will accept not just
any address, but specifically random addresses.
If we were sending a second address where only the local part changed, then
I would 100% agree that it proves nothing. You could not reject this CBV
session. But it is not a 2nd test for a random user at the same MDA. It is
random non-local domain address test which I hope you could address, the BCP
for a MSA will not accept unless you were authorized, especially with a NULL
return path address.
PS: I decided to contact/research the current CBV implementations/authors,
finished up the I-Ds I started which will include the CBV concept, among
others as well. I would love to get assistance from veteran RFC writers.
Hector Santos, Santronics Software, Inc.