John Harmon wrote:
Edvin Seferovic wrote:
The only time I've ever seen this is when you are using a MySQL
backend and using smtp auth and all the mysql connection slots are
used.
This would be my next idea :)
Maybe you use a slow DNS server and use RBLs ?
Regards,
E:S
1. As far as I know, I do not use a mysql back end. I have it setup
as outline on shupp.org/toaster (didn't install tmda and mgmt tools)
2. When this occurs, despite a failure on the client side, the email
seems to really send about 50% of the time.
3. Here is the output of /var/log/qmail/smtp/current during a failed
attempt:
@4000000047d187dd1625fd94 tcpserver: ok 428 0:10.0.0.10:2525
:10.0.0.50::2662
@4000000047d187dd1fdc16fc CHKUSER accepted sender: from
<[EMAIL PROTECTED]:[EMAIL PROTECTED]:> remote
<[10.0.0.50]:unknown:10.0.0.50> rcpt <> : sender accepted
@4000000047d187dd21bca66c CHKUSER accepted rcpt: from
<[EMAIL PROTECTED]:[EMAIL PROTECTED]:> remote
<[10.0.0.50]:unknown:10.0.0.50> rcpt
<[EMAIL PROTECTED]> : found existing recipient
@4000000047d187dd26e8da84
simscan:[428]:RELAYCLIENT:0.0525s:-:10.0.0.50:[EMAIL PROTECTED]:[EMAIL PROTECTED]:
@4000000047d187dd337d0d9c tcpserver: end 428 status 0
4. RBLs??? Are you referring to some type of receive buffer? Not
sure what you are referring to here
5. I don't know about "slow" DNS, but this server is a own DNS
server. Do you think that might be in play here??
My DNS servers as outline in my resolv.conf are:
nameserver 198.60.22.2
nameserver 198.60.22.22
Both of those DNS servers are my ISPs servers, and I am on a direct
fiber connection to them (15mbps).
Here are my ping results to both servers:
mail:/etc # ping 198.60.22.2
PING 198.60.22.2 (198.60.22.2) 56(84) bytes of data.
64 bytes from 198.60.22.2: icmp_seq=1 ttl=61 time=2.63 ms
64 bytes from 198.60.22.2: icmp_seq=2 ttl=61 time=2.83 ms
64 bytes from 198.60.22.2: icmp_seq=3 ttl=61 time=2.71 ms
64 bytes from 198.60.22.2: icmp_seq=4 ttl=61 time=2.66 ms
--- 198.60.22.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 2.633/2.713/2.837/0.093 ms
mail:/etc # ping 198.60.22.22
PING 198.60.22.22 (198.60.22.22) 56(84) bytes of data.
64 bytes from 198.60.22.22: icmp_seq=1 ttl=61 time=2.92 ms
64 bytes from 198.60.22.22: icmp_seq=2 ttl=61 time=2.76 ms
64 bytes from 198.60.22.22: icmp_seq=3 ttl=61 time=2.70 ms
64 bytes from 198.60.22.22: icmp_seq=4 ttl=61 time=2.56 ms
Thanks,
John
OK. After having one of my coworkers read a couple of LAN traces for
me, here is what we have:
On a good trace, the client sends a Carriage Return Line Feed (<CR>) 3
times, adds a period to its own line, and finishes off with on more CR.
In SMTP terms this is the signal to the server (the period on its own
line) that the data transmission is complete and the email needs to be
sent (as far as I understand it). The server acknowledges it with a TCP
ACK and then responds with a 250 ok #########. The client then sends a
QUIT and the connection closes. One note, the CR, CR, CR, . (dot), CR
is all in one packet sent from the client to the server.
On the bad trace a CR, CR, CR is sent in one packet, a dot, CR is sent
in another packet, and the server sends a TCP ACK that it received
them. At that point the client times out after waiting for 60 seconds
WITHOUT ever receive a 250 ok ######### from the server.
Without debug logs it sounds like qmail's smtp doesn't correctly
reassemble or read the packets when sent in 2 packets (I am making an
assumption here). This would seem like a bug to me.
Based on the info above, if someone has an answer then GREAT!; however,
I think the next step is to run smtp debug logs. I don't know how to
set the qmail smtp to a debug log level. Does anyone else out there know?
Thanks,
John
