Educause Security Discussion mailing list archives
Re: Firewall Upgrade
From: Derek Diget <derek.diget+educause-security () WMICH EDU>
Date: Fri, 14 Feb 2014 15:42:29 -0500
Disclaimer: We don't have a PA in operation. We have one in "by-pass" mode right now. We intend to switch in the next few weeks from an ASA to PA. I am also our main email admin, and do security related to that. I am in no way a network engineer. Just someone that can send an email from a telnet session to an MTA just about as fast as a mail client can. :) On Feb 14, 2014 at 19:44 -0000, Roger A Safian wrote: =>Just out of curiosity, the problem you could be creating is for the =>external smtp server, yes? And your MTA as it has seen enough packets to open a connection via the PA, establish a SMTP dialogue with the sending MTA, get the RFC5322.MailFrom, list of recipients, and even the message body. If the PA closes the session, it needs to do it on both sides. A good 5XX SMTP response with a string of something like "Message rejected for policy reasons" to the sending system would be nice. Just closing the connection should cause a queue and retry on a _legitimate_ mail server. If the SMTP response is given or the socket closed on the this side (outside) of the PA there are no real issues for you beside wasted bandwidth for the potential retries. The problem that I see is your "inside" MTA and it is more tricky. After the DATA command (where the message body is sent) in SMTP, there isn't a way for the sender (PA in this case) to tell the receiver (your MTA) that it doesn't want the message to be sent. So unless the PA is masquerading the DATA command, faking a SMTP response for your MTA to the sender, and then capturing the sender sending the message body (all while your MTA patiently waits for the DATA command from your PA) there really isn't a clean way to "block" the message at the PA with regards to not leaving your MTA hanging. After a while (ten minutes if waiting for DATA/msg body to be sent), your MTA will close the connection. Some MTAs will discard what it had in its buffers as it never was able to send the OK response after receiving the DATA, but I have seen some poorly written MTAs think that the remote site just closed the session improperly and still relay the (blocked) email on. (I don't remember what theses MTAs were as it was several years ago when our Cisco CSS would close the connection early and our MTA would rightly retry thus causing recipients duplicate emails.) Note that the above is for a plain clear text old (aka SMTP/HELO) SMTP session. When you start talking ESMTP/EHLO session and extensions, things get more complicated when you are dealing with PIPELINING (command batching), Chuncking or BDAT and several other extensions that come into play. This is starting to remind of the head aches that SMTP Fix-Up caused. Time to put the issue into my subconscious mind for the weekend and see how it cooks over the weekend. :) =>BTW, don?t most mailers give up after a while?72 hours or so? Most legitimate MTAs do. Their retry interval varies from site to site and can very from a few minutes to a few hours with some doing some-kind of back-off. But then you also have grey-listing going on in places as well. -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***********************************************************************
Current thread:
- Re: Firewall Upgrade, (continued)
- Re: Firewall Upgrade Thomas Carter (Feb 14)
- Re: Firewall Upgrade Robert Lau (Feb 13)
- Re: Firewall Upgrade Chris Davis (Feb 14)
- Re: Firewall Upgrade Ben Parker (Feb 14)
- Re: Firewall Upgrade Mike Osterman (Feb 14)
- Re: Firewall Upgrade Ian McDonald (Feb 14)
- Re: Firewall Upgrade Mike Osterman (Feb 14)
- Re: Firewall Upgrade Roger A Safian (Feb 14)
- Re: Firewall Upgrade Pete Hickey (Feb 14)
- Re: Firewall Upgrade Mike Osterman (Feb 14)
- Re: Firewall Upgrade Derek Diget (Feb 14)
- Re: Firewall Upgrade randy (Feb 14)
- Re: Firewall Upgrade Nathaniel Hall (Feb 14)
- Re: Firewall Upgrade Mike Osterman (Feb 14)
- Re: Firewall Upgrade Mike Osterman (Feb 14)
- Re: Firewall Upgrade Ben Parker (Feb 14)
- Re: Firewall Upgrade Mike Osterman (Feb 14)
- Re: Firewall Upgrade Mark Rogowski (Feb 14)