Slashdot Mirror
Why Are We on E-mail Blacklists?
LogicallyRogue asks: "I run an email server for a small webhosting company. We've crawled all around the email server to make it as secure as possible: tightened Sendmail's security, POP Before SMTP, denying non-authenticated relaying, using SpamCop DNS blacklist, etc. However, with all this in place, every few months, it seems that we have been blacklisted by some ISP somewhere. This month it was AOL. We had no warning, and we don't know why we were blacklisted. All the information we have is a single URL. We visit all the DNS blacklist services we can to be sure we are not on any of them. We send emails to the postmasters inquiring for more information (like perhaps a reason or copy of the email that made the ISP blacklist us) - however, those are usually bounced back because we are blacklisted. We've tried calling the Blacklisting ISP tech support - and usually get the stunned I-have-no-clue-what-you-are-talking-about silence.
Have any other Slashdot readers experienced similar problems with blacklisting and the big ISPs?"
..and as such, shouldn't be relied upon as a "oh this is definately for rejection". My firm uses an RBL as a plug in to SpamAssassin. Just being in the RBL by itself isn't enough to get rejected, but it bumps up the score a bit. Unfortunately, because RBL's are easy to slave and use, too many people rely on them, when the use is now limited. Limited by the fact that the 'big' spammers are incredibly clever these days. Having said all that, it wouldn't surprise me if AOL started blocking addresses with the '@' symbol... ;)
Lee
--
'I love spam. Come get me.'
This is a real problem. Many blacklists are far to eager to list an IP without real evidence of spamming.
openrbl.org is useful for looking up your host and trying to figure out what blacklists you are on. But it is still fairly difficult to track down. Our server is listed on three blacklists there even though we have a static IP and have never emitted a single spam address. Sigh.
The other problem I've found is that when a bounce arrives from another server that says you are blacklisted, you can't email them to find out what list they use!
Our mail server does not use any blacklists, which is a shame because we get quite a bit of spam. But we are a business and I cannot take the risk of a client email bouncing, especially if they are innocent and the blacklist is wrong.
What I'd like is a SMTP front end that uses blacklists to determine the likelyhood of the site as a spam source, and delay spam messages for a day or so. The idea being that many mass email programs cannot keep retrying for that long.
With all the renewed focus on fighting SPAM it has occurred to me that this could be a good business opportunity. It seems that small business could use someone who could not only help them to nail down mail servers but also someone who has experience with getting issues like being blacklisted resolved. A combination techie and advocate who knew who to call to get issues resolved quickly. Someone who has contacts throughout the industry. Anyone interested?
All the more reason for verification that an e-mail actually did originate from the address specified. I think half the solution is in this proposal, but I think the other half is validation of the sending address as follows:
1. The sending server would generate a CONTENT KEY based on the contents of a specific message, including the subject, date, from, to, and CC fields, as well as the body. The algorithm to generate this key would be public in nature.
2. A PRIVATE KEY would be used in conjunction with the CONTENT KEY to generate a VERIFICATION KEY.
3. The VERIFICATION KEY would be added to the e-mail, which would then be sent.
4. The receiving server would use the same algorithm above to generate another CONTENT KEY for the received message.
5. The CONTENT KEY plus the VERIFICATION KEY would be sent to the sending server for verification.
6. The sending server would use its PRIVATE KEY with the CONTENT KEY from the receiving server and compare the results to the VERIFICATION KEY.
A. If the receiving server was not updated with the verification capability, it would pass the message through as is done today, for backwards compatibility.
B. If the sending server was not updated, the VERIFICATION KEY would obviously not be present, and the receiving server would pass the message through as is done today, for backwards compatibility (note that the number of non-updated servers will diminish over time, eventually leaving only "spoofable" servers, which could easily be blocked in a more manageable way via the RBL).
C. If the sending server indicates that the message is verified, the message passes through.
D. If the sending server indicates that the message is NOT verified, the message is BOUNCED (I think it is important to actually bounce the message in order to generate additional traffic at the sending server and further encourage open relays to be updated, and to discourage protected e-mail addresses from being added to further SPAM address lists).
Xesdeeni
...and we ended up on it also. Had to make a call to their hostmaster in VA, and 120 seconds later it was fixed. I was repeatedly assured that the issue was in no way related to anything particular on my end... they just screwed up while implementing something yesterday morning.
- SBB
help me i've cloned myself and can't remember which one I am
Recently we switched a large set of servers to another netblock (yeah, I know sucks). We discovered after that the previous netblock owner had gotten themselves on a bunch of black-lists. Maybe that has something to do with it.
Doesn't really have any negative impact on me and helps them control spam, so I'm happy with it.
I run an e-mail server with over 20.000 acounts. This is what happens (and I am not RFC ignorant): My domain (ie: mandic.com.br) is about 10 years old. So it was present on the first spam lists that ever existed. People use it to send spam. That is, they send spam and sign it as foo@mandic.com.br. That happens about every day. My postmaster@mandic.com.br receives about 40MB e-mail every day. I would need 2 persons reading this to get it read. What do I do?
Sometims they just get confused between the attacking and defending system.
I have a program which scans http connects for nimda style probes of my server (given that I don't have a 'live' website, or even a real dns address that points at my box, I know that 95%+ of connects are bogus to begin with, but I filter for obvious attacks anyways).
At the height of the NIMDA season, I was getting more than a dozen provable probes a day, and statistics would just catch up to me. Once in a while I would get letters to my roommate threatening him with cutting off his broadband connection unless he cleaned up the virus on his system..... Given the work that he's done to lock down his system and the fact that he depends on it for his business (he pays business broadband rates, even), he would freak.
He'd then pass the letter to me, I'd ask them for the log information indicating when the complaint occurred, and then look in my logs, and send them my (saved) copy of the original complaint. After the second or third complaint, I sent them a much sterner message asking that they completely clear my roommate's name and put an explicit note on his file explaining my program.
I got a call from a rather knowledgable member of their group who appologized profusely, and even took a copy of my program to play with. We agreed on some minor changes to my automatic email that made it even more obvious that my machine was the defender, and that was that ...... for a while.
A couple of months later I got another email from my roommate -- forwarding yet another threatening letter from our cable company.
In response, I sent a rather bitter email and wrote a rather sarcastic how-to on reading my logfiles. Once again, their abuse uber-geek called me up and apologized. He told me that the latest email was because they had changed their abuse reporting system and hired a fresh set of newbies. Between then and when I moved out, I didn't get another complaint from them.
Free Software: Like love, it grows best when given away.
Contacting the postmaster@ does not always meet with success. You omitted your IP address so an informed response is rather unlikely. AOL runs their internal block list you can be listed for reasons like changing your server configuration without notifying them about said changes.
With 30 Million subscribers AOL receives a deluge of spam and must act to protect the integrity of their systems and subscriber base. As far as I am aware AOL does not subscribe to any outside filters reasons being the lack of control over such filters.
With so much on the line AOL most likely feels they must be proactive instead of reactive. The Comcast fiasco was about server configuration "Comcast must register their e-mail server configurations to communicate with AOL"