On Thu June 30 2005 11:02, Tony Finch wrote:
On Thu, 30 Jun 2005, Bruce Lilly wrote:
Not necessarily; for better or worse, a number of sites use multiple
MTA relays within their own administrative domain, and aliasing
expansion might well occur at a separate upstream host from the one
effecting actual delivery. There is nothing particulary
non-compliant about such a configuration, though it does have the
characteristic of forcing a bounce where a single-host arrangement
might be able to return an SMTO 5xx reply code
There's nothing to prevent the front-end MX hosts in such a setup from
having access to the list of valid users,
I suppose so, but then there's not much purpose in having such a split
setup.
I have on many occasions found it very useful to have a backup MX on a
completely separate network that can accept mail when the primary network is
down or unreachable. And if it is possible to configure such a system to be
able to tell good addresses from bad for the domain, all the better since that
will lessen the amount of blow-back spam somewhat.
The mail servers for the innosoft.com domain were set up this way for many
years, as a matter of fact.
My point, perhaps not clearly expressed, is that there are
split setups that do expansion and validation downstream from the MX
host(s), and that such a setup does tend to send bounces rather than
5xx reply codes.
Indeed. And while it is arguably better to do address checks on the front end
system, it certainly is not required, and may not even be possible in some
setups. And when it is possible the security implications are interesting, to
say the least.
This is why I pushed back on Pekka Savola's suggestion that
draft-hutzler-spamops-04.txt recommend/require this practice.
Even that's not strictly necessary, as the MX could
start a lock-step relay during RCPT TO rather than store-and-forward,
but I don't know of any such split setups that work that way.
We use this sort of thing as part of large scale deployments that support
POP-before-SMTP, as a matter of fact. (Of course this effectively disjoint from
backup or secondary MX case.)
so it doesn't "force"
accept-and-bounce instead of reject.
The point is that store-and-forward implies accept-and-bounce (except
of course for a null reverse path).
Indeed it does, since regardless of how desireable it may be to reject invalid
recipient addresses early, it most certainly is not required and is in some
cases next to impossible to implement.
What, you might ask, are the implications? For one, it means collateral
damage caused by such systems accepting joe-job spam then bouncing to
the joe-job victim when the downstream host finally determines that
there's no such recipient. If you've received any such bounces, you
may know that such system configurations are not uncommon.
I average around a hundred of these every day.
For CBV, it
means that acceptance by such a system's MX host doesn't mean diddly.
And one generally can't tell from the outside if such a configuration
is in use unless and until one analyzes a joe-job bounce from there.
A secondary implication is that a CBV rejection from such a system
probably means more about the CBV initiator than mailbox validity,
and initiating a CBV session with such a host won't tell one much,
unless perhaps one is trying to find bugs in one's less-than-100%
compliant systems.
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. Keith mentioned earlier
in this thread that an address verification specification would be a good idea.
I agree, and would be happy to assist in writing such a document.
Ned