I had this problem for several weeks, and I'm documenting it in case anyone else is unlucky enough to be in this situation and needs to find the solution. I was seeing that Earthlink and Mindspring were not able to send to my domain. The senders would get delivery delay emails and the delivery failures eventually on all emails to my domain. With a couple exceptions, everyone else had no problem sending to my domain. So 99% of all email was coming through, but these couple were problematic.
It turns out that I had configured too many real time block list providers (RBLs). When the remote server was connecting to my server, the process of checking the sending server against all 5 RBLs would take some time. In this case, the Earthlink servers wouldn't wait long enough for my server to finish checking - and the Earthlink servers would drop the connection. The solution was to just have one block list provider. In this case I used zen.spamhaus.org
So that was it. Just a note for future reference.
Showing posts with label NDR. Show all posts
Showing posts with label NDR. Show all posts
Monday, March 29, 2010
Friday, June 6, 2008
don't forget reverse DNS
I recently built a mail server for a client. It went as smoothly as it could have . . .
until I started getting reports of delays and undeliverables from AOL addresses and Juno addresses. I had forgotten to set up a reverse DNS entry. Frankly, I think a reverse DNS entry (PTR entry) is a meaningless way to address spam issues - but what can you do?
Someone seriously needs to take the lead and start enforcing SPF records. Anyway, don't forget to create reverse DNS entries. And in case anyone other than me ever reads this blog - a reverse DNS entry is created by your ISP - not your DNS host.
until I started getting reports of delays and undeliverables from AOL addresses and Juno addresses. I had forgotten to set up a reverse DNS entry. Frankly, I think a reverse DNS entry (PTR entry) is a meaningless way to address spam issues - but what can you do?
Someone seriously needs to take the lead and start enforcing SPF records. Anyway, don't forget to create reverse DNS entries. And in case anyone other than me ever reads this blog - a reverse DNS entry is created by your ISP - not your DNS host.
Sunday, May 18, 2008
Hundreds of underliverable emails you never sent
This blog entry's goal is to give a lay person's explanation as to why a user might be receiving hundreds of delivery failures for messages that he/she never sent.
Email is insecure and very exploitable. This is a fact. The standard for email was designed in the late 60s and early 70s, long before spam and other types of abuse existed or were even thought of. Today, we live with the repercussions of the insecurity and exploitability of the original designs of the email standard. For more detail on the email standard and why it's exploitable, please see my advanced user's explanation (forthcoming as of 5/18/08).
What's happening is that an unethical spammer somewhere in the world has set up his/her own email server and is sending out spam. The exploitability of email is that this spammer can send out emails with any email address he/she wants. He can use bill.gates@microsoft.com; he can use dave@t-solve.com; he can use tom.brady@newenglandpatriots.com. The spammer can send using any address he/she wants - but the email standard does not require that the spammer be a legitimate sender of that domain. The email standard also does not require that the receiving email server check to see that an email is coming from the legitimate server for that domain.
So the spammer can send emails to anyone he/she wants with YOUR address. He/she can be doing that from his/her house in China, Norway, or next door. We have no control over this because it can be done from anywhere in the world. And this spammer is sending emails potentially with YOUR address (as well as other people's addresses) to other people. This process does not involve your server and is not disallowed in the email standard, so we have no control over it.
In these instances where a user gets several hundred undeliverable emails ... the spammer sends out spams to a random list of email addresses (many of which do not exist). And then the recipient's email server sends a bounceback to the sender's address (your email address) that says "undeliverable - this address does not exist."
So what can be done about this? Not a lot, unfortunately. The spammer is taking advantage of an exploitable part of the email standard. It may be unethical and improper, but it's not preventable.
The standard way to deal with this issue is to ignore the emails. Oftentimes, the spammer will send out 200 to 500 of theses emails over a period of 2 to 5 hours and then stop.
For additional questions on this issue, please email me:
http://www.t-solve.com/contact.html
Email is insecure and very exploitable. This is a fact. The standard for email was designed in the late 60s and early 70s, long before spam and other types of abuse existed or were even thought of. Today, we live with the repercussions of the insecurity and exploitability of the original designs of the email standard. For more detail on the email standard and why it's exploitable, please see my advanced user's explanation (forthcoming as of 5/18/08).
What's happening is that an unethical spammer somewhere in the world has set up his/her own email server and is sending out spam. The exploitability of email is that this spammer can send out emails with any email address he/she wants. He can use bill.gates@microsoft.com; he can use dave@t-solve.com; he can use tom.brady@newenglandpatriots.com. The spammer can send using any address he/she wants - but the email standard does not require that the spammer be a legitimate sender of that domain. The email standard also does not require that the receiving email server check to see that an email is coming from the legitimate server for that domain.
So the spammer can send emails to anyone he/she wants with YOUR address. He/she can be doing that from his/her house in China, Norway, or next door. We have no control over this because it can be done from anywhere in the world. And this spammer is sending emails potentially with YOUR address (as well as other people's addresses) to other people. This process does not involve your server and is not disallowed in the email standard, so we have no control over it.
In these instances where a user gets several hundred undeliverable emails ... the spammer sends out spams to a random list of email addresses (many of which do not exist). And then the recipient's email server sends a bounceback to the sender's address (your email address) that says "undeliverable - this address does not exist."
So what can be done about this? Not a lot, unfortunately. The spammer is taking advantage of an exploitable part of the email standard. It may be unethical and improper, but it's not preventable.
The standard way to deal with this issue is to ignore the emails. Oftentimes, the spammer will send out 200 to 500 of theses emails over a period of 2 to 5 hours and then stop.
For additional questions on this issue, please email me:
http://www.t-solve.com/contact.html
Subscribe to:
Posts (Atom)