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

Comcast rate limiting

Russell from Port25 posted a comment on my earlier post about changes at Comcast.

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

e360 in court again

Today’s edition of Magilla Marketing announced that Dave Linhardt and e360 have sued Comcast. Spamsuite.com has the text of the complaint up.
On the surface this seems quite silly. e360 is alleging a number of things, including that Comcast is committing a denial of service attack against e360 and locking up e360’s servers for more than 5 hours. Additionally, e360 is laying blame at the feet of multiple spam filtering companies, including Spamhaus, Trend Micro and Brightmail.
One of the more absurd claims is that Comcast is fraudulently transmitting ‘user unknown’ messages. At no point do they explain how or why they think this is the case, but simply assert:

Read More