ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
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.
Somehow I must have missed or forgot this part, was it your
idea to say "MDAs" in the corresponding "SHALL NOT accept" ?
It's IMO really "best common practice" to export this knowledge
to the front end. If you'd start to suppress bounces based on
some spam filtering it could be more messy than the _security_
implications of an exported local user list.
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
What's a "lock step relay", like CBV only forward ? That would
be one way to export the knowledge about local users. It could
also catch some "over quota" cases depending on the MDA. With
more than one hop from MX to MDA it starts to get interesting.
regardless of how desireable it may be to reject invalid
recipient addresses early, it most certainly is not required
You'd need two MTAs or rather two IPs as mailouts, one would be
permanently blaklisted as the soure of bogus bounces to forged
addresses. My attempts to discuss the issue in the spamcop NG
had no effect, and I'd stop when you had a fair chance: If you
accept FAIL-protected forged mails to non-existing local users
it would be really your problem to discuss this with BLs.
I average around a hundred of these every day.
How long do you have your -all ? "My" spammer needed about 14
weeks until he got the idea.
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.
What could it say, something about catch-all and "teergrube" ?
Or is this about some "lock step relay" / forward verification
within an MRN (MX to MDA) ?
Bye, Frank