On Friday 24 May 2002 02:15, Michael Doughty wrote: > > Yes, and it is the sending port that is blocked. That is my point. > > If a remote mail server sends a message to our mail server using a > > non-privileged port (i.e. the port they use to send the msg to us), > > and we block that port, then their mail server will simply see a > > dropped connection (or some such). If it happens to chose various > > ports that we have blocked, then it may well give up and tell the > > sender that it cannot send mail to our site. > > I see. So you are talking about a rule that filters based on the > source port? Generally, this is not desirable for the exact reason > you are describing. The source port is a randomized non-priveleged > port. What exactly do you expect to gain from filtering on source > port, besides lack of compliance? Any program can start on any port > provided the proper configuration of the source system. The source > port really tells you nothing about the program. > That's it! You got it :-) And you have done exactly what I wanted, which is simply someone to confirm what I suspected - that source port filtering is probably doing nothing but causes problems (albeit probably for the sender!). I have no idea why the source ports are being blocked, however I have just confirmed it from home using my linux box, the 'nc' command and one of the blocked ports. In attempting to contact the mailhubs I got a 'no route to host' error; just changing the source port number and it works fine.
All I've got to do now is show the manager that someone's made a bit of a mistake...:-) John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] PGP key available from public key servers