Showing results for 
Search instead for 
Did you mean: 

AsyncOS 7.0.0 ??

Level 1
Level 1


My 2 C160 (in release 6.5.3 for now) have an available update to AsyncOS 7.0.0 apparently released in 11/09. OK but why there is now release note about this version anywhere, ironport site alsways talk about 6.5.3 as the last version.

Anyone have information about this ?


1 Accepted Solution

Accepted Solutions

Tom Foucha
Cisco Employee
Cisco Employee

AsyncOS 7.0.0 has been released as an "early release" or FCS Limited Release to a subset of customers. You can see on the support portal that status along with release notes. Full GA (General Availability) is generally be shortly thereafter.

View solution in original post

6 Replies 6

Tom Foucha
Cisco Employee
Cisco Employee

AsyncOS 7.0.0 has been released as an "early release" or FCS Limited Release to a subset of customers. You can see on the support portal that status along with release notes. Full GA (General Availability) is generally be shortly thereafter.

Cisco stated: This version (7.0.1) will be released next month (feb 2010)


Does that C-series AsyncOS 7.0.1 version include 'SMTP Call Ahead' feature? That is a new LDAP alternative method for recipient (RCPT TO) address verification. Similar to Postfix MTA verify feature;

It's been mentioned in Ironport forum that it's coming, but is it included in that 7.0.1 version? If not, when do we get such a version supporting this feature?

Our customers do not like creating LDAP connections from C-appliances located in DMZ to their LDAP servers located in their private LANs. SMTP Call Ahead would be the solution since it's done via the same SMTP opening where the messages are being delivered to the target mailbox servers. And there are even no legacy VRFY requirements for target mailserver since the verification is being done by EHLO/MAIL FROM/RCPT TO and then listening for the reply code '200 Ok' or '505 User unknown', and then using this information either allow or reject incoming mail traffic for this recipient. The method is sure interoperable with most of the mailbox servers out there. For example in MS Exchange you just need to activate recipient filtering to allow incoming mail only for those SMTP addresses that are listed in Active Directory. No maintenance, no updates, no LDAP connections, no LDAP accounts, but just the SMTP opening against the target mailbox server.

There is something similar on the testing phase and there is a big maybe doesn't mean that it'll make it.

On the other hand looking up the limitation for postfix and this "call ahead" feature will make anyone think twice for using it.

This is from POSTFIX site:

Limitations of address verification

  • When verifying a remote address, Postfix probes the nearest MTA for that address, without actually delivering mail to it. If the nearest MTA accepts the address, then Postfix assumes that the address is deliverable. In reality, mail for a remote address can bounce AFTER the nearest MTA accepts the recipient address.

  • Some sites may blacklist you when you are probing them too often (a probe is an SMTP session that does not deliver mail), or when you are probing them too often for a non-existent address. This is one reason why you should use sender address verification sparingly, if at all, when your site receives lots of email.

  • Normally, address verification probe messages follow the same path as regular mail.  However, some sites send mail to the Internet via an intermediate relayhost; this breaks address verification.  See below, section "Controlling the routing of address verification probes", for how to override mail routing and for possible limitations when you have to do this.

  • Postfix assumes that an address is undeliverable when the nearest MTA for the address rejects the probe, regardless of the reason for rejection (client rejected, HELO rejected, MAIL FROM rejected, etc.).  Thus, Postfix rejects mail when the sender's MTA rejects mail from your machine.  This is a good thing.

  • Unfortunately, some major sites such as YAHOO do not reject unknown addresses in reply to the RCPT TO command, but report a delivery failure in response to end of DATA after a message is transferred.  Postfix address verification does not work with such sites.

  • By default, Postfix probe messages have "double-bounce@$myorigin" as the sender address (with Postfix versions before 2.5, the default is "postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does not reject mail for this address.

    You can change this into the null address ("address_verify_sender ="). This is UNSAFE because address probes will fail with mis-configured sites that reject MAIL FROM:  <>, while probes from "postmaster@$myorigin" would succeed.

YIKES!!!  I don't want to be black listed... Plus there is mention of 6 seconds delay per recipent validation the first time around...without too much dive into this... I would raise a flag of caution...

On IronPort side of things...stay tuned..   that's my two cents  

Postfix verify feature uses local cache file for previously made verifications. For both negative and positive answers. You can adjust cache TTL values freely. Without any adjustments it's been working beautifully in several Postfix based MTA's that I use to maintain. Somethiong quite similar behaviour would be good in C-series appliances. That verify cache really decreases the extra recipient verification load on target mailbox server, and it makes recipient verification process running without notable delay in the front-end MTA router.

We have even tested and used Postfix verify feature to reject mail traffic for forged sender email addresses. There's spam coming in from faked sender addresses like even that address is not used. So it's forged mail. In Postfix MTA that verify feature can be configured also using the same recipient verify method to allow or reject inbound mail for according to the given sender address (MAIL FROM). After creating a new local email address into our mailbox server, it takes some short moment (see above TTL) while the Postfix front-end is clearing the cache for this sender or recipient and tries making online verification against target mailbox server. The TTL delay causing new local mailbox visibility not to happen in realtime, is not disturbing at all.

The IronPort appliance already does cache the ldap lookups and it's configurable to how many entries it should cache and how long should retain the cache. so under the "System Administration" > "LDAP" click to anyone of your ldap profile to edit then click on the word "Advanced". There you will see the "Cache TTL" and Maximum Retain Cache Entries".

Hope that helps!