ISP

Archived Posts from this Category

Sender complaints about spamfiltering

Posted by laura on 01 May 2008 | Tagged as: Blocking, Blocklisting, ISP, Industry

JD posed a question in my post about Postini and trying to sort out a customer getting marked as spam by their filtering mechanism and I think it bears more discussion than can be done in comments.

And sure, it’s a best practice for filtering companies to respond politely to requests from filterees. But is it a requirement? Do senders have a right to demand explanations?

There is not really an easy answer for that. My first response is “of course not!” but then I think about some of my clients who really have been trying to do the right thing and how we work through issue after issue and finally fix everything I can think of, but they still have delivery problems. These are not spammers, they are sending mail to people who have asked for it and by all measures do actually want it, but some mail is being blocked for reasons neither my client or I can figure out. In those cases it would be really nice if someone from the group doing the blocking would take 10 minutes to point me in the right direction and show me what I missed.

I have been doing this long enough to know that spamfilters are not 100% accurate. I know there are times when a specific block is outside the scope of what email the filter designer, or user, expected to block. Look at what happened when Yahoo started using the PBL a few months back. There was a bug in the implementation that neither Yahoo nor Spamhaus expected and that caused mail from IPs not listed on the PBL to be blocked because of the PBL. With a valid report of the problem, I could contact both Spamhaus volunteers and someone at Yahoo to point out there was a problem with the implementation. Yahoo and Spamhaus figured out the issue and fixed the problem and Yahoo is no longer blocking IPs not on the PBL for being on the PBL.

I do believe that there are times when feedback from senders and blockees is beneficial and can help improve the overall filters. I have clear evidence this is the case.

On the flip side, I also have been in the email business long enough to know that more than 99% of senders just want their mail delivered and do not care about anything other than getting into the inbox. They believe every block is a mistake and the ISP / spamfilter is wrong or broken. They are not interested in actually making sure the implementation of the filter meets the design goals, usually they do not care what the goals of that filter are. They are just interested in delivery of their mail. This creates a signal / noise ratio into the filters or ISPs that is so weighted to the noise side, there is almost no value to the filter or ISP in even having a channel for the small amount of signal.

The reality is that most senders do not spend a lot of time looking into a block before contacting the ISP. They use the ISP points of contact as a way to avoid doing hard work internally. This transfers lot more work onto the ISPs and makes them less conducive to working with any senders at all.

I also think there are slightly different obligations on commercial spamfiltering companies and ISPs in regards to listening to senders. Commercial spamfiltering companies are further removed from the end user than the ISPs are. In many cases the end user has no idea that the spamfiltering at their ISP has been outsourced to a commercial company and they have no internal resolution path. They can contact their ISP, but that is only useful if the ISP has an escalation path back to the filtering company. I think that this distance, and the fact that the spamfiltering companies are profiting directly from blocking mail, means that spamfiltering companies have more of a responsibility to be accessible to the people they are blocking. The irony is that the spamfiltering companies are generally less accessible to senders than ISPs are.

Overall I do not think that good spamfiltering happens in a vacuum, and that reliable reports from senders about inaccurate filtering help improve blocking schemes. Senders are not in a position to be making any demands of ISPs and filtering companies, however, I do believe that the end user experience would be better if there were more communication between senders and recipients. The problem is that the history of communication between the two groups has been contentious at best and there are only so many times the receivers are going to spend time listening to the senders, again.

I guess it boils down to no, senders do not have a right to demand explanations, but things might be better if more ISPs and spamfiltering companies engaged with non-spamming but blocked senders more often. Sorting out those non-spamming but blocked senders from legitimately blocked senders is the real trick and I expect if receivers could do that reliably, there would be no false positives.

AOL Postmaster blog

Posted by laura on 02 Apr 2008 | Tagged as: AOL, Blogroll, ISP

AOL announced today they are launching a postmaster blog http://journals.aol.com/pmtjournal/blog/

I’ll be updating the blogroll, too. I’ve been checking out some new delivery / marketing blogs the last few weeks.

Report spam button broken: an ISP perspective

Posted by laura on 27 Mar 2008 | Tagged as: Deliverability, ISP, Industry, Relevancy

This press release has been discussed in a lot of groups and sites I read. One of my favorite comments comes from one of the filter developers at a large ISP. He was asked “does the overuse/misuse of the this-is-spam button significantly affect the ability to do your job?” His response, reposted with permission,

The customer is always right. In my opinion, there is no such thing as ‘overuse’ of the report spam button. The more feedback we get, the better. Our job is to keep the user’s inbox in the state they want it. The more they tell us what they do and don’t want, the clearer picture we get about who is sending unwanted mail. So I would say, yes, it does affect my ability to do my job in that it enables me to actually do my job.

It might cause my job to involve more detailed research into people’s preferences and what to do with mail that people disagree about, but I don’t see that as a problem.

Just because a marketer doesn’t like that we consider our users’ opinions to be more important than theirs is not really a problem either as far as I’m concerned. I’m here to serve my users, not them. They can either send mail that people don’t respond negatively to, or I can put their mail in the spamfolder. It’s not like they are going to make any money by repeatedly mailing people who think their mail is spam anyway.

If senders really want ISPs to change things, that is one of the people they are going to have to convince to make the change. It does not seem that the current methodology to effect change is being effective. Senders who want more cooperation from receivers need to start listening to him, and his peers in the industry, and start making misuse of the this-is-spam button important to them.

The ISPs are open to feedback. Just yesterday I posted the request from AOL to get feedback on how ISPs and ESPs are using the data AOL is generating. They are actively looking at how bounce rates are used in order to send clearer, more useful data back to senders (bulk senders and ISP senders). Cooperate with them here, help them improve their processes and maybe they will be more open to listening to senders in the future.

Yahoo, part 5…

Posted by laura on 14 Mar 2008 | Tagged as: ISP, Yahoo

… wherein I rename this blog “What change did Yahoo make today.” No, really, I like the guys at Yahoo a lot, but really, occasionally I would like to blog about something different!

Today’s change, actually yesterday’s, is that Yahoo has closed their beta FBL program to changes or additions. It is a beta program, this is not unexpected. They will be making changes based on the results of that program and will open it up sometime in the future.

Yahoo!’s announcement

Due to the success of our beta program, we are currently making changes to the application process for the Yahoo! Mail Complaint Feedback Loop program. As such, we are *not* processing new applications at this time. We do hope to re-launch an improved, more streamlined online process for interested participants soon. Please check our Postmaster Help pages often for updates in this regard.

What does this mean? It means there will be a Yahoo, part 6 post on this blog!

Happy Friday, everyone.

Unauthenticated email

Posted by laura on 03 Mar 2008 | Tagged as: Authentication, ISP

A few weeks ago, NetworkWorld posted an interview with Mark Risher of Yahoo. In it, Mark talked about how Yahoo had no plans to outright block or refuse any unauthenticated email. Of course authentication will be a large part of their decision making for incoming emails but they cannot just refuse to accept mail that is unauthenticated, because there are times when unauthenticated email is the most important mail to their recipients.

A lot of marketers often seem to forget that they are competing for time and space with other, non-marketing, types of email. Email from friends and family and discussion lists are both more important to most people that the latest and greatest email advertisement. These are the emails people want to receive, the ones they open, read and respond to.

In terms of authentication, right now the majority of wanted emails are unsigned with DK or DKIM.  Sure there are the early adopters who are using DK/DKIM to sign their emails, and a few large ISPs have started signing outgoing email. But until the vast majority of wanted email is actually signed, recipient ISPs are going to have to accept unsigned email.

Looking forward, even if all of the ISPs sign email sent through their SMTP servers, there will still be some fraction of desired email that will be unsigned. Individuals and small businesses who choose to run their own mailservers may not sign email. Even though these servers make up a tiny fraction of total email, they make up a much larger fraction of wanted email. ISPs cannot block this email without angering their customer base.

Marketers should not be concerned about ISPs blocking unauthenticated email, as it is extremely unlikely that any major ISP will do that. Marketers should focus, instead on making their email relevant and wanted by the recipients. I have been recommending clients plan to have all their outgoing emails DK/DKIM signed by the end of 2008.

Yahoo delays, part 2

Posted by laura on 26 Feb 2008 | Tagged as: ISP, Yahoo

A number of people have posted to various mailing lists and made blog posts pointing to the Yahoo Mail blog post discussing recent problems Yahoo was having with mail. The general feeling seemed to be “AHA! That’s what is wrong!”

Unlike many of my peers, I do not think this explains the delivery problems senders have been seeing while attempting to deliver mail to Yahoo. The Yahoo mail blog article is talking about the Yahoo outgoing mailservers (smarthosts) for their non-webmail users. It is extremely unlikely that these are the same servers used for incoming email.

While I sympathize with everyone who had the AHA! moment and thought their delivery problems were being acknowledged and addressed by Yahoo! I do not think this is really what that blog post is saying.

I am hearing from people that Yahoo is aware of a problem with delayed incoming email, and they are working on fixing it. This does seem to be a broader problem than just bulk mailers, I am hearing from small and mid-size ISPs that they are having significant problems delivering email to Yahoo, too.

For more information about what Yahoo is doing to filter mail check out my previous post Greylisting: that which Yahoo! does not do.

Yahoo delays

Posted by laura on 20 Feb 2008 | Tagged as: ISP, Yahoo

You may have noticed increase in delays and rejections from Yahoo. I am certainly seeing a lot of customers complaining and hearing a lot of other delivery people commenting on problems getting mail into Yahoo. I have even heard from multiple ISPs that are struggling with full queues and delayed email.

No solutions or suggestions right now, just that everyone is having problems right now. I expect it will take some time for the backlogs to dissipate, even after the underlying problem is fixed. If I hear anything more I will post it here.

Articles I read today

Posted by laura on 12 Feb 2008 | Tagged as: ISP, Industry, Yahoo

It has been a rather busy day today, I do not have a full blog post. I did see a couple posts come across my RSS feeds. Both of them have content I want to talk about and discuss in a little more detail, as I think they touched on some very interesting issues.

Network World has an article interviewing Mark Risher from Yahoo. The article discusses Yahoo’s use of DomainKeys as part of their inbound mail filtering.

Mickey has an article about how to deal with ISPs when attempting to troubleshoot a blocking issue.

More details and commentary on both articles later this week.

ESP unwittingly used to send spam

Posted by laura on 11 Feb 2008 | Tagged as: ISP, Industry, Spam, Technical

Late last week I heard from someone at AOL they were seeing strange traffic from a major ESP, that looked like the ESP was an open relay. This morning I received an email from AOL detailing what happened as relayed by the ESP.

IronPort Open Relay Vulnerability

Systems Affected
IronPort A60 running software version 2.5.4-005. According to IronPort, later devices and software versions using the same filtering mechanisms are vulnerable.

Overview
In recent weeks, one or more rogue spammers have been using misconfigured IronPort A60s as open relays to send unsolicited emails for AOL users via open relay. It is important for IronPort device administrators to review their configuration to shore up any vulnerability to this web server exploit.

Diagnosis
A seemingly minor configuration mistake made years ago internally has been exploited over the last several weeks to send out massive amounts of unsolicited email to AOL users. The spam mail originated from an outside zombie server, apparently infected with remote mailing viruses (such as BackDoor.Servu.76) according to the IT contact at IP 66.139.77.16. <ESP> has a filter specifically designed to deliver email over IP ranges set for AOL only. However, it was listed before a filter designed to log and discard bounced emails coming in through the Internet-facing of the IronPort appliance.

Impact
We have received 6,500 customer complaints so far through the AOL feedback loop. As the IronPort devices are black boxes, we are unable to determine how many unsolicited emails were delivered across them. It is difficult to ascertain whether or not the rogue spammer(s) knew only AOL addresses were delivered using this exploit. It is important to note that only AOL addresses were delivered in our specific case due to the order of the filters.

Solution
The solution was simple: move the filter designed to log and drop bounce messages coming in from the Internet to the top of the filter list so it will run first, as other filters may direct the IronPort device to deliver the emails through this vulnerability.

Authors: Jake Lanza, Baigh Auvigne, Daniel Fox

Congrats to the ESP for noticing this so quickly and being on the ball to stop this leak so quickly.

The compromise was first noticed when email coming back through the AOL FBL did not match any mail sent by the ESP. Initially, the ESP contacted AOL to report a problem with the FBL, but in working with AOL employees determined the email was coming from the ESP’s IP addresses.

This highlights the need to not just process FBL emails, but also monitor them and react when there are emails in a FBL that you do not recognize.

Ironport has responded here.

Updating SenderID records for Microsoft

Posted by laura on 04 Feb 2008 | Tagged as: ISP, MSN/Hotmail

In the past, bulk senders who wanted Microsoft to check SenderID had to email information to a special Microsoft address. Microsoft would then cache the senderID data from the sender’s DNS records and verify incoming email.
Microsoft has simplified the process and now has a webform to submit the data.

http://support.msn.com/…

In order to submit your information you will need a contact email address, the domains that you want to add and the SPF records of those domains.

Next Page »