Even thought it might be recommended to do processing in real-time, in
practice many systems do not and will not. We must be take that into
account.
Of course we must. We shouldn't assume Best Practice to be done by others.
Best Practice is what we should try to do ourselves.
I agree with Yakov, and would even go further. I think smtp-session
reject is falling out of favor and will eventually disappear.
Your evidence ? For goodness sake, *hotmail* do it. Of course they may be
going to stop at any minute - in which case I'll look silly.
There are strong reasons to prefer accept-then-bounce or even filter to
reject.
(1) Reject gives feedback about your system to would-be bad
guys--including dictionary spammers--in a much faster and more
reliable way. Sysadmins rightly want to give out as little
information as possible, because that's standard practice anywhere
security is involved.
This is a variation of security through obscurity. And we know how well
that works.
(2) Reject is a less flexible mechanism. Accept-then-bounce or filter
allows recipients to work around certain obselete or overzealous
systems.
How so?
(3) Senders have come to understand that messages get incorrectly
filtered as spam sometimes; they no longer expect to recieve an
immediate rejection if there is a problem delivering a message.
Which senders no longer expect this? All of them? You've asked them all?
Like ident, smtp-reject has some usefulness inside private networks, but
one shouldn't expect to see it widely used on the public Internet.
Why compare this to ident? What's the point? And who says I shouldn't
expect Best Practice on the public Internet (while being prepared for
less).
If we really think that BCP30 is so hopelessly outdated, wouldn't this be a
good place to start rewriting it.
Jon (tired) Kyme
--
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg