At 15:41 +0100 4/29/03, Jon Kyme wrote:
Apologies to Andrzej, I should have said:
"And I'd like a good explanation of how ONE would detect that behavior"
whew, that's a relief
But would you be happy if a sender/receiver collusion could get you
blacklisted (rfc-ignorant-like)? Or would the presentation of relevant logs
be a sufficient defence?
So no, bad idea to make protocols that make it too easy for tiny numbers of
third parties to gang up on others silently. Sometimes just balancing a
protocol by allowing tiny numbers of third parties to un-do the problem
may be enough, however. I think this design ethic is often not considered,
yet potentially powerful.
If the sender doesn't have a reliable means for distinguishing between
non-deliveries with and without user control... well, it gives scope for
misunderstanding. And it's not feasible to ring up everybody I send mail to
so I can close the loop.
Occasionally i still get messages with "return receipt requested"
on them and my Eudora client dutifully offers a button to generate an
acknowledgement...
so people seem to be generally aware of this sort of function and desire it
from time to time.
AF said:
> Whenever you send a email message you should always get message
> delivered or info why it can not be delivered or info why some server
> refused to deliver your message.
I agree, pretty much. That would be the ideal state of affairs.
So you're AOL and you have just received 300 million pieces of
undeliverable mail...
do you drop them or try to generate 1 billion bounces that may come
right back at
you, not to mention the complaints as your mailers are used in reverse attacks?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg