headers
Michael Di Martino | 1 Nov 2009 14:29

Delayed delivery

My qmail server processes all the inbound and outbound mail for my RT  
Trouble Ticket Server. The issue is when RT processes requests it will  
send approx 10 to 15 individual emails to one domain. About half of  
those emails will be delivered imeadiatly the rest will be delivered  
over th next 15 minutes.

What causes this behavior and what can be done correct it? I am  
apparrently am at a complete loss.

Btw. I know the use of dist lists would solve this issue but at  
present this not possible.

Michael Di Matino
Open Access, Inc.
Permalink | Reply | 10 comments |
headers
Markus Stumpf | 1 Nov 2009 15:29
Picon
Favicon

Re: Delayed delivery

On Sun, Nov 01, 2009 at 07:29:11AM -0600, Michael Di Martino wrote:
> What causes this behavior and what can be done correct it? I am  
> apparrently am at a complete loss.

As I already wriote the last time you asked here:
    What does the qmail-send logfile say?

I'd bet you can see the reason in there.
Check it. If you don't understand, it post some relevant lines here.

	\Maex
Permalink | Reply | 9 comments |
headers
Michael Di Martino | 1 Nov 2009 15:50

RE: Delayed delivery


-----Original Message-----
From: Markus Stumpf [mailto:lists-qmail <at> maexotic.de] 
Sent: Sunday, November 01, 2009 9:29 AM
To: Michael Di Martino
Cc: qmail List
Subject: Re: Delayed delivery

On Sun, Nov 01, 2009 at 07:29:11AM -0600, Michael Di Martino wrote:
> What causes this behavior and what can be done correct it? I am  
> apparrently am at a complete loss.
__________________________________________________________________________

>>> As I already wriote the last time you asked here:
 >>   What does the qmail-send logfile say?

>> I'd bet you can see the reason in there.
>>Check it. If you don't understand, it post some relevant lines here.

>>>	\Maex
__________________________________________________________________________________

Output of /var/log/qmail/current 
As u will see 6 emails were delivered,  howeer after running qmailctl queue you can see 6 still need to be delivered.

 <at> kirk ~]$ sudo su -l
Password:
[root <at> kirk ~]# tail -f /var/log/qmail/current 
 <at> 400000004aed9e7f1230e9ec delivery 7926: success: 209.85.221.23_accepted_message./Remote_host_said:_250_2.0.0_OK_1257086581_31si6336125qyk.19/
 <at> 400000004aed9e7f1230f5a4 status: local 0/10 remote 5/80
(Continue reading)

Permalink | Reply | 8 comments |
headers
Michael Di Martino | 1 Nov 2009 16:16

RE: Delayed delivery


-----Original Message-----
From: Michael Di Martino [mailto:mdm <at> openaccessinc.com]
Sent: Sunday, November 01, 2009 9:51 AM
To: qmail List
Cc: Markus Stumpf
Subject: RE: Delayed delivery

-----Original Message-----
From: Markus Stumpf [mailto:lists-qmail <at> maexotic.de]
Sent: Sunday, November 01, 2009 9:29 AM
To: Michael Di Martino
Cc: qmail List
Subject: Re: Delayed delivery

On Sun, Nov 01, 2009 at 07:29:11AM -0600, Michael Di Martino wrote:
> What causes this behavior and what can be done correct it? I am
> apparrently am at a complete loss.
__________________________________________________________________________

>>> As I already wriote the last time you asked here:
 >>   What does the qmail-send logfile say?

>> I'd bet you can see the reason in there.
>>Check it. If you don't understand, it post some relevant lines here.

>>>     \Maex
__________________________________________________________________________________

Output of /var/log/qmail/current
(Continue reading)

Permalink | Reply | 7 comments |
headers
Kyle Wheeler | 1 Nov 2009 16:38

Re: Delayed delivery


On Sunday, November  1 at 09:16 AM, quoth Michael Di Martino:
>2009-11-01 09:43:00.665771500 delivery 7915: deferral: 
>Connected_to_98.129.185.3_but_greeting_failed./Remote_host_said:_421_4.7.0_gate2.gate.dfw.mlsrvr.com_Error:_too_many_connections_from_66.206.114.119/

There's your answer right there. Your recipient refused to accept that 
many connections from you (which is an unfortunately common, and 
misguided, anti-spam technique). Thus, some of the messages could not 
be delivered right away. Qmail waited, tried again later, and they got 
through on the second try.

To fix this, you either need to involve serialmail (a somewhat 
involved process where you deliver all messages for this domain to a 
local Maildir and then use serialmail to push all those messages out 
through a single connection), OR convince the recipient domain of the 
idiocy of its connection limitation policy.

~Kyle
--

-- 
Strong coffee, much strong coffee, is what awakens me. Coffee gives me 
warmth, waking, an unusual force and a pain that is not without very 
great pleasure.
                                                  -- Napoleon Bonaparte
Permalink | Reply | 1 comment |
headers
Markus Stumpf | 1 Nov 2009 17:11
Picon
Favicon

Re: Delayed delivery

On Sun, Nov 01, 2009 at 09:16:13AM -0600, Michael Di Martino wrote:
> 2009-11-01 09:43:00.502571500 starting delivery 7926: msg 6815748 to remote cgucker <at> openaccessinc.net
> 2009-11-01 09:43:00.502572500 status: local 0/10 remote 17/80
> 2009-11-01 09:43:00.665771500 delivery 7915: deferral: Connected_to_98.129.185.3_but_greeting_failed./Remote_host_said:_421_4.7.0_gate2.gate.dfw.mlsrvr.com_Error:_too_many_connections_from_66.206.114.119/

Ah, here it is!
You are allowing you qmail server to open 80 parallel outgoing
connections. The server at 98.129.185.3 however has a limit on
the number of parallel incoming connections from the same IP address.
(spam protection probably).

You have 2 (easy) possibilities:
1) If you qmail server is not running with heavy load, reduce the number
   of parallel outgoing connections to 10. This should be fine for the
   receiving server. (see control/concurrencyremote file)
2) If you have control of the receiving server you could check whether
   you can increase the number of parallel incoming connection for one
   IP address *only* (for 66.206.114.119) to maybe 20 or 30.

If both of the above solutions are unacceptable more work is needed.

1) on qmail.org there is a patch:
   Joshua Megerman wrote a patch to implement hashed per-IP connection
   limiting in qmail-send and qmail-remote.
     http://www.coyotetechnical.com/software/patches/qmail-send-concurrencyperip.patch
   It introduces a new control file "concurrencyperip".
   I have never used that patch but it looks like it should solve
   your problem by setting concurrencyperip to "10"

2) You could add a virtual domain for openaccessinc.net to the TTS server,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Di Martino | 1 Nov 2009 18:40

Re: Delayed delivery


On Nov 1, 2009, at 11:05 AM, "Kyle Wheeler" <kyle- 
qmail <at> memoryhole.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sunday, November  1 at 09:16 AM, quoth Michael Di Martino:
>> 2009-11-01 09:43:00.665771500 delivery 7915: deferral:
>> Connected_to_98.129.185.3_but_greeting_failed./ 
>> Remote_host_said: 
>> _421_4.7.0_gate2. 
>> gate.dfw.mlsrvr.com_Error:_too_many_connections_from_66.206.114.119/
>
> There's your answer right there. Your recipient refused to accept that
> many connections from you (which is an unfortunately common, and
> misguided, anti-spam technique). Thus, some of the messages could not
> be delivered right away. Qmail waited, tried again later, and they got
> through on the second try.
>
> To fix this, you either need to involve serialmail (a somewhat
> involved process where you deliver all messages for this domain to a
> local Maildir and then use serialmail to push all those messages out
> through a single connection), OR convince the recipient domain of the
> idiocy of its connection limitation policy.
>
> ~Kyle
> - --
> Strong coffee, much strong coffee, is what awakens me. Coffee gives me
> warmth, waking, an unusual force and a pain that is not without very
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Di Martino | 1 Nov 2009 18:06

RE: Delayed delivery


Michael DiMartino | Director of IT | Open Access, Inc.
115 Bi County Blvd | Farmingdale, NY 11735     
631.227.1034| 631.694.6730 FAX |631.988.6060 MOBILE
www.openaccessinc.com

-----Original Message-----
From: Markus Stumpf [mailto:lists-qmail <at> maexotic.de] 
Sent: Sunday, November 01, 2009 10:49 AM
To: Michael Di Martino
Cc: qmail List
Subject: Re: Delayed delivery

On Sun, Nov 01, 2009 at 08:50:42AM -0600, Michael Di Martino wrote:
> Output of /var/log/qmail/current 
> As u will see 6 emails were delivered,  howeer after running qmailctl queue you can see 6 still need to be delivered.

Yes. And the inetresting ones are the ones that did NOT get delivered.
Could you do a
   fgrep deferral /var/log/qmail/current | fgrep roswald <at> openaccessinc.com
and send the output?
Or if this is empty do a
   fgrep deferral /var/log/qmail/* | fgrep roswald <at> openaccessinc.com

Another question: how does your setup look like?
1) You have one machine that hosts the Trouble Ticket System. This machine
   runs qmail and sends the mail. The qmail-send logfile was from that
   machine.
2) This machine sends the messages to another machine. This is running
   another mailserver (not qmail).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fred McIntyre | 1 Nov 2009 23:39

554 deferral or failure?

Hi,
In my logs, for outgoing mail, I have a lot of lines where the receiving server responded with 554, yet it is
logged as
a deferral rather than a failure. I'm seeing this for 571 also. I thought that all smtp codes >=500 were
supposed to be
permanant failures.

I'm running netqmail-1.06 with the following patches:
http://pyropus.ca/software/misc/qmail-1.03-domainbindings-1.2.patch
qmail-smtpd-viruscan-1.3.patch
big-concurrency.patch
big-ext-todo-20030101.patch
doublebounce-trim.patch

In qmail-remote.c (line 227 among other places) I see:
if (code >= 500) quit("DConnected to "," but sender was rejected");

and in qmail-send.c
         case 'D':
           log3("delivery ",strnum3,": failure: ");

which indicate to me that it should be a failure rather than deferral.

Any suggestions?

Thanks,
Fred Mc
Permalink | Reply | 6 comments |
headers
Adi Pircalabu | 2 Nov 2009 00:29
Picon

Re: 554 deferral or failure?

On Sun, 1 Nov 2009 14:39:02 -0800 Fred McIntyre wrote:

> In my logs, for outgoing mail, I have a lot of lines where the
> receiving server responded with 554, yet it is logged as a deferral
> rather than a failure. I'm seeing this for 571 also. I thought that
> all smtp codes >=500 were supposed to be permanant failures.
[...]
> In qmail-remote.c (line 227 among other places) I see:
> if (code >= 500) quit("DConnected to "," but sender was rejected");
> 
> and in qmail-send.c
>          case 'D':
>            log3("delivery ",strnum3,": failure: ");
> 
> which indicate to me that it should be a failure rather than deferral.

http://www.faqs.org/rfcs/rfc821.html
For SMTP, a failure is a failure, regardless of whether it's permanent
(5xx) or temporary (4xx) one.
It's also common sense to use "failure" for every type of event which
did not finished successfully. Failure to understand this is still a
failure :)

--

-- 
Adi Pircalabu
Permalink | Reply | 1 comment |

Gmane