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
0.5 and holding.

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

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

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



Server-addressed bounce-mails

Address bounce-mails to the IP address of the server they came from, rather than an email address
  (+3, -1)
(+3, -1)
  [vote for,

One of the major problems in trying to deal with spam is that many spammers falsify return addresses on their messages. Thus, a mail server that bounces messages that look like spam has a high likelihood of hitting innocent people with its bounce messages. Unfortunately, if a server doesn't bounce spam messages, legitimate email messages will vanish into the void without the sender ever being notified.

My proposal would be to eliminate this problem by adding a compatible extension to the email protocol. To wit, a machine that was passing along an email message would include a line

Xbounce-direction: xbouncefnordwowza@

containing an "email address" formed with up to 64 base64 characters and the machine's numerical IP address (which the receiving server would validate). The machine passing the message would be required to keep a transaction log of such messages for 48 hours.

In case of an email bounce, if the recipient machine saw an Xbounce-direction: line it would send the bounce message to the address given in the Xbounce-direction line; this machine would then look up the real From: address associated with that xbounce-direction address and relay it there.

Note that machines which originate email messages could simply include a real email address with the machine's numeric IP address in the Xbounce-direction line and the bounce would automatically taken care of.

If mail servers could be configured to send spam-related bounce messages only in response to messages with the Xbounce-direction: header, legitimate mailers could be informed of message delivery problems while bounced spams would end up in the bit bucket where they belong.

supercat, Feb 19 2005


       I'm all for killing spam, but can you run that by me again, how the machine determines it's a spam message? It seems that if that can be accomplished, all else is moot.
normzone, Feb 19 2005

       The idea here isn't to identify spam. It's to provide a means of avoiding sending bounce messages to any machine that wasn't actually involved in originating or sending the email message being bounced.   

       In short, it provides a means for a machine sending an email to say "Please tell me if this bounces for any reason; here's a bounce address which I claim will work, but which--even if bogus--you can tell isn't going to hit any innocent third party ."
supercat, Feb 21 2005

       Thanks to a worm's idiotic behavior, I received a bounce message from my IP. I suspected something and investigated, thankfully days before my IP contacted me with their suspicion. If this were in place [supercat], would I be subject to longer periods without notification of my own bounced spam messages?
reensure, Feb 21 2005

       A nefarious person could use this to launch a DDoS attack against a particular host while hiding their own identity. Simply send a million intended-to-bounce emails to various email servers that support your protocol, and those servers then bombard the target with undesired bounce messages.
krelnik, Feb 22 2005

       If you send a message to a server with an Xbounce-direction: message that doesn't give your own numeric IP, that server should reject the message outright even before the IP connection is closed. In no case would it generate any email to a third-party server.
supercat, Feb 22 2005

       (+) Took me a while, but I like it. Could the forwarder get around having to keep the transaction log by storing the encrypted, encoded path to forward the bounce to in the header it adds on the way out?
jutta, Feb 22 2008

       Most spam these days (according to most of the reports i read) is sent by zombies, compromised computers of the elderly. In this case, the computer itself is acting as a mail server, and would not even have the ability to receive mail, nor would the ports for receiving be open, nor would spammers care about your bounce.

Edit: I see what you did there.
I recommend you up your time from 48 hours to 6 days, which is the more typical retry time.
Also, since we're implementing a system which would have to have the servers changed for it to work, can we just re-do SMTP to have two-way authentication?
I'll bun you for an idea that will work a little, and at least not break things for people who haven't implemented it yet.
ericscottf, Feb 22 2008

       The forwarder could perhaps encrypt the bounce path rather than keeping a log of such paths, though this could result in the strings getting rather long when messages go through multiple servers (since each string would then have to include enough information to derive the addresses of everyone up the chain). If each machine can have its own lookup table, the expansion of message sizes would not be an issue.   

       I agree two-way authentication would be better as a standard, but getting there with the existing infrastructure might be difficult.   

       On the other hand, I just had another thought: if there were a standard format for bounce messages which would ensure that (1) they were machine-recognizable as bounce messages, and (2) the sender could easily identify the message which was being bounced, it should be possible to make an email client that would separate out legitimate and illegitimate bounces based upon whether they matched anything that was sent recently.
supercat, Feb 22 2008


back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle