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

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



random, halfbakery