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.
It's more "best practice, but uncommon", in my experience at least. And that's
the problem - it most certainly is not required and I see little if any chance
of getting consensus on recommending it, given that we cannot seem to get
consensus on lots of even simpler, more obvious stuff.
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.
That depends very much on how you do the export. A simple list in a file is one
thing, opening a channel through to your directory server is a very different
kettle of fish. Full security audits of directory servers are really fun...
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 ?
Bruce already described it accurately, I think.
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.
Indeed, which is why we tend to limit use of the technique to fairly specific
cases. Using it for a backup MX situation can get messy, given that one of the
main purposes for having backup MXes is so mail keeps flowing when the primary
site (where the definitive data lives) is unreachable.
Of course you can always use the standard directory replication protocol the
LDUP group defined to create a remote copy of the data you need and keep it in
sync. Oops, the LDUP group died without ever specifying a protocol, so the ways
these is done are totally proprietary.
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.
Mine has been in place for something like two years. Hasn't done a lick of good
that I can tell. But hey, at least I'll be able to keep sending mail to
hotmail.com...
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) ?
There's lots of stuff to cover. One thing would be how to define best practices
for address verification done by web sites - both simple syntax checks and
active online checks. (I'm personally sick and tired of being told that
ned+foo(_at_)mrochek(_dot_)com is an invalid email address.) There's a fair
degree of
overlap between this sort of verification and what CBV does for MAIL FROM
addresses, so might as well do that too.
Such document would be a bit tricky in the IETF given that some of it
gets close to GUI guidelines. But I think that aspect of it could be
managed.
Ned