[H-GEN] Mail problems

Gearon, Paul pgea at qcom.com.au
Wed Jul 7 22:32:29 EDT 1999


(Note reply-to: being general at humbug.org.au vs "Gearon, Paul" <pgea at qcom.com.au>)

> All internal mail is handled by the MSES.  I have no problem with this
> system at all (it hasn't even crashed the NT server for over a week
> now 8^).
> It seems to be some odd interaction when MSES sends forwards mail to
> Sendmail for delivery.  As far as I can tell, under certain situations
> (which I have not identified yet), sendmail does not send the "220
> Message
> Accepted" after MSES sends the "." data terminator for the message
> until
> after MSES times out and closes the connection.  
> 
It sounds like sendmail is waiting for the end of line after the ".".
Is it MSES sending a newline character after the "." ?  What happens if
you telnet into sendmail and send a manual message?  Does that work, or
does sendmail still pause?

> Is it possible this is actually something to do with the kernel as
> Paul
> suggested?  I have tried using netstat during this 10 minute period.
> Both
> ends show the connection as being established still and the Linux end
> has no
> packets queued (well, not that netstat shows anyway).  I hope I don't
> have
> to go to the extent of trying to run gdb with sendmail to see why it
> is
> waiting 8^(.
> 
I doubt it's your kernel.  It's just that I'd heard there are problems
with 2.2.5, so it's worth an upgrade anyway.  Who knows, maybe you'll
strike it lucky  :^)

To have a closer look at what MSES is doing (since telnet lets you look
at what sendmail is doing) I'd be tempted to knock up a quick perl
script like this (disclaimer - I KNOW this is wrong, but I don't
remember the SMTP commands):

#!/usr/bin/perl
open(VLOG, ">/tmp/mail_log");
print "220 belial.tams.com.au sendmail\n";
<STDIN>;
print "250 OK";
<STDIN>;
print "250 OK";
<STDIN>;
print "250 OK";
<STDIN>;
print "250 OK";
while ($_ = <STDIN>) {
  chomp;
  last if ($_ eq ".");
}
print "221 closing connection\n";


Then stop sendmail and create an entry for port 25 in inetd.conf which
points to this.

This might give you a hint anyway.  The nice thing is that you can say
 print VLOG, $_;
to send the current line to the log file, if you like.

Not perfect, but it give you another avenue for tracing the problem.

Regards,
Paul

--
This is list (humbug) general handled by majordomo at lists.humbug.org.au .
Postings only from subscribed addresses of lists general or general-post.



More information about the General mailing list