Ironport response

Last week I posted about a ESP that had a misconfiguration in their Ironport A60s that let spammers use the A60s to relay email to AOL. Earlier this week, Pat Peterson from Ironport approached me to talk about the problem and clarify what happened.
Ironport has provided me with the following explanation.

As part of a normal implementation a customer has a number of options they can choose from to setup their system.  How they handle messages on both their public and private interfaces can be easily configured based on the needs of their business.  IronPort has made sure that customers have the capability they require to configure their systems appropriately.  As with most products and services, proper usage is require for desired results.
In this case a configuration that is appropriate for some environments was viewed as a vulnerability because it was not appropriate for this specific environment.  Customers are warned about not configuring their systems to allow unauthorized domains to relay mail.  There are legitimate reasons why someone would want to allow external hosts to send mail through their IronPort, and functionality exists that allows customers to configure their systems to do that.  It should be noted that allowing any external host to relay mail through the appliance is neither encouraged nor recommended by IronPort.
In fact, the user documentation and CLI both clearly warn customers about the risk of allowing external hosts to relay mail through their IronPort.
Our customers are specifically warned during setup not to configure their systems to allow “any host to relay mail through your server.”  If someone purposely ignores these warnings and instead chooses to setup their IronPort to allow unknown domains to relay mail they can make themselves appear as an open relay, but that’s certainly not how the system was designed or intended to be used.

There is a broader message here. Anyone using any MTA needs to understand the configuration options as presented and make sure that the configuration does not allow unauthorized relay. In this case it was an Ironport MTA, but it could happen to any other MTA out there. Everyone should test their MTA after any configuration change to verify that it will not function as an open relay.

Related Posts

Update on Yahoo and the PBL

Last week I requested details about Yahoo rejections for IPs pointing to the PBL when the IP was not on the PBL. A blog reader did provide me with extremely useful logs documenting the problem. Thank you!
Based on my examination of the logs, this appears to be a problem only on some of the Yahoo! MXs. In fact, in the logs I was sent, the email was rejected from 2 machines and then eventually accepted by a third.
I have forwarded those logs onto Yahoo who are looking into the issue. I have also talked with one of the Spamhaus volunteers and Spamhaus is aware of the issue as well.
The right people are looking at the issue and Spamhaus and Yahoo are both working on fixing this.
Thanks for the reports and for the logs.

Read More

SenderScore Certified expands

ReturnPath announced yesterday that SenderScore Certified now covers 1.2 billion inboxes, including mail handled by Hotmail, Time Warner Cable, GoDaddy and eventually Yahoo. A number of filters are also using SSC, including Spam Assassin, IronPort Systems, Barracuda Networks and Cloudmark.

Read More

ESP unwittingly used to send spam

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.

Read More