mail server connection hanging forever

[Richard Gooch]

Brian J. Murrell writes:
> from the quill of Richard Gooch <rgooch@ras.ucalgary.ca> on scroll
> <200007141327.e6EDRWi21710@vindaloo.ras.ucalgary.ca>
> > 
> > Go ahead if that's what you want. I don't.
> 
> I don't want either, but please understand something before you slam
> it.  Slamming something based on misinformation or misunderstanding
> serves nobody any good.

I guess I did come across that way. I'm slamming it because I feel
like identd is being shoved down my throat and I'm being asked to
swallow. Like I said earlier, yeah, I'm bitter.

> > Sendmail wants us to run it and report real usernames.
> 
> Really?  Where is the requirement written that an identd must return
> a username?  Sendmail just takes the "user identifier" portion of
> the ident return data and sticks it in a Received: header.  I don't
> think sendmail would give two whoops if the data was an opaque value
> that only the identd owner knew the meaning of.

Identd out of the box returns a real username. I bet if identd out of
the box returned an opaque cookie, there would have been less
incentive to use it in sendmail. Or at least, it might be an obvious
config option: "turn on ident queries if you want better auditing on
your internal network. For external delivery, it is better to leave
this off since most sites are configured to return opaque cookies (or
don't run identd at all) for security/privacy reasons, and making
ident queries slows down mail delivery".

And even opaque cookies leak privacy information: traffic analysis.

> > But I allow all my machines to make direct SMTP connections. So I need
> > to block ident at the firewall, in case someone misconfigures (or even
> > installs) some box and turns on ident.
> 
> Yes this is troublesome.  It is an argument for outbound relay but I
> certainly do not want to tell you how to run your network so let's
> not open that can of worms either.  :-)

I can see why it makes sense in some environments. It has pros and
cons, though. We don't need to block outgoing SMTP connections here,
and since I'm not a control freak, I don't bother. My life is easier
with outgoing SMTP connections permitted.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca