you are correct as said in the TID also says cisco has released a fix for this.
/quote/ Cisco has corrected this issue in later software releases. Customers who do not want to turn off Mailguard must contact Cisco for the latest updates to the PIX operating system. /end quote/
as said in the TID a well secured server will not have any problems. you are opening SMTP to the server as long as the server is not an open relay I would not see a problem.
/quote/ The Mailguard feature is intended to help protect weakly secured mail servers /end quote/
/quote/ Mailguard allows connections to an e-mail host through Transport Control Protocol (TCP) port 25 only. It logs all Simple Mail Transfer Protocol (SMTP) activity and allows only the minimum SMTP server commands found in Request for Comments (RFC) 821, Section 4.5.1. /end quote/
It depends on how much of an RFC lawyer you want to be. It appears that someone is pretty picky, as I don't recall anyone ever raising this issue before.
If you want to argue back, you could use the fact that RFC 821 uses the qualifier "usually" in describing originating the 220 connection message. This could be one of the times that isn't "usual" -- and if your implementation happens to throw in a gratitutious 220 message with a different format, then so be it ;-)
In a follow up you spoke of "risk". There is a security risk in leaving the hostname exposed. If someone does a portscan looking for smtp servers, it is better that you don't tell them who you are, at least not until you have more reason to trust them.
Other than that, if the smtp fixup is enabled, then it restricts permitted commands to a relatively small subset of SMTP, with no ESMTP extensions, and it restricts command lengths, but it does not restrict the length of anything within a DATA flow. The questions then becomes "Do you trust that your mail server would be able to handle commands of indefinite length", and "Do you trust that your mail server would be able to handle arbitrary unfiltered commands, possibly including obscure ESMTP features?"
The smtp fixup is good for the mail servers of days gone by, which might have included accessible DEBUG features (sometimes it just isn't feasible to update a computer more than every couple of decades...). Modern mail server bugs are -usually- more subtle. e.g.,
Sendmail 8.13.7 is available (2006-06-14); it contains a fix for a potential denial of service problem caused by excessive recursion which leads to stack exhaustion when attempting delivery of a malformed MIME message.
That's going to get by PIX mailguard anyhow.
There -have- been occasional mail server security issues in the last few years that PIX mailguard would have blocked... just has there have (for example) been BIND9 security issues involving features that earlier BIND versions didn't have at all. risk vs utility...
The RFC states that the text of SMTP replies is only for human users (i.e. to troubleshoot) and are not required for the operation of an MTA.
Since most MTAs like to tell the whole world their version number, minor revision number, OS and patch level of the OS, giving hackers more info than they require, Mailguard changes all non-numerical replies to xxx to hide that info from the outside world. Mailguard also disables many SMTP commands to prevent additional data leakage (EXPN and VRFY, for example).
The risk of turning Mailguard off is that your MTA is then naked on the Internet. If you know your stuff and use an MTA that does not have
984574372643 known vulnerabilities, then go ahead.
The only two problems I have seen with keeping Mailguard on, is (a) that unless you run PixOS 7, you can't use any of the ESMTP commands of RFC2821 and (b) the Pix will eat messages that have the . combination split between two packets *and* where the receiving party replies to the frist half of the combination with a "250 Message accepted".