At 05:20 PM 10/14/2008 -0400, Sanford Whiteman wrote:
Let's drop the word "sender", since we now need a little more
precision. If the Transmitter does not handle the text of the SMTP
reject message properly, and by that I would assume simply relay it
to the original Author of the message, if that is the problem, it is
not the Receiver's responsibility. The Receiver has done his job by
sending a clearly-worded reject message.
Your claim that a "clearly-worded" (512-character, given non-global
support for multi-line responses) response message is your only
responsibility is ridiculous. Though classic FUSSP.
Try doing all your tech support in 512-character phrases from now on.
Guess what: it's not like the developers of the original C/R concept
had never heard of the SMTP protocol. They just knew their idea would
be _even lamer_ if they tried to express it using such an, ahem,
concise end user interface.
Here are some sample reject messages that I would consider clearly worded.
Notice we are not trying to do tech support in the message itself.
Sorry! We cannot guarantee delivery of this message.
- <your domain> does not offer sufficient authentication to prevent forgery.
- <your domain> does not have sufficient reputation for <recipient>.
We will run it through our spam filter, and keep it in our quarantine, but the
recipient may not read it.
See http://open-mail.org/rejects for help.
Receivers cannot be held responsible for these kind of problems on
the sending side.
The age-old "problem" of not being able to send mail because the
receiver set a policy that stopped being feasible in around 1983, or
whenever the first non-techie end user used SMTP.
There seems to be a lot of unstated assumptions here. I'm not quite sure what
is behind this statement, so I can't offer a complete response. I'll just say
that I believe an intelligent reject policy can motivate senders to fix a
problem without adding to problems on the receiver side.
Maybe a little less sarcasm would help. I am interested in what you have to
say.
-- Dave
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com