Re: Slow sending of email

[li...@rhsoft.net]

correct, the empty-zone data below is because in need these
"disable-empty-zone" lines and have several in both which
are maintained on the forwarder on the other end(s) of
vpn-routings, maybe it's even posible to list them
explicit in "disable-empty-zone", not tried yet

normally "empty-zones-enable" is enabled on recent namservers

empty-zones-enable yes;
disable-empty-zone "10.in-addr.arpa";
disable-empty-zone "168.192.in-addr.arpa"

Am 17.02.2014 06:58, schrieb Noel Butler:
> or, in bind options :   empty-zones-enable yes;
> 
> any server running bind not understanding this should result is two things
> 
> 1: the responsible admins resignation
> 
> 2: ensuring his/her replacement upgrades to something modern
>  
> 
> On 16/02/2014 07:43, li...@rhsoft.net wrote:
> 
>> Am 15.02.2014 22:37, schrieb SW:
>>> Yes, you are correct. That is the cause of the problem. A quick entry of my 
>>> machine in the hosts file sorted
>>> that one out! I'm just baffled why I have never experienced this issue 
>>> before
> ___
> 
> zone "1.10.IN-ADDR.ARPA" {
>  typemaster;
>  file"named.empty";
> };
> 
> zone "2.10.IN-ADDR.ARPA" {
>  typemaster;
>  file"named.empty";
> };
> 
> zone "3.10.IN-ADDR.ARPA" {
>  typemaster;
>  file"named.empty";
> };

Mail delivery problem.. intermittent .. I dont see what could be wrong...

[Vaughan, Jesse]

I have been having problems with mail not being delivered and I don't know 
why...  In this particular instance an email from 
cschofi...@cox.net wasn't delivered.. anyone know 
why?

I'm running centos 6 with virtual users using the config from howtoforge.  I'm 
also using maildrop for my maildelivery.

I had smtpd -v turned on in the log..the log is here:

http://www.restonlinux.com/maillog.txt

I don't see anywhere where it says the message is being dropped and if anyone 
can shed light on the issue I would GREATLY appreciate it..

The other thing I'll mention is the problem is intermittent.. in otherwords.. I 
got mail before and after it.. just not this particular piece of mail (and 
probably others that I don't know about!! This is just the one that was obvious)



I also looked in my /var/log/messages  and these are the only things that are 
about the same time.


...
...
Feb 17 14:36:10 mail clamd[1553]: lstat() failed on: 
/var/spool/amavisd/tmp/amavis-20140217T142839-14053/parts
Feb 17 14:36:18 mail postfix/smtpd[14307]: sql_select option missing
Feb 17 14:36:18 mail postfix/smtpd[14307]: auxpropfunc error no mechanism 
available
...
...
Feb 17 14:37:57 mail postfix/smtpd[14361]: sql_select option missing
Feb 17 14:37:57 mail postfix/smtpd[14361]: auxpropfunc error no mechanism 
available
Feb 17 14:38:03 mail postfix/smtpd[14366]: sql_select option missing
Feb 17 14:38:03 mail postfix/smtpd[14366]: auxpropfunc error no mechanism 
available
Feb 17 14:38:08 mail clamd[1553]: lstat() failed on: 
/var/spool/amavisd/tmp/amavis-20140217T143507-14254/parts
Feb 17 14:38:08 mail clamd[1553]: lstat() failed on: 
/var/spool/amavisd/tmp/amavis-20140217T142839-14053/parts
...


Thanks again if you have any ideas.

Jesse Vaughan

Re: Mail delivery problem.. intermittent .. I dont see what could be wrong...

[Viktor Dukhovni]

On Tue, Feb 18, 2014 at 02:52:12AM +, Vaughan, Jesse wrote:

> I have been having problems with mail not being delivered and I
> don't know why...  In this particular instance an email from
> cschofi...@cox.net wasn't delivered..  anyone know why?

Please carefully requests for help for material errors, the actual
address appears to be different: cschofie...@cox.net

> I had smtpd -v turned on in the log..the log is here:

Do NOT turn "-v" unless asked to by someone who can justify why it
is needed, this just makes it much harder to see the relevant data.

> http://www.restonlinux.com/maillog.txt

This boils down to two deliveries via amavis to your maildrop LDA
both successful.  Both carry the same message-id, and have the same
size, they look like duplicates, and may have been consolidated by
Courier IMAP.

EF2F17788B2: message-id=<53026510.7080...@cox.net>
F420B7788B3: message-id=<53026510.7080...@cox.net>

Everything looks normal, except perhaps the high delay in the
incoming queue both before and after the amavis filter.  

For the pre-filter delay: you seem to be using an RBL that is not
responsive, and may cause clients to disconnect due to high delays:

Feb 17 14:37:57 mail postfix/smtpd[14259]: generic_checks:
name=reject_rbl_client
Feb 17 14:37:57 mail postfix/smtpd[14259]: reject_rbl:
Client host 68.230.241.216
Feb 17 14:38:07 mail postfix/smtpd[14259]: dns_query:
216.241.230.68.opm.blitzed.org (A): Host not found, try again
Feb 17 14:38:07 mail postfix/smtpd[14259]: warning:
216.241.230.68.opm.blitzed.org: RBL lookup error:
Host or domain name not found.
Name service error for name=216.241.230.68.opm.blitzed.org type=A:
Host not found, try again

Paying attention to such warnings may be wise.

For the after queue delay: slow amavis RBL lookups enabled?

Feb 17 14:38:23 mail amavis[14254]: (14254-03) Passed CLEAN,
[68.230.241.216] [98.169.62.249]
 -> ,
Message-ID: <53026510.7080...@cox.net>,
mail_id: 4046SmN5F+37, Hits: -2.453,
size: 189387, queued_as: 532797788B4,
15035 ms

The post-filter smtp server logs no delay in enqueueing the message,
so the 15 seconds delay is entirely in amavisd.

Feb 17 14:38:23 mail postfix/smtpd[14127]: connect from unknown[127.0.0.1]
Feb 17 14:38:23 mail postfix/smtpd[14127]: 532797788B4: 
client=unknown[127.0.0.1]
Feb 17 14:38:23 mail postfix/smtpd[14127]: disconnect from 
unknown[127.0.0.1]

The transaction logs are below:

Feb 17 14:38:07 mail postfix/smtpd[14259]: EF2F17788B2: 
client=eastrmfepo201.cox.net[68.230.241.216]
Feb 17 14:38:08 mail postfix/cleanup[14222]: EF2F17788B2: 
message-id=<53026510.7080...@cox.net>
Feb 17 14:38:08 mail postfix/qmgr[19042]: EF2F17788B2: 
from=, size=189387, nrcpt=1 (queue active)
Feb 17 14:38:23 mail postfix/smtp[14371]: EF2F17788B2: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=26, 
delays=11/0.02/0/15, dsn=2.0.0, status=sent (250 2.0.0 from 
MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 532797788B4)
Feb 17 14:38:23 mail postfix/qmgr[19042]: EF2F17788B2: removed

Feb 17 14:38:23 mail postfix/smtpd[14127]: 532797788B4: 
client=unknown[127.0.0.1]
Feb 17 14:38:23 mail postfix/cleanup[14222]: 532797788B4: 
message-id=<53026510.7080...@cox.net>
Feb 17 14:38:23 mail postfix/qmgr[19042]: 532797788B4: 
from=, size=189826, nrcpt=1 (queue active)
Feb 17 14:38:23 mail postfix/pipe[14248]: 532797788B4: 
to=, orig_to=, relay=maildrop, 
delay=0.07, delays=0.02/0/0/0.04, dsn=2.0.0, status=sent (delivered via 
maildrop service)
Feb 17 14:38:23 mail postfix/qmgr[19042]: 532797788B4: removed

Feb 17 14:38:08 mail postfix/smtpd[14361]: F420B7788B3: 
client=eastrmfepo201.cox.net[68.230.241.216]
Feb 17 14:38:08 mail postfix/cleanup[14370]: F420B7788B3: 
message-id=<53026510.7080...@cox.net>
Feb 17 14:38:08 mail postfix/qmgr[19042]: F420B7788B3: 
from=, size=189387, nrcpt=1 (queue active)
Feb 17 14:38:23 mail postfix/smtp[14229]: F420B7788B3: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=26, 
delays=11/0/0.01/15, dsn=2.0.0, status=sent (250 2.0.0 from 
MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 5F2A17788B5)
Feb 17 14:38:23 mail postfix/qmgr[19042]: F420B7788B3: removed

Feb 17 14:38:23 mail postfix/smtpd[14127]: 532797788B4: 
client=unknown[127.0.0.1]
Feb 17 14:38:23 mail postfix/smtpd[14127]: 5F2A17788B5: 
client=unknown[127.0.0.1]
Feb 17 14:38:23 mail postfix/cleanup[14370]: 5F2A17788B5: 
message-id=<53026510.7080...@cox.net>
Feb 17 14:38:23 mail postfix/qmgr[19042]: 5F2A17788B5: 
from=, size=189826, nrcpt=1 (queue active)
Feb 17 14:38:23 mail postfix/pipe[14248]: 5F2A17788B5: 
to=, relay=maildrop, delay=0.05, delays=0.02/0/0/0.02, 
dsn=2.0.0, status=sent (delivered via maildrop service)
Feb 17 14:38:23 mail postfix/qmgr[19042]: 5F2A17788B5: removed

-- 
Viktor.

Re: Mail delivery problem.. intermittent .. I dont see what could be wrong...

[Viktor Dukhovni]

On Tue, Feb 18, 2014 at 03:36:09AM +, Viktor Dukhovni wrote:

> For the pre-filter delay: you seem to be using an RBL that is not
> responsive, and may cause clients to disconnect due to high delays:
> 
> Feb 17 14:37:57 mail postfix/smtpd[14259]: generic_checks:
>   name=reject_rbl_client
> Feb 17 14:37:57 mail postfix/smtpd[14259]: reject_rbl:
>   Client host 68.230.241.216
> Feb 17 14:38:07 mail postfix/smtpd[14259]: dns_query:
>   216.241.230.68.opm.blitzed.org (A): Host not found, try again
> Feb 17 14:38:07 mail postfix/smtpd[14259]: warning:
>   216.241.230.68.opm.blitzed.org: RBL lookup error:
>   Host or domain name not found.
>   Name service error for name=216.241.230.68.opm.blitzed.org type=A:
>   Host not found, try again
> 
> Paying attention to such warnings may be wise.

As well as not blindly including random RBLs from some stale HOWTO.
This particular RBL seems to have been dead for 7 years now.

http://www.dnsbl.com/2007/02/status-of-opmblitzedorg-dead.html

The OP would be wise to keep the set of RBLs used to a short list
of just the most effective ones.  The marginal value of additional
RBLs is low, and the latency cost of using too many is high.
Periodically audit your RBL list to make sure none are dead.

The mail server performance will be much better without dead RBLs.

-- 
Viktor.