Comments on: Forged return addresses http://spamhuntress.com/2006/04/25/forged-return-addresses/ Just another WordPress weblog Fri, 21 Nov 2008 05:04:39 +0000 http://wordpress.org/?v=2.0.7 by: Administrator http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7873 Sun, 30 Apr 2006 13:09:46 +0000 http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7873 Sigh... I'm afraid it's your knowledge which is incomplete or outdated. I don't advocate keeping the mailboxes on the same server as the SMTP server (which can also be the mailserver in the MX record for your domains). So you're right that this server would not automatically have a list of all users on it. But it's essential to provide these servers with a list of users. A big domain may have more than two servers in their MX record. All of those servers would have a copy of the user list. Servers that don't lend themselves well to that, should no longer be used. Here's a concrete example of how one server solves the problem you seem to think is unsolvable: http://www.postfix.org/LDAP_README.html I recently got a bounce from Earthlink. The reject mail to nonexistent users. Earthlink is pretty big, don't you think? AOL does the same thing. I just sent a test mail a few seconds ago. So, you want to stay with your position on this? Sigh…

I’m afraid it’s your knowledge which is incomplete or outdated.

I don’t advocate keeping the mailboxes on the same server as the SMTP server (which can also be the mailserver in the MX record for your domains). So you’re right that this server would not automatically have a list of all users on it.

But it’s essential to provide these servers with a list of users. A big domain may have more than two servers in their MX record. All of those servers would have a copy of the user list.

Servers that don’t lend themselves well to that, should no longer be used.

Here’s a concrete example of how one server solves the problem you seem to think is unsolvable:

http://www.postfix.org/LDAP_README.html

I recently got a bounce from Earthlink. The reject mail to nonexistent users. Earthlink is pretty big, don’t you think? AOL does the same thing. I just sent a test mail a few seconds ago.

So, you want to stay with your position on this?

]]> by: Reg Stevens http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7698 Fri, 28 Apr 2006 16:23:46 +0000 http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7698 Your knowledge of how email systems work is a little incomplete. What you are proposing (and have apparently tested) works fine for non-existent domains, but it cannot be relied on to bounce mail sent to non-existent mail boxes. The Mail Exchange server (MX) supplies only the name of the recipient mail server (based on the email address)- it has no record of mailboxes. This works akin to DNS, but provides server names in the form of mail.somewhere.com, not even IP addresses which need yet further DNS action. It will provide this whether the actual user (somebody@) specified exists or not. Often the MX will provide an alternative (back-up) recipient address (as well as the primary mail server name) in order to make the delivery more reliable. This would be invoked if the real recipient server is switched off or is otherwise too busy. However, even this secondary (back-up) server (e.g. mail2.somewhere.com) would also still have no knowledge of the existence or otherwise of the actual mailbox! It merely retains the sent mail until the real recipient server becomes available again. Mailbox (user@) information is ONLY held on the final recipient server- believe me! This server may be switched off for days, but the mail will still get through- if the mailbox exists. That's it from me. Your knowledge of how email systems work is a little incomplete. What you are proposing (and have apparently tested) works fine for non-existent domains, but it cannot be relied on to bounce mail sent to non-existent mail boxes. The Mail Exchange server (MX) supplies only the name of the recipient mail server (based on the email address)- it has no record of mailboxes. This works akin to DNS, but provides server names in the form of mail.somewhere.com, not even IP addresses which need yet further DNS action. It will provide this whether the actual user (somebody@) specified exists or not. Often the MX will provide an alternative (back-up) recipient address (as well as the primary mail server name) in order to make the delivery more reliable. This would be invoked if the real recipient server is switched off or is otherwise too busy. However, even this secondary (back-up) server (e.g. mail2.somewhere.com) would also still have no knowledge of the existence or otherwise of the actual mailbox! It merely retains the sent mail until the real recipient server becomes available again. Mailbox (user@) information is ONLY held on the final recipient server- believe me! This server may be switched off for days, but the mail will still get through- if the mailbox exists. That’s it from me.

]]> by: Administrator http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7691 Fri, 28 Apr 2006 14:27:44 +0000 http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7691 Reg Stevens: OK, here we go again. You're flat out wrong, because you've misunderstood how this happens. It's the server that has the MX record for a domain that needs to have a list of users, so it knows what e-mails to reject. It sends a 550 code to the sending server, which then forwards that error code, and including whatever wordy explanation the receiving server sends, to its users. So, again, both of you are wrong. Here's a sample from the logs of one of my servers. The receiving server (has an MX record for the domain). And yes, I've munged it: Apr 25 06:54:19 post postfix/smtpd[31607]: NOQUEUE: reject: RCPT from mungedsendinghostname[mungedsendingIP]: 550 : Recipient address rejected: User unknown in relay recipient table; from= to= proto=SMTP helo= (blasted WordPress removed part of the code, so this is NOT how it appears in my logs, sorry!) This is what it looks like in my logs. This particular e-mail was from a spammer, but IF that e-mail had been from a regular user, the sending mailserver - the one he was using, would send him a bounce. My server never received the mail at all, it REJECTED it, and left the sending server to send a bounce. In fact, if I send an e-mail to a nonexistent address on my local network, my e-mail program sends me the bounce! Because the sending and receiving servers are the same in that example. Do you understand now? Reg Stevens:
OK, here we go again.

You’re flat out wrong, because you’ve misunderstood how this happens.

It’s the server that has the MX record for a domain that needs to have a list of users, so it knows what e-mails to reject. It sends a 550 code to the sending server, which then forwards that error code, and including whatever wordy explanation the receiving server sends, to its users.

So, again, both of you are wrong.

Here’s a sample from the logs of one of my servers. The receiving server (has an MX record for the domain). And yes, I’ve munged it:

Apr 25 06:54:19 post postfix/smtpd[31607]: NOQUEUE: reject: RCPT from mungedsendinghostname[mungedsendingIP]: 550 : Recipient address rejected: User unknown in relay recipient table; from= to= proto=SMTP helo=

(blasted WordPress removed part of the code, so this is NOT how it appears in my logs, sorry!)

This is what it looks like in my logs.

This particular e-mail was from a spammer, but IF that e-mail had been from a regular user, the sending mailserver - the one he was using, would send him a bounce. My server never received the mail at all, it REJECTED it, and left the sending server to send a bounce.

In fact, if I send an e-mail to a nonexistent address on my local network, my e-mail program sends me the bounce! Because the sending and receiving servers are the same in that example.

Do you understand now?

]]> by: Reg Stevens http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7688 Fri, 28 Apr 2006 14:11:10 +0000 http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7688 Sadly, I think Andrew is the one reasoning correctly here. Although it may be possible for sending (SMTP) mail servers to identify non-existent domains, it certainly isn't feasible for them to have a list of every non-valid mail box irrespective of where it may be. New mail boxes are being newly created somewhere every second. Bounces (if you are going to have them) ultimately have to come from the potential recipient- usually a POP3 server. Andrew's proposed solution may be heavy handed, but it is not short sighted and certainly not "categorically wrong". Sadly, I think Andrew is the one reasoning correctly here. Although it may be possible for sending (SMTP) mail servers to identify non-existent domains, it certainly isn’t feasible for them to have a list of every non-valid mail box irrespective of where it may be. New mail boxes are being newly created somewhere every second. Bounces (if you are going to have them) ultimately have to come from the potential recipient- usually a POP3 server. Andrew’s proposed solution may be heavy handed, but it is not short sighted and certainly not “categorically wrong”.

]]> by: Administrator http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7604 Thu, 27 Apr 2006 11:51:13 +0000 http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7604 Andrew: You're categorically wrong. Most of your arguments are sound. But you're backing the wrong solution. The right way to do this is to have the mailserver REJECT mail to nonexistent addresses. What that means is that the mailserver gives the sending server the message that the mail will not be received. Which means that any legitimate mail to nonexistent addresses will bounce, with the sending server sending the bounce. That doesn't produce backscatter, which is the industry term for the pointless bounces. Spammer servers of course won't produce bounces even though the receiving mailserver doesn't accept mail from them, so it all works out. But turning off bounces alltogether is shortsighted to the extreme! Use the solution I outlined, and you've reduced backscatter to only legitimate bounces. Many mailservers have this behavior as default, provided they have a list of valid e-mail addresses, whether those mailboxes are on that server or a second server. Andrew:
You’re categorically wrong. Most of your arguments are sound. But you’re backing the wrong solution.

The right way to do this is to have the mailserver REJECT mail to nonexistent addresses. What that means is that the mailserver gives the sending server the message that the mail will not be received. Which means that any legitimate mail to nonexistent addresses will bounce, with the sending server sending the bounce. That doesn’t produce backscatter, which is the industry term for the pointless bounces. Spammer servers of course won’t produce bounces even though the receiving mailserver doesn’t accept mail from them, so it all works out.

But turning off bounces alltogether is shortsighted to the extreme! Use the solution I outlined, and you’ve reduced backscatter to only legitimate bounces.

Many mailservers have this behavior as default, provided they have a list of valid e-mail addresses, whether those mailboxes are on that server or a second server.

]]> by: Andrew Oakley http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7600 Thu, 27 Apr 2006 11:08:36 +0000 http://spamhuntress.com/2006/04/25/forged-return-addresses/#comment-7600 Whilst obviously it is the spammer's fault that this is happening, mail servers are not helping by having bounces switched on at all. Years ago there used to be a point for bounces; they'd let you know if you sent an email to a misspelt address, or if your friend had got a new job or new ISP or somesuch. Nowadays almost all bounces are spam-related; either failed spam that the spammer tried to send to someone else, or "reverse joe jobs" where the spammer deliberately sent to a known-bouncing email address in the hope the message would avoid spam filters when it bounced back to you. I really think all mail servers should ship with bounces turned off by default these days. They're just not useful anymore. Whilst obviously it is the spammer’s fault that this is happening, mail servers are not helping by having bounces switched on at all.

Years ago there used to be a point for bounces; they’d let you know if you sent an email to a misspelt address, or if your friend had got a new job or new ISP or somesuch. Nowadays almost all bounces are spam-related; either failed spam that the spammer tried to send to someone else, or “reverse joe jobs” where the spammer deliberately sent to a known-bouncing email address in the hope the message would avoid spam filters when it bounced back to you.

I really think all mail servers should ship with bounces turned off by default these days. They’re just not useful anymore.

]]>