Hi Markus,

I see where you are coming from with this, but I don't think that is the
problem.  We've checked with the senders and their firewalls only log ONE
outbound connection to us.  If the 250 OK was not being sent, the sender's
SMTP gateway would make multiple connections (one for each repeated
message).  This being the case, it does look like a local problem - but I
can't seem to find the message anywhere!

We'll investigate further (in case the sender's firewall were not being
totally honest ;)).

Thanks!

Shash


-----Original Message-----
From: Markus Stumpf [mailto:[EMAIL PROTECTED]]
Sent: 16 March 2001 18:49
To: Steve Crowder
Cc: [EMAIL PROTECTED]; Harald Hanche-Olsen; Shashi Dookhee
Subject: Re: Repeated Identical Messages


On Fri, Mar 16, 2001 at 05:44:54PM -0000, Steve Crowder wrote:
> We restarted our qmail server last night explicitly adding to
> control/timeoutsmtpd a value of 1200
>
> as per the mail by \Maex

1200 is the default. So setting this to 1200 won't change anything ;-)
btw. you do not need to restart qmail, this file is read by every invocation
of qmail-smtpd (i.e. on every new connection).

I have looked at the code of qmail-smtpd.c
The 451 timeout is issued by the receiver if it doesn't get any
infos from the sender within timeout (=1200 default or from
timeoutsmtpd).

- the message seems to have arrived successfully (including CRLF.CRLF)
  otherwise the receiver wouldn't have it correctly in queue.
  At that point if the connection breaks the mail will be delivered.
  (if there where no local filesystem problems, message size problems,
  too many hops or the like).
- Then the receiver sends back the "250 ok tstamp qp pid".
  This tells the sender that the message was received ok.
  And it looks like this code never arrives at the sender.

Would all of you that have the problems mind makeing a test and
inserting an explicit
    flush();
call in qmail-smtpd.c in function acceptmessage() as the last statement.
This *should* not be needed, as the data command has a flush entry ...

What *really* puzzels me is that saferead() spits out an error to the
sender before closing, but safewrite() simply does an _exit(1).
Maybe inserting some error output could also help tracking down the
problem.

        \Maex

--
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
Stress is when you wake up screaming and you realize you haven't fallen
asleep yet.

Reply via email to