h a l f b a k e r yOutside the bag the box came in.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
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@194.39.37.251
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.
[link]
|
| |
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. |
|
| |
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 ." |
|
| |
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? |
|
| |
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. |
|
| |
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. |
|
| |
(+) 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? |
|
| |
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. |
|
| |
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. |
|
| |