Gunnar Hjalmarsson wrote:
are you thinking of anything beyond what Stuart suggested?
Probably not, I saw his reply only later, apparently he also
proposed to do SRS only on demand (or the opposite, disable
it on demand).
The essential point, only the recipient knows - at least in
theory - what the next hop does. In your example the next
hop uses a C/R system, the best you can do in this situation
is nothing. Not your fault if the setup of this user breaks.
permanent, in other words your user wants that senders
update their address book.
Not sure from where you drew that conclusion. ;-)
Guessing. A C/R system is a (dubious) way to create a white
list. That makes no sense for temporary addresses, and the
challenge normally shows the destination address, and then it
is also no "secret" address.
OTOH, it shouldn't do any harm either.
Depends on what you do with these challenges, if you delete
them silently it's worse than no SRS:
MAIL FROM:<me> RCPT TO:<your.user>
User is not local, if you forward it to user(_at_)cr(_dot_)example and
the the challenge is sent back to you, where it vanishes in
/dev/null, the original mail is lost without any hint.
If you forward it with the original MAIL FROM and the C/R
system checks SPF, it would reject it (the IPs allowed to
use my MAIL FROM don't include your box). Therefore you
would get a reject and send a bounce to me, case closed, I
cannot send mail to <your.user>, and then I know why.
Or the C/R system doesn't check SPF, and sends a challenge
to me. That works also, maybe I even reply or whatever it
wants, solve one of those stupid puzzles.
Only if you rewrite the sender and later drop the challenge
it fails silently, and silent failures are A Bad Thing. Bye