Thank you everyone for your suggestions. I really appreciate the help.
I did what Dave suggested and emptied the /var/qmail/control/
blacklists file and then reloaded. No change. Then I tried Eric's
suggestion and set my external IP address the same as SM in the
tcp.smtp file and rebuilt. This allowed me to send mail without delay.
So it must be something within the server.
And although I am not seeing it myself, others with email accounts on
the server are now reporting getting hundreds of duplicate incoming
messages. Yuck. I think I might be fubar'd. On the other hand, maybe
this gives someone an idea of where to look?
Thanks again for you generous help.
On Jul 21, 2009, at 1:45 PM, Eric Shubert wrote:
That would be a good test, Dave. FWIW, Jake wrote a script that
checks for inactive RBLs and removes them from the configuration. I
think it's part of QT-plus.
The main thing that's different about SquirrelMail is that it's
essentially configured as an open relay for localhost. This is done
in the tcp.smtp file. Personally, I think it'd be better to have SM
authenticate itself, which I think Jake may be changing in a future
release.
Anyhow, in an attemp to isolate the problem, I would select an
external IP address to use for testing, and configure it the same as
SM in the tcp.smtp file (don't forget to rebuild the cdb). If the
remote client works as an open relay, you know it's something within
the server. If the remote client still has a delay, you know it's a
networking issue, since SM works ok as an open relay.
I would bet on the later, but not much. An extra entry in a routing
table could cause sporadic behavior like this in a network connection.
d...@acbsco.com wrote:
Jim,
Not sure, but you could try to empty the contents of your /var/
qmail/control/blacklists file and then reload the qmail control
files. (make a backup of your blacklists file of course)
# /etc/init.d/qmail reload
In the past, I have read about delays, and one of the rbl's was
having to timeout before the email would be sent and/or received.
Yes, it seems odd that the rbl's would be checked on outgoing
email, but by default that is exactly what happens.
Anyway, it is an easy quick test.
Dave
Jim Bassett wrote:
That makes sense. I can't find anything though. Here's a couple
more points as a last try to see if anyone can think of anything:
I was wrong about the outgoing mail being delivered immediately
even though the client would hang. The mails are not delivered
until the client finally shows a completed send - usually around 3
minutes per email (client show quick progress right up to
completion, but then hangs at the very end.)
If I telnet to port 25, do an auth login, and send mail from the
command line the same thing happens. The smtp server is completely
responsive up through where I say 'DATA' and type in the body of
the message. But then when I type /n/r./n/r to end the DATA
absolutely nothing happens for several minutes until it finally
replies with '250 ok'. (Is there any way to make the smtp server
more verbose here?)
This same delay happens from multiple clients, multiple locations,
multiple email accounts. It happens whether the recipient is on
the same domain (same server) or on a remote server. But webmail
can send without delay in any situation.
Reverse DNS and resolving DNS are correct and trouble free.
That webmail can send but remote clients cannot seems like the
key. What is different in the sending process between these two?
Are there checks / scans that are done for remote clients that
wouldn't be done for someone logged into webmail?
Thank you very much for any ideas!
On Jul 20, 2009, at 1:28 PM, Eric Shubert wrote:
If nothing has changed on the server and nothing changed on the
clients, maybe something changed between them. Routing issue
perhaps near the server end? Just a swag.
Jim Bassett wrote:
Thanks for the reply. All different client software (Apple Mail
and Microsoft Outlook mostly) from different locations. Port
465. No spamdyke. This just started happening today after
working fine for years. Nothing was changed on the server
recentlyt although I did have a mystery few minutes yesterday
where load averages spiked to around 100 for no reason I could
track down (MySQL was at least part of the issue.)
On Jul 20, 2009, at 12:12 PM, Eric Shubert wrote:
Jim Bassett wrote:
Hi. I'm having a problem sending mail. Sending out through
Squirrelmail works fine. Sending out through a remote client
takes a very long time (~ 1 minute.) But the mail is actually
sent very fast - for example, if I send out through an account
on my server running qmailtoaster to my gmail account I can
see the email arrive in Gmail account almost immediately, but
my local email client still appears to be sending, having
become stuck with the progress bar showing 99% complete. So it
seems like qmail is just not disconnecting from the client
even though the mail has actually been sent.
There is nothing in my queue. Load average on the server is
reasonable. DNS checks out fine. Resolving nameserver is
working fast. This happens from multiple accounts on multiple
different hosted domains on my server.
Any thoughts on what to check? Thank you!
Which client software?
Which port? (smtp/submission)
Using spamdyke?
Does this happen with different client software? Connecting
from different locations?
--
-Eric 'shubes'
--
-Eric 'shubes'
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com
)
Vickers Consulting Group offers Qmailtoaster support and
installations.
If you need professional help with your setup, contact them
today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com
)
Vickers Consulting Group offers Qmailtoaster support and
installations.
If you need professional help with your setup, contact them
today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
--
-Eric 'shubes'
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com
)
Vickers Consulting Group offers Qmailtoaster support and
installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
