-----Original Message----- From: John Hardin [mailto:jhar...@impsec.org] Sent: vrijdag 8 mei 2009 15:52 To: Mark Cc: users@spamassassin.apache.org Subject: RE: Odd behaviour under load.
> On Fri, 8 May 2009, Mark wrote: > > > From: Charles Gregory [mailto:cgreg...@hwcn.org] > > > > Do yahoo and python.org enforce a shorter time-out? > > > > Highly doubtful. RFC 2821, Section 4.5.3.2 ("Timeouts") gives you a 2 > > minutes window while awaiting the "354 Start Input" reply to a DATA > > command. > > ....are you sure that's the timeout he's referring to? > > I suspect the sender is timing out waiting for the "250 OK" after > sending the message, hence my (humorous) "100 Please hold..." > suggestion. (Jeeze, SM, lighten up!) I suspect that's indeed what he meant. I guess I took his "So obviously some systems were 'timing out' waiting for my server to respond to the DATA command." a bit too literal. > How does SA come into play **before** the sending MTA sends the > message body? It doesn't. :) That's why it did make no sense to me. > More likely the client is disconnecting after the timeout and > _assuming_ a 4xx state, and requeueing the message > > If there's any problem with Charles' server it's that it continues > delivery after the sending client has dropped the connection. > I wouldn't really see that as a problem, though, as I'd rather get > multiple deliveries in that case than have both sides make assumptions > the other direction and _lose_ the message. Well, _assuming_ a 4xx state is an assumption, too. :) And not one I like per se, to be honest (though one could make a good case for its rationale, saying an unexpected disconnect is precisely the kind of 'transient' error-state the 4.x.x codes are meant to cover). But resending a message, over and over, without the receiving server indicating such need, well, that could here and there raise an eyebrow or two as well. Okay, working from the idea that indeed the connecting client is timing out waiting for the "250 OK" after sending the message, I would think DNS lookups are the most costly, time-wise. So, I would examine the RBL lookups first: it only takes the presence of one or two defunct DNSBL lookups, or an unruly 'rbl_timeout' setting, to muck things up. - Mark
