Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Question on "Mail Queue" and "sending"
5 views
Skip to first unread message
Steve
Apr 27, 2012, 3:48:08 AM4/27/12
to
Hi,
As you know, when you send an email, the email is in the queue, then the
status become.. "sending"
We are using our SMTP email server from our Internet provider.
We have sometimes ( rarely ) all our emails blocked into the queue. (
"Deferred with.. smtp.example.com"
It sounds that this is not the email server from our internet provider, but
ONE mail seems to block everything.. but the problem is : which one ????
* Restarting the server doesn't help
* Even the reception is blocked ( I can see with my fresh email Backup that
news email are in the backup server..
If I delete everything and restart Sendmail everything is back OK !
but this solution is a bit extrem....
- Is there a way to tell the server, that if you have a problem with ONE
email... leave it in the queue and send the others ?
Thanks
As you know, when you send an email, the email is in the queue, then the
status become.. "sending"
We are using our SMTP email server from our Internet provider.
We have sometimes ( rarely ) all our emails blocked into the queue. (
"Deferred with.. smtp.example.com"
It sounds that this is not the email server from our internet provider, but
ONE mail seems to block everything.. but the problem is : which one ????
* Restarting the server doesn't help
* Even the reception is blocked ( I can see with my fresh email Backup that
news email are in the backup server..
If I delete everything and restart Sendmail everything is back OK !
but this solution is a bit extrem....
- Is there a way to tell the server, that if you have a problem with ONE
email... leave it in the queue and send the others ?
Thanks
Joe Zeff
Apr 27, 2012, 11:55:06 AM4/27/12
to
On Fri, 27 Apr 2012 09:48:08 +0200, Steve wrote:
> As you know, when you send an email, the email is in the queue, then the
> status become.. "sending"
> We are using our SMTP email server from our Internet provider.
Something doesn't sound right here. If, as you say, you're using your
> As you know, when you send an email, the email is in the queue, then the
> status become.. "sending"
> We are using our SMTP email server from our Internet provider.
ISP's server, all that should happen at your end is that you send an
email and out it goes. What happens to it once it hits the server is not
only completely out of your control, you're not even notified unless
there's a long delay -- generally speaking, you're not told about delays
lasting under 24 hours or so. And, customers certainly aren't able to
restart the server or empty the queue as you say you've tried. Please
give us more details, including an explanation of how you're restarting
your ISP's SMTP server.
--
Joe Zeff -- The Guy With The Sideburns:
http://www.zeff.us http://www.lasfs.info
Another clue like that and I may have to start thinking.
Steve
Apr 30, 2012, 2:23:06 AM4/30/12
to
Joe Zeff wrote:
> On Fri, 27 Apr 2012 09:48:08 +0200, Steve wrote:
>
>> As you know, when you send an email, the email is in the queue, then the
>> status become.. "sending"
>> We are using our SMTP email server from our Internet provider.
>
> Something doesn't sound right here. If, as you say, you're using your
> ISP's server, all that should happen at your end is that you send an
> email and out it goes. What happens to it once it hits the server is not
> only completely out of your control, you're not even notified unless
> there's a long delay -- generally speaking, you're not told about delays
> lasting under 24 hours or so. And, customers certainly aren't able to
> restart the server or empty the queue as you say you've tried. Please
> give us more details, including an explanation of how you're restarting
> your ISP's SMTP server.
>
Hi Joe,
> On Fri, 27 Apr 2012 09:48:08 +0200, Steve wrote:
>
>> As you know, when you send an email, the email is in the queue, then the
>> status become.. "sending"
>> We are using our SMTP email server from our Internet provider.
>
> Something doesn't sound right here. If, as you say, you're using your
> ISP's server, all that should happen at your end is that you send an
> email and out it goes. What happens to it once it hits the server is not
> only completely out of your control, you're not even notified unless
> there's a long delay -- generally speaking, you're not told about delays
> lasting under 24 hours or so. And, customers certainly aren't able to
> restart the server or empty the queue as you say you've tried. Please
> give us more details, including an explanation of how you're restarting
> your ISP's SMTP server.
>
No, we didn't reboot our internet provider's email server.
When we are sending emails, our email server is sending TO our ISP email
server. [ define(`SMART_HOST', `smtp.example.fr')dnl ]
When I had the problem, sending emails... OUR server couldn't send
anything... I can't remember what was the exact message, but it sounded
coming from our ISP. BUT.. AFter deleting OUR Queue... news emails coming
into queue could be sent.
I have the feeling that this is not our ISP email server problem, but our
email server, which had some problems with ONE email..
What I would like to do is : If sendmail doesn't like or cannot send one
email, just ignore it and send the others....
Joe Zeff
Apr 30, 2012, 2:35:49 AM4/30/12
to
On Mon, 30 Apr 2012 08:23:06 +0200, Steve wrote:
> When I had the problem, sending emails... OUR server couldn't send
> anything... I can't remember what was the exact message, but it sounded
> coming from our ISP. BUT.. AFter deleting OUR Queue... news emails
> coming into queue could be sent.
> I have the feeling that this is not our ISP email server problem, but
> our email server, which had some problems with ONE email..
Thank you; that makes a lot more sense.
> When I had the problem, sending emails... OUR server couldn't send
> anything... I can't remember what was the exact message, but it sounded
> coming from our ISP. BUT.. AFter deleting OUR Queue... news emails
> coming into queue could be sent.
> I have the feeling that this is not our ISP email server problem, but
> our email server, which had some problems with ONE email..
*Sigh* It's almost as if they interpret the Bible as Microsoft does
RFCs.
Robert Bonomi
May 2, 2012, 5:54:00 AM5/2/12
to
In article <4f9e2fcb$0$21950$426a...@news.free.fr>,
Probably correct.
>What I would like to do is : If sendmail doesn't like or cannot send one
>email, just ignore it and send the others....
Sendmail generally *does* do that.
When there is a problem with a particular -message- that message is
held in the queue, and other messages are processed,
When there is a problem with a particular remote _server_ all traffic
to that server is held.
If a particular _message_ cause the remote server to 'fail', as distinct
from just giving a 'deferred'/'rejection' message, this can cause the
local mailer to conclude there is a server problem, and not send any
more traffic to _that_ server for a 'while'. Unfortunately, the 'problem'
message remains at the -head- of the queue, thus when the 'wait' interval
expires, it tries to send =that= message first. IF the same 'failure'
happens, the entire queue is pended again.
The *exact* content of the error message is _critical_ in starting to
figure out what is going on.
The next time this happens, *SAVE* the error message, and move _that_
message (the 'd*' and corresponding 'q*' file) to a 'quarantine' area.
_With_ the exact error message, someone may be able to shed some light on
what's happening.
>What I would like to do is : If sendmail doesn't like or cannot send one
>email, just ignore it and send the others....
When there is a problem with a particular -message- that message is
held in the queue, and other messages are processed,
When there is a problem with a particular remote _server_ all traffic
to that server is held.
If a particular _message_ cause the remote server to 'fail', as distinct
from just giving a 'deferred'/'rejection' message, this can cause the
local mailer to conclude there is a server problem, and not send any
more traffic to _that_ server for a 'while'. Unfortunately, the 'problem'
message remains at the -head- of the queue, thus when the 'wait' interval
expires, it tries to send =that= message first. IF the same 'failure'
happens, the entire queue is pended again.
The *exact* content of the error message is _critical_ in starting to
figure out what is going on.
The next time this happens, *SAVE* the error message, and move _that_
message (the 'd*' and corresponding 'q*' file) to a 'quarantine' area.
_With_ the exact error message, someone may be able to shed some light on
what's happening.
0 new messages