To expand, if your incoming mailserver rejects all inbound messages with a=
transient error and notifies the recipient. The recipient can then elect to=
allow any similar messages through if the remote server tries again within=
a set period of time.
This may have to second guess how many times the remote server will retry=
before giving up, and either allow or reject the message with a permanent=
error if the recipient does not express their will in time.
This kind of lame idea is a good example... so you end up increasing the cost
of
handling E-mail, wasting bandwidth and transmission latency on artificially
necessary retries, and requiring new recordkeeping (queueing, etc) on both the
recipient and sender ends.
What the hell benefit is THAT?
And the idea about "queueing it closer to the sender"... again, a large
percentage of spam TODAY is sent by spambot zombies. So you're NOT clogging up
SPAMMER uplinks... or increasing THEIR costs... you're clogging, abusing, and
increasing the cost to VICTIM ISPs and VICTIM users.
Either way, if the message is legitimate but ends up being bounced, a clear=
message could indicate why and recommend trying again or contacting the=
user via other means to arrange to allow the message through.
And when those messages bounce back to Yahoogroups or Majordomo or other
mailing
list software, or publishers sending thousands of legitimate users... who the
heck do you think is going to deal with all those stupid "challenge/response"
type situations?
Publishers have already made quite clear their policy regarding such stuff.
They just IGNORE such things, and if you want the information they're providing
to you, you won't subject them to it.
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections! http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg