ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
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.
Okay, I can't judge how "common" it is, but in some cases
it's clear why it's at least difficult. OTOH look at LTRU,
with two exceptions, one more on the troll side of things,
all are happy with saying 3066bis => BCP. The definition
of "common" is apparently flexible enough to cover it.
that's the problem - it most certainly is not required
and I see little if any chance of getting consensus on
recommending it
As always I have some difficulties with SHOULD, with valid
and good reasons where's the problem ? If you simply want
some backup MX service run by a third party, then it can't
verify addresses or temporary conditions like "over quota",
it's the idea of this backup MX to work especially if the
main site is down.
The backup MX probably uses some very aggressive blocking,
and of course it's not affected by a "SHOULD verify". The
SHOULD would be for those who can reasonably do it. And if
that's a problem in the next spamops I-D maybe listing some
of the cases where it's impossible could fix it.
What's a "lock step relay", like CBV only forward ?
Bruce already described it accurately, I think.
Yes, it's what I thought. The timing issues are interesting,
a timeout would be another valid reason to violate a SHOULD,
and to check the problem with the next hop(s) manually... ;-)
[FAIL]
Mine has been in place for something like two years. Hasn't
done a lick of good that I can tell.
With rule #3 (spammers are stupid) some delay is clear, but
after SA 3.0 (2004-09 IIRC) that must be a very hard case...
or it's "only" a mail worm, worms authors have more pressing
needs than to avoid FAIL-protected addresses.
But hey, at least I'll be able to keep sending mail to
hotmail.com...
Depends on your PRA, not if you're on Sympa mailing lists :-(
[elaborated "lock step relay" etc. I-D]
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.
[...]
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.
RfC 3696 is nice... but apparently not correct, I don't find
a way to get a <quoted-pair> outside of a <quoted-string>, and
an unquoted space in a <quoted-string> is also dubious. Maybe
the planned I-D should update 3696 - is it possible to update
an informational RfC ? Or to submit errata ? Bye, Frank