Re: Firewall Upgrade

[Derek Diget <derek.diget+educause-security () WMICH EDU>]

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/
***********************************************************************