AOL bounces and false positives

A number of people have been seeing an increase in AOL bounces over the last few days. Some of these are the new rejection 554/421 CON:B1 message. This is, basically, you’ve topped our thresholds, back off.
The other one is a bit more interesting. The error message a lot of people are seeing is 554/421 RLY:SN. Senders should only be getting this error message when they are sending email from a banned address.

This error indicates you are sending email using a disallowed AOL.COM screenname as your FROM or REPLY-TO address, or as one of AOL’s affiliates from an unauthorized IP address. Example: Billing@aol.com

Clearly this is AOL attempting to minimize phishing and spoofing of the AOL brand. This is a great thing.
Unfortunately, there seems to be some problems with the current implementation. This rule is catching perfectly legitimate email. One report I have seen is that mail with @aol.com in the from address is getting rejected with this message. That means all those small businesses sending mail from their @aol.com addresses through an ESP are seeing problems. Another report I’ve seen is that email addresses with “a” “o” “l” in order (like, for instance, kaolin@somewhere.example.com) are also getting rejections.
It’s very possible that this filter is catching other mail, too.
Folks I’ve talked to are in touch with AOL and AOL is working on fixing the issue.
Note these do seem to be intermittent errors and not every email with an @aol.com address in the from line or some rendition of “aol” in the email address is getting bounced. But if you do start seeing increases in the number of AOL bounces and they are RLY:SN, this may be why. A short term work around will probably be to modify From: addresses where possible. Longer term, we’re just going to have to wait for AOL to fix things.

Related Posts

AOL transmitting 4xx error for user unknown

AOL is currently returning “451 4.3.0 <invaliduser@aol.com>: Temporary lookup failure” in some cases when they really mean “550 user unknown.” This message from AOL should be treated as 5xx failure and the message should not be retried (if at all possible) and the failure should be counted as a hard bounce for list management purposes.
This is something broken at AOL’s end, and the guys with the magic fingers that keep the system running are working to fix it. Right now there doesn’t seem to be an ETA on a fix, though.
Even if you are a sender who is able to stop the retries, you may see some congestion and delays when sending to AOL for the time being. Senders who don’t get the message, or who are unable to stop their MTAs from retrying 4xx mail will continue to attempt delivery of these messages until their servers time out. This may cause congestion for everyone and a noticeable  slowdown on the AOL MTAs.
AOL blog post on the issue
HT: Annalivia

Read More

I know your customers' passwords

Go to your ESP customer login page and use “View Source” to look at the HTML (under “Page” on Internet Explorer, “Tools->Web Developer” on Firefox, and “View” on Safari).
Go on, I’ll wait.
Search for the word autocomplete. If it says something like autocomplete=”off” then your web developers have already thought about this security issue. If it doesn’t, then you might have a serious security problem.
What’s going on here? You’ve probably noticed that when you’re filling in a web form your browser will often offer to fill in data for you once you start typing. This feature is supported by most modern browsers and it’s very convenient for users – but it works by recording the contents of the form in the browser, including the username and password.
As a bad guy that’s very interesting data. I can take some off-the-shelf malware and configure it with the URLs of a bunch of ESP login pages. Then I just need to get that malware installed on your customers desktops somehow. A targeted web drive-by malware attack, maybe based on targeted hostile banner ads is one approach, but sending email to people likely to be ESP customers is probably more effective. Maybe I’ll use hostile email that infects the machine automatically, or – most likely – I’ll use a phishing attack, sending a plausible looking email with an attachment I’m hoping recipients will open.
Once the malware is installed it can rummage through the users browser files, looking for any data that matches the list of login pages I gave it. I just need to sit back and wait for the malware to phone home and give me a nicely packaged list of ESPs, usernames and passwords. Then I can steal that customer’s email lists and send my next phishing run through that ESP.
This isn’t a new issue – it’s been discussed since browsers started implementing autocompletion over a decade ago, and it’s been a best practice to include autocomplete=”off” for password fields or login forms for years.
How serious a risk is this for ESPs? Well, I looked at the customer login pages at several ESPs that have a history of being compromised and none of them are using autocomplete=”off”. I looked at several that haven’t been compromised that I know of, and they’re all using either autocomplete=”off” or a complex (and reasonably secure-looking) javascript approach to login. Correlation isn’t causation, but it’s fairly strong circumstantial evidence.
ESPs should fix this hole if they haven’t already. If any customers are upset about having to actually type in their password (really?) they can take a look at secure password management tools (e.g. 1Password, LastPass or KeePass).
Thanks to Tim at Silverpop for reminding me that this is a serious security hole that many ESPs haven’t plugged yet and pointing me at some of these resources.
More on passwords and application security tomorrow.

Read More

Phishing and trust

Tom Sather has a great post up on the RP Email marketing blog discussing phishing. His point is that phishing lowers the overall trust in email marketing. He lists a number of things marketers should consider doing to counteract that loss of trust.
I rely heavily on the use of tagged addresses to deal with phishing in my own mailbox. If an email doesn’t come to the right address, then it’s immediately tossed as a phish. Unfortunately, as data leaks increase this is becoming less effective as a strategy.

Read More