This is mainly addressed to the IronPort employees who hang out here.
I found this thread on a discussion board while searching for something else. The bottom line is that AsyncOS does not follow RFC 2034 in its use of enhanced SMTP status codes because it precedes them with a "#", like this:
550 #5.1.0 Address rejected.
instead of this:
550 5.1.0 Address rejected.
This prevents SMTP clients which implement RFC 2034 from noticing the enhanced status code. AsyncOS doesn't advertise the ENHANCEDSTATUSCODES capability, so it isn't actually breaking the rules. But if IronPort is going to go to the effort of putting those codes in there, then why not follow RFC 2034?
[quote:1903d3ddb0="Mark [CSE]"]That is kinda right, but we never announce after the EHLO that we do follow the advanced status codes. Yes I know. That's what I said:
AsyncOS doesn't advertise the ENHANCEDSTATUSCODES capability, so it isn't actually breaking the rules.
My question is, since you're putting the enhanced codes in there anyway, why not do it in a way that conforms to RFC 2034 so that conformant clients can use them? No one recognizes Dan Bernstein's sharp style, so those codes aren't really doing any good except to human readers. But human readers have the explanatory text. The enhanced codes are meant to be machine readable, so it's useless to put them in there in a way that negates this purpose.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...