I wish that I knew of a way to set this, but the only info that I have was
obtained with
the help of my up-stream provider -- AT&T. They were helping me to
trouble-shoot a
strange mail problem. In any event, in my case responses were always in the
4000's and
sequentially updated with every message sent.
The only place (that I know of) you might get into a UDP vs. TCP issue is
that IMS
needs to find the domain. To do this, it must also send out a port 53 UDP
request to a
DNS server. I have not been able to prove it (actually, too lazy to configure
a proper
sniffer for this), but it appears that IMS may also send out a port 53 TCP
request --
presumably if it had a problem with the UDP DNS request.
However, I once had a similar problem. My purpose was to prevent mail
requests
from all hosts on my network to any host outside of my network (like a mail
sending virus
might do). The only allowed exception would be the mail server. I put in an
access
(wrong) list like this:
permit tcp host MailServerIP eq smtp any
permit tcp host MailServerIP eq pop3 any
deny tcp any any eq smtp
deny tcp any any eq pop3
permit ip any any
The result was that I could send mail to my mail server, but it simply
got stuck
there in the holding queue!
To correct this, I used the following:
permit tcp host MailServerIP eq smtp any
permit tcp host MailServerIP eq pop3 any
permit tcp host MailServerIP any eq smtp
permit tcp host MailServerIP any eq pop3
deny tcp any any eq smtp
deny tcp any any eq pop3
permit ip any any
This seems to work well. So well, that if you have anyone on your
network
that is using an external e-mail server (non-web-based), they will not be able
to get to
it. Then you will have to put in the "forever" task of an exception set of
lines.
Because I have a lot of game players on my net, I only block selective
ports. So
my solution may not exactly fit your need. You may also wish to use some cisco
"established" command. These can be more forgiving for outgoing requests and
will allow
any port to come back so long as it was as a result of the internal request and
not
otherwise blocked by a higher command in the access list.
Hope that helps.
Rich
-----Original Message-----
From: Greg Baumgratz <[EMAIL PROTECTED]>
To: [email protected] <[email protected]>
Date: Tuesday, January 13, 2004 2:09 PM
Subject: Mail Transport ports
>Here's a question: When your mail server sends mail by smtp it goes out
>on port 25. Any ideas of the range the responses will come on? When
>your server receives mail, the connection will always be incoming on
>port 25, but when you send messages from your server, they will go out
>25 and the responses messages will come on other ports. The reason
>behind this is if in your router, you block all packets to your
>mailserver other than port 25, you can receive mail without a problem,
>but you can no longer send mail. I have recorded packets in the 2000s
>and 3000s as reponse messages, of course coming with a source port of
>25. As far as I know, you can not permit packets in the cisco based on
>source port, only destination.
>
>Is there a rule that defines the ports the responses will return on?
>
>Greg
>
>
>
>This is the discussion list for the IMS Free email server software.
> To unsubscribe send mailto:[EMAIL PROTECTED]
>
> Delivered by Rockliffe MailSite
> http://www.rockliffe.com/mailsite
> Rock Solid Software (tm)
>
This is the discussion list for the IMS Free email server software.
To unsubscribe send mailto:[EMAIL PROTECTED]
Delivered by Rockliffe MailSite
http://www.rockliffe.com/mailsite
Rock Solid Software (tm)
