Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Funny peculiar.

idea: add, search, annotate, link, view, overview, recent, by name, best, random

meta: news, help, about, links, report a problem

account: Browse anonymously, or get an account and write.

User:
Pass:

or Create a new account.


        Please log in.
If you're not logged in, you can see what this page looks like, but you will not be able to add anything.

X-Bounce-Request and related headers
Some headers to improve email bouncing in this world of spam while maintaining general compatibility
 
(0) 		  [vote for,
against]


Mail originating clients would add a new header to outgoing messages: X-Bounce-Request: [something], where [something] is arbitrary text the client would be able to recognize if it saw it again. In most cases, it could just be some arbitrary word or number chosen at install time. Note that many existing email clients could be configured to do this automatically.

Enhanced mail servers would bounce almost all undeliverable that contained an X-Bounce-Request: header, even if it seemed like it might be spam and the return address might be fake. The bounce message for any rejected email that contained an X-Bounce-Request: header would contain an X-Bounced: header with a "reason" code and the original [something].

Mail receiving clients would examine incoming messages and delete unread those which contained an X-Bounced: header that did not contain a valid [seomthing]. More sophisticated clients could rebounce messages which contained an X-Rebounce-Request header.

The "reason" code and "X-Rebounce-Request" header would allow for enhanced handling of the following scenarios:

-1- A message is undeliverable for some reason.

-2- A message is delayed and might or might not be delivered.

-3- A message is put on hold pending further action by the original sender (some anti-spam services require the sender to take some action to confirm that they're human).

Note that in case #3, it may be desirable to have the server that bounced a message discover that its bounce message was rejected so it can avoid wasting resources holding a message that it will never deliver.

Using the new headers would allow improved functionality for clients and servers that support them while retaining present functionality for those that don't.

supercat, May 12 2005


Short name, e.g., Bob's Coffee

Destination URL. E.g., http://www.coffee.com/

Description (displayed with the short name and URL.)







       How is this different from a just plain bounce message? Scenario 1 works exactly the same, scenario 2 already happens and scenario 3 the anti-spam services send mail saying 'you have to do this to continue' already.   

       Reason codes already exist and are sent along with the bounces in most cases.
StarChaser, May 12 2005
   

       The enhancement is that under current protocols and usages, a machine that bounces a spam message risks hitting a legitimate user with the bounce; this is especially true of users with 'catchall' domains. I probably get about 5 or so such bounce messages daily.   

       To avoid having user get bombarded with spam bounces, many servers silently delete suspected spam. Unfortunately, this means that any email message that gets mistaken for a spam will be deleted without notice.   

       Adding the described headers would allow machines to return bounce messages with some confidence that they wouldn't clutter up some legitimate user's mailbox. If all my outgoing emails contain "X-Bounce-Request: fisbin" and I get an email with "X-Bounced:" header that does not say "fisbin", I can safely have my mailserver delete it unread since I would be able to tell it was a bounce of a spoofed email.
supercat, May 12 2005
   


 
back: main index
 business 
 computer 
 culture 
 fashion 
 food 
 halfbakery 
 home 
 other 
 product 
 public 
 science 
 sport 
 vehicle