On Tue, 28 Sep 2004 14:34:54 +0200, Volker Kindermann <[EMAIL PROTECTED]> wrote: > Hi Siju, > > The Port 113 was opened because the PF FAQ asked to open it for SMTP > > > > "Auth/Ident (TCP port 113): used by some services such as SMTP and IRC.
The "auth" service (aka identd or "tap") was useful back in the day of multi-user machines where it could assist in providing information about which of many users (assuming none had root) originated an outbound TCP session. The service is of limited value today, and can in certain instances reveal information about processes on your server (this "information leakage" is addressed by OpenBSD's "-h" option to identd.) > I know that this is in the pf faq but I don't think that you really need it. I don't > know about IRC but you mentioned only SMTP on your side. Many IRC servers will drop sessions if they cannot talk to an ident service on the originating end. If you don't want your users to be on IRC; this could be considered as a benefit of blocking TCP/113 ;) > I'm running emailservers for years now and never ran an identd. And my clients don't > have an identd running either. > I don't think that you need this for smtp nowadays. While the identd service is not *mandatory* on servers which send outbound SMTP email, many remote SMTP servers will query identd when your machine connects as a SMTP client. If the service responds on your client, the username returned will be logged in the Received: header at the remote mail server. If your machine returns a RST in response to the SYN, the remote server will give up looking for identd and move on with the conversation. If your firewall blocks and drops the SYN packet on the identdport (TCP/113), the remote server will wait for an answer, and retransmit, sometimes for thirty seconds or more. Bottom line, if your server sends SMTP email to arbitrary remote SMTP servers, is is detrimental to "stealth" ident. If your mail sending host does not accept ident connections, your firewall rules should return RST, or live with the delay (and possible timeout failures) on each outbound SMTP session. Kevin
