Milter-greylist

Hello,

I have the following sendmail milter log

Mar 15 10:42:10 mx sendmail[23146]: NOQUEUE: Milter (greylist): to error state
Mar 15 10:47:10 mx sendmail[26653]: NOQUEUE: Milter (greylist): to error state
Mar 15 10:52:10 mx sendmail[29865]: NOQUEUE: Milter (greylist): to error state
Mar 15 10:57:10 mx sendmail[32580]: NOQUEUE: Milter (greylist): to error state
Mar 15 11:02:10 mx sendmail[3565]: NOQUEUE: Milter (greylist): to error state
Mar 15 11:07:10 mx sendmail[7228]: NOQUEUE: Milter (greylist): to error state

The interval between each line logged is exactly 5m

I've found nothing related but sendmail timeout which default to 5m
 
O ConnectionCacheTimeout=5m
#O Timeout.initial=5m
#O Timeout.connect=5m
#O Timeout.iconnect=5m
#O Timeout.helo=5m
#O Timeout.datainit=5m
#O Timeout.rset=5m

Are theses value related with NOQUEUE messages ?


-- 
Christian P�lissier
\ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
\ue201 34419

Christian Pélissier Christian.Pelissier@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> I've found nothing related but sendmail timeout which default to 5m
>  
> O ConnectionCacheTimeout=5m
> #O Timeout.initial=5m
> #O Timeout.connect=5m
> #O Timeout.iconnect=5m
> #O Timeout.helo=5m
> #O Timeout.datainit=5m
> #O Timeout.rset=5m
> 
> Are theses value related with NOQUEUE messages ?

What happens if you set it to 6m?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Le jeudi 15 mars 2018 � 20:44 +0100, manu@... [milter-greylist] a
�crit :
>   
> Christian P�lissier Christian.Pelissier@... [milter-greylist]
> <milter-greylist@yahoogroups.com> wrote:
> 
> > I've found nothing related but sendmail timeout which default to 5m
> > 
> > O ConnectionCacheTimeout=5m
> > #O Timeout.initial=5m
> > #O Timeout.connect=5m
> > #O Timeout.iconnect=5m
> > #O Timeout.helo=5m
> > #O Timeout.datainit=5m
> > #O Timeout.rset=5m
> > 
> > Are theses value related with NOQUEUE messages ?
> 
> What happens if you set it to 6m?
No changes period remain 5m.

> -- 
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu@...
> 
> 
> 
> 

-- 
Christian P�lissier
\ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
\ue201 34419

Based on the error message I think the problem stems from an error in 
the milter. Do you see anything in the milter logs?

Also see this old thread about time outs defaulting to 10 seconds for 
milter connections.

http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827

Best

John


---
Denne e-mail blev kontrolleret for virusser af Avast antivirussoftware.
https://www.avast.com/antivirus

Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
john@... [milter-greylist] a �crit :
> http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827

I have no 10s timeout. I've changed C:5m to c:6m. Logging period is
always 5mn.

Mimedefang log the same thing at the same time but opendkim, opendmarc
clamav do not log NOQUEUE message.

Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (greylist): to error state
Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (mimedefang): to error state

Opendkim and Opendmarc have default flags

-- 
Christian P�lissier
\ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
\ue201 34419

So both greylist and mimedefang fails. Do you see anything in the logs? 
Are they failing on the same email maessage?

How are they defined in the .cf/.mc file?

/john


Den 16-03-2018 kl. 12:32 skrev Christian P�lissier 
Christian.Pelissier@... [milter-greylist]:
>
> Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
> john@... [milter-greylist] a �crit :
> > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
>
> I have no 10s timeout. I've changed C:5m to c:6m. Logging period is
> always 5mn.
>
> Mimedefang log the same thing at the same time but opendkim, opendmarc
> clamav do not log NOQUEUE message.
>
> Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (greylist): to 
> error state
> Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (mimedefang): to 
> error state
>
> Opendkim and Opendmarc have default flags
>
> -- 
> Christian P�lissier
> \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> \ue201 34419
>
> 



---
Denne e-mail blev kontrolleret for virusser af Avast antivirussoftware.
https://www.avast.com/antivirus

Le vendredi 16 mars 2018 � 12:40 +0100, John Damm S�rensen
john@... [milter-greylist] a �crit :
>   
> So both greylist and mimedefang fails. Do you see anything in the
> logs? Are they failing on the same email maessage?

Both have always the same sendmail PID  17925 in the example
> How are they defined in the .cf/.mc file?

Well ... I hope

INPUT_MAIL_FILTER(`greylist', `S=local:/var/milter-greylist/milter-greylist.sock, T=C=6m;S:10m;R:10m;E:10m')dnl
INPUT_MAIL_FILTER(`mimedefang', `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:360s;R:360s;E:15m')

INPUT_MAIL_FILTER(`opendkim', `S=inet:4445@127.0.0.1')dnl

I can try to use an inet socket, but I have other milter with local
socket and they do not log NOQUEUE messages.

Milter API evolved with time. Could we have both in mimedefang and
milter-greylist and old style milter callback indirectly related with
theses log lines ??

Another cause (the stange period of 5mn) could be a nagios monitoring
occuring regularly but in that case why only 2 milters are affected ?

I found inside sendmail source and KNOWBUGS file a bug related to
NOQUEUE: but not related with milter 

=====
* accept() problem on Linux.

  The accept() in sendmail daemon loop can return ETIMEDOUT.  An
  error is reported to syslog:

  Jun  9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
                        getrequests: accept: Connection timed out

  "Connection timed out" is not documented as a valid return from
  accept(2) and this was believed to be a bug in the Linux kernel.
  Later information from the Linux kernel group states that Linux
  2.0 kernels follow RFC1122 while sendmail follows the original BSD
  (now POSIX 1003.1g draft) specification.  The 2.1.X and later kernels
  will follow the POSIX draft.
=====

I have a 2.6.X kernel so both kernel and sendmail are POSIX ... and I
have no such message
> 
> /john
> 
> 
> 
> Den 16-03-2018 kl. 12:32 skrev Christian P�lissier
> Christian.Pelissier@... [milter-greylist]:
> 
> >   
> > Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
> > john@... [milter-greylist] a �crit :
> > > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
> > 
> > I have no 10s timeout. I've changed C:5m to c:6m. Logging period is
> > always 5mn.
> > 
> > Mimedefang log the same thing at the same time but opendkim,
> > opendmarc
> > clamav do not log NOQUEUE message.
> > 
> > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (greylist): to
> > error state
> > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (mimedefang): to
> > error state
> > 
> > Opendkim and Opendmarc have default flags
> > 
> > -- 
> > Christian P�lissier
> > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > \ue201 34419
> > 
> > 
> > 
> > 
> 
> 
> 
> Virusfri. www.avast.com 
> 
> 
> 

-- 
Christian P�lissier
\ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
\ue201 34419

The sendmail code issuing the error message is in the milter_error() 
function which has this comment:

 ��� ��� /*
 ������� **� We could send a quit here but we may have gotten here due to
 ������� **� an I/O error so we don't want to try to make things worse.
 ������� */
So it might be useful to check the messages file for error messages 
related to general system starvation ( memory, file system, /tmp , etc.)

When everything else fails try run strace -o <output file> -tfp <pid of 
milter-greylist> and check for errors.

Best

John

Den 16-03-2018 kl. 17:00 skrev Christian P�lissier 
Christian.Pelissier@... [milter-greylist]:
>
> Le vendredi 16 mars 2018 � 12:40 +0100, John Damm S�rensen
> john@... [milter-greylist] a �crit :
> >
> > So both greylist and mimedefang fails. Do you see anything in the
> > logs? Are they failing on the same email maessage?
>
> Both have always the same sendmail PID 17925 in the example
> > How are they defined in the .cf/.mc file?
>
> Well ... I hope
>
> INPUT_MAIL_FILTER(`greylist', 
> `S=local:/var/milter-greylist/milter-greylist.sock, 
> T=C=6m;S:10m;R:10m;E:10m')dnl
> INPUT_MAIL_FILTER(`mimedefang', 
> `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, 
> T=S:360s;R:360s;E:15m')
>
> INPUT_MAIL_FILTER(`opendkim', `S=inet:4445@127.0.0.1')dnl
>
> I can try to use an inet socket, but I have other milter with local
> socket and they do not log NOQUEUE messages.
>
> Milter API evolved with time. Could we have both in mimedefang and
> milter-greylist and old style milter callback indirectly related with
> theses log lines ??
>
> Another cause (the stange period of 5mn) could be a nagios monitoring
> occuring regularly but in that case why only 2 milters are affected ?
>
> I found inside sendmail source and KNOWBUGS file a bug related to
> NOQUEUE: but not related with milter
>
> =====
> * accept() problem on Linux.
>
> The accept() in sendmail daemon loop can return ETIMEDOUT. An
> error is reported to syslog:
>
> Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
> getrequests: accept: Connection timed out
>
> "Connection timed out" is not documented as a valid return from
> accept(2) and this was believed to be a bug in the Linux kernel.
> Later information from the Linux kernel group states that Linux
> 2.0 kernels follow RFC1122 while sendmail follows the original BSD
> (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels
> will follow the POSIX draft.
> =====
>
> I have a 2.6.X kernel so both kernel and sendmail are POSIX ... and I
> have no such message
> >
> > /john
> >
> >
> >
> > Den 16-03-2018 kl. 12:32 skrev Christian P�lissier
> > Christian.Pelissier@... [milter-greylist]:
> >
> > >
> > > Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
> > > john@... [milter-greylist] a �crit :
> > > > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
> > >
> > > I have no 10s timeout. I've changed C:5m to c:6m. Logging period is
> > > always 5mn.
> > >
> > > Mimedefang log the same thing at the same time but opendkim,
> > > opendmarc
> > > clamav do not log NOQUEUE message.
> > >
> > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (greylist): to
> > > error state
> > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (mimedefang): to
> > > error state
> > >
> > > Opendkim and Opendmarc have default flags
> > >
> > > --
> > > Christian P�lissier
> > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > \ue201 34419
> > >
> > >
> > >
> > >
> >
> >
> >
> > Virusfri. www.avast.com
> >
> >
> >
>
> -- 
> Christian P�lissier
> \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> \ue201 34419
>
> 



---
Denne e-mail blev kontrolleret for virusser af Avast antivirussoftware.
https://www.avast.com/antivirus

Reading the sendmail source code it appears that the NOQUEUE error 
should be accompanied by another� Milter error.
Look for these errors:
"Milter: no active filter"
"Milter: connect to filters"
"Milter: connect, ending"
"Milter: reject, no sender"
"Milter: sender: %s"
"Milter: reject, sender"
"Milter: reject, no rcpt"
"Milter: rcpts: %s"
"Milter: reject, data"
If none found please enable explicit milter logging. E.g. 
define(`confMILTER_LOG_LEVEL',`9')

/john
Den 16-03-2018 kl. 17:40 skrev John Damm S�rensen john@... 
[milter-greylist]:
>
> The sendmail code issuing the error message is in the milter_error() 
> function which has this comment:
>
> ��� ��� /*
> ������� **� We could send a quit here but we may have gotten here due to
> ������� **� an I/O error so we don't want to try to make things worse.
> ������� */
> So it might be useful to check the messages file for error messages 
> related to general system starvation ( memory, file system, /tmp , etc.)
>
> When everything else fails try run strace -o <output file> -tfp <pid 
> of milter-greylist> and check for errors.
>
> Best
>
> John
>
> Den 16-03-2018 kl. 17:00 skrev Christian P�lissier 
> Christian.Pelissier@... [milter-greylist]:
>>
>> Le vendredi 16 mars 2018 � 12:40 +0100, John Damm S�rensen
>> john@... [milter-greylist] a �crit :
>> >
>> > So both greylist and mimedefang fails. Do you see anything in the
>> > logs? Are they failing on the same email maessage?
>>
>> Both have always the same sendmail PID 17925 in the example
>> > How are they defined in the .cf/.mc file?
>>
>> Well ... I hope
>>
>> INPUT_MAIL_FILTER(`greylist', 
>> `S=local:/var/milter-greylist/milter-greylist.sock, 
>> T=C=6m;S:10m;R:10m;E:10m')dnl
>> INPUT_MAIL_FILTER(`mimedefang', 
>> `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, 
>> T=S:360s;R:360s;E:15m')
>>
>> INPUT_MAIL_FILTER(`opendkim', `S=inet:4445@127.0.0.1')dnl
>>
>> I can try to use an inet socket, but I have other milter with local
>> socket and they do not log NOQUEUE messages.
>>
>> Milter API evolved with time. Could we have both in mimedefang and
>> milter-greylist and old style milter callback indirectly related with
>> theses log lines ??
>>
>> Another cause (the stange period of 5mn) could be a nagios monitoring
>> occuring regularly but in that case why only 2 milters are affected ?
>>
>> I found inside sendmail source and KNOWBUGS file a bug related to
>> NOQUEUE: but not related with milter
>>
>> =====
>> * accept() problem on Linux.
>>
>> The accept() in sendmail daemon loop can return ETIMEDOUT. An
>> error is reported to syslog:
>>
>> Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
>> getrequests: accept: Connection timed out
>>
>> "Connection timed out" is not documented as a valid return from
>> accept(2) and this was believed to be a bug in the Linux kernel.
>> Later information from the Linux kernel group states that Linux
>> 2.0 kernels follow RFC1122 while sendmail follows the original BSD
>> (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels
>> will follow the POSIX draft.
>> =====
>>
>> I have a 2.6.X kernel so both kernel and sendmail are POSIX ... and I
>> have no such message
>> >
>> > /john
>> >
>> >
>> >
>> > Den 16-03-2018 kl. 12:32 skrev Christian P�lissier
>> > Christian.Pelissier@... [milter-greylist]:
>> >
>> > >
>> > > Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
>> > > john@... [milter-greylist] a �crit :
>> > > > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
>> > >
>> > > I have no 10s timeout. I've changed C:5m to c:6m. Logging period is
>> > > always 5mn.
>> > >
>> > > Mimedefang log the same thing at the same time but opendkim,
>> > > opendmarc
>> > > clamav do not log NOQUEUE message.
>> > >
>> > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (greylist): to
>> > > error state
>> > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (mimedefang): to
>> > > error state
>> > >
>> > > Opendkim and Opendmarc have default flags
>> > >
>> > > --
>> > > Christian P�lissier
>> > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
>> > > \ue201 34419
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> > Virusfri. www.avast.com
>> >
>> >
>> >
>>
>> -- 
>> Christian P�lissier
>> \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
>> \ue201 34419
>>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virusfri. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 



---
Denne e-mail blev kontrolleret for virusser af Avast antivirussoftware.
https://www.avast.com/antivirus

Le vendredi 16 mars 2018 � 17:40 +0100, John Damm S�rensen
john@... [milter-greylist] a �crit :
>   
> The sendmail code issuing the error message is in the  milter_error()
> function which has this comment:
> 
>         /*
>         **  We could send a quit here but we may have gotten here due
> to
>         **  an I/O error so we don't want to try to make things worse.
>         */
> So it might be useful to check the messages file for error messages
> related to general system starvation ( memory, file system, /tmp ,
> etc.)
> 
> When everything else fails try run strace -o <output file> -tfp <pid
> of milter-greylist> and check for errors.



After checking many things, logs "NOQUEUE to error state" are related to
nagios monitoring.
/usr/lib64/nagios/plugins/check_nrpe -H $IP -c check_mailq -t 10




> Best
> 
> John
> 
> 
> Den 16-03-2018 kl. 17:00 skrev Christian P�lissier
> Christian.Pelissier@... [milter-greylist]:
> 
> >   
> > Le vendredi 16 mars 2018 � 12:40 +0100, John Damm S�rensen
> > john@... [milter-greylist] a �crit :
> > > 
> > > So both greylist and mimedefang fails. Do you see anything in the
> > > logs? Are they failing on the same email maessage?
> > 
> > Both have always the same sendmail PID 17925 in the example
> > > How are they defined in the .cf/.mc file?
> > 
> > Well ... I hope
> > 
> > INPUT_MAIL_FILTER(`greylist',
> > `S=local:/var/milter-greylist/milter-greylist.sock,
> > T=C=6m;S:10m;R:10m;E:10m')dnl
> > INPUT_MAIL_FILTER(`mimedefang',
> > `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T,
> > T=S:360s;R:360s;E:15m')
> > 
> > INPUT_MAIL_FILTER(`opendkim', `S=inet:4445@127.0.0.1')dnl
> > 
> > I can try to use an inet socket, but I have other milter with local
> > socket and they do not log NOQUEUE messages.
> > 
> > Milter API evolved with time. Could we have both in mimedefang and
> > milter-greylist and old style milter callback indirectly related
> > with
> > theses log lines ??
> > 
> > Another cause (the stange period of 5mn) could be a nagios
> > monitoring
> > occuring regularly but in that case why only 2 milters are
> > affected ?
> > 
> > I found inside sendmail source and KNOWBUGS file a bug related to
> > NOQUEUE: but not related with milter 
> > 
> > =====
> > * accept() problem on Linux.
> > 
> > The accept() in sendmail daemon loop can return ETIMEDOUT. An
> > error is reported to syslog:
> > 
> > Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
> > getrequests: accept: Connection timed out
> > 
> > "Connection timed out" is not documented as a valid return from
> > accept(2) and this was believed to be a bug in the Linux kernel.
> > Later information from the Linux kernel group states that Linux
> > 2.0 kernels follow RFC1122 while sendmail follows the original BSD
> > (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels
> > will follow the POSIX draft.
> > =====
> > 
> > I have a 2.6.X kernel so both kernel and sendmail are POSIX ... and
> > I
> > have no such message
> > > 
> > > /john
> > > 
> > > 
> > > 
> > > Den 16-03-2018 kl. 12:32 skrev Christian P�lissier
> > > Christian.Pelissier@... [milter-greylist]:
> > > 
> > > > 
> > > > Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
> > > > john@... [milter-greylist] a �crit :
> > > > >
> > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
> > > > 
> > > > I have no 10s timeout. I've changed C:5m to c:6m. Logging period
> > is
> > > > always 5mn.
> > > > 
> > > > Mimedefang log the same thing at the same time but opendkim,
> > > > opendmarc
> > > > clamav do not log NOQUEUE message.
> > > > 
> > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (greylist):
> > to
> > > > error state
> > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter
> > (mimedefang): to
> > > > error state
> > > > 
> > > > Opendkim and Opendmarc have default flags
> > > > 
> > > > -- 
> > > > Christian P�lissier
> > > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > > \ue201 34419
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > Virusfri. www.avast.com 
> > > 
> > > 
> > > 
> > 
> > -- 
> > Christian P�lissier
> > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > \ue201 34419
> > 
> > 
> > 
> > 
> 
> 
> 
> Virusfri. www.avast.com 
> 
> 
> 

-- 
Christian P�lissier
\ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
\ue201 34419

By default the Nagios check_mailq plugin tries to autodetect the mail 
server type. I guess this check results in the NOQUEUE errors. You can 
tell the Nagios check_mailq plugin what type of mail server you are 
using via the -M |[ sendmail | qmail | postfix | exim | nullmailer ]| 
option for the plugin.

Best

John


Den 20-03-2018 kl. 10:18 skrev Christian P�lissier 
Christian.Pelissier@... [milter-greylist]:
>
> Le vendredi 16 mars 2018 � 17:40 +0100, John Damm S�rensen
> john@... [milter-greylist] a �crit :
> >
> > The sendmail code issuing the error message is in the milter_error()
> > function which has this comment:
> >
> > /*
> > ** We could send a quit here but we may have gotten here due
> > to
> > ** an I/O error so we don't want to try to make things worse.
> > */
> > So it might be useful to check the messages file for error messages
> > related to general system starvation ( memory, file system, /tmp ,
> > etc.)
> >
> > When everything else fails try run strace -o <output file> -tfp <pid
> > of milter-greylist> and check for errors.
>
> After checking many things, logs "NOQUEUE to error state" are related to
> nagios monitoring.
> /usr/lib64/nagios/plugins/check_nrpe -H $IP -c check_mailq -t 10
>
> > Best
> >
> > John
> >
> >
> > Den 16-03-2018 kl. 17:00 skrev Christian P�lissier
> > Christian.Pelissier@... [milter-greylist]:
> >
> > >
> > > Le vendredi 16 mars 2018 � 12:40 +0100, John Damm S�rensen
> > > john@... [milter-greylist] a �crit :
> > > >
> > > > So both greylist and mimedefang fails. Do you see anything in the
> > > > logs? Are they failing on the same email maessage?
> > >
> > > Both have always the same sendmail PID 17925 in the example
> > > > How are they defined in the .cf/.mc file?
> > >
> > > Well ... I hope
> > >
> > > INPUT_MAIL_FILTER(`greylist',
> > > `S=local:/var/milter-greylist/milter-greylist.sock,
> > > T=C=6m;S:10m;R:10m;E:10m')dnl
> > > INPUT_MAIL_FILTER(`mimedefang',
> > > `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T,
> > > T=S:360s;R:360s;E:15m')
> > >
> > > INPUT_MAIL_FILTER(`opendkim', `S=inet:4445@127.0.0.1')dnl
> > >
> > > I can try to use an inet socket, but I have other milter with local
> > > socket and they do not log NOQUEUE messages.
> > >
> > > Milter API evolved with time. Could we have both in mimedefang and
> > > milter-greylist and old style milter callback indirectly related
> > > with
> > > theses log lines ??
> > >
> > > Another cause (the stange period of 5mn) could be a nagios
> > > monitoring
> > > occuring regularly but in that case why only 2 milters are
> > > affected ?
> > >
> > > I found inside sendmail source and KNOWBUGS file a bug related to
> > > NOQUEUE: but not related with milter
> > >
> > > =====
> > > * accept() problem on Linux.
> > >
> > > The accept() in sendmail daemon loop can return ETIMEDOUT. An
> > > error is reported to syslog:
> > >
> > > Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
> > > getrequests: accept: Connection timed out
> > >
> > > "Connection timed out" is not documented as a valid return from
> > > accept(2) and this was believed to be a bug in the Linux kernel.
> > > Later information from the Linux kernel group states that Linux
> > > 2.0 kernels follow RFC1122 while sendmail follows the original BSD
> > > (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels
> > > will follow the POSIX draft.
> > > =====
> > >
> > > I have a 2.6.X kernel so both kernel and sendmail are POSIX ... and
> > > I
> > > have no such message
> > > >
> > > > /john
> > > >
> > > >
> > > >
> > > > Den 16-03-2018 kl. 12:32 skrev Christian P�lissier
> > > > Christian.Pelissier@... [milter-greylist]:
> > > >
> > > > >
> > > > > Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
> > > > > john@... [milter-greylist] a �crit :
> > > > > >
> > > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
> > > > >
> > > > > I have no 10s timeout. I've changed C:5m to c:6m. Logging period
> > > is
> > > > > always 5mn.
> > > > >
> > > > > Mimedefang log the same thing at the same time but opendkim,
> > > > > opendmarc
> > > > > clamav do not log NOQUEUE message.
> > > > >
> > > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (greylist):
> > > to
> > > > > error state
> > > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter
> > > (mimedefang): to
> > > > > error state
> > > > >
> > > > > Opendkim and Opendmarc have default flags
> > > > >
> > > > > --
> > > > > Christian P�lissier
> > > > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > > > \ue201 34419
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > Virusfri. www.avast.com
> > > >
> > > >
> > > >
> > >
> > > --
> > > Christian P�lissier
> > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > \ue201 34419
> > >
> > >
> > >
> > >
> >
> >
> >
> > Virusfri. www.avast.com
> >
> >
> >
>
> -- 
> Christian P�lissier
> \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> \ue201 34419
>
> 



---
Denne e-mail blev kontrolleret for virusser af Avast antivirussoftware.
https://www.avast.com/antivirus

Le mardi 20 mars 2018 � 14:19 +0100, John Damm S�rensen
john@... [milter-greylist] a �crit :
>   
> By default the Nagios check_mailq plugin tries to autodetect the mail
> server type. I guess this check results in the NOQUEUE errors. You can
> tell the Nagios check_mailq plugin what type of mail server you are
> using via the -M [ sendmail | qmail | postfix | exim | nullmailer ]
> option for the plugin.
> 
> Best
> 
> John
Thanks but it's not a solution to add -M because in fact we log the
lines everytime we launch mailq as a non root account. For example

On a standard sendmail gateway config we have :

# su - nagios -c mailq
can not chdir(/var/spool/mqueue/): Permission denied <<<<
Program mode requires special privileges, e.g., root or TrustedUser.

And this related log

Mar 20 14:49:39 onera sendmail[3708]: NOQUEUE: SYSERR(nagios): can not
chdir(/var/spool/mqueue/): Permission denied



On this customized and miltered antispam/antivirus config with
different /var/spool/mqueue/ permissions

# su - nagios -c mailq
You are not permitted to see the queue <<<<
		Total requests: 0

Mar 20 14:41:18 emix2 sendmail[5921]: NOQUEUE: Milter (greylist): to
error state
Mar 20 14:41:18 emix2 sendmail[5921]: NOQUEUE: Milter (mimedefang): to
error state

We have same sendmail patch level version on both server.


Theses differences are the result of sendmail.mc choices. However if I
understand the different mailq messages : can not
chdir(/var/spool/mqueue/): Permission denied AND You are not permitted
to see the queue,
I don't understand which relation between mailq non root attempt to list
the queue and mimedefang and milter-greylist milter ?





> 
> Den 20-03-2018 kl. 10:18 skrev Christian P�lissier
> Christian.Pelissier@... [milter-greylist]:
> 
> >   
> > Le vendredi 16 mars 2018 � 17:40 +0100, John Damm S�rensen
> > john@... [milter-greylist] a �crit :
> > > 
> > > The sendmail code issuing the error message is in the
> > milter_error()
> > > function which has this comment:
> > > 
> > > /*
> > > ** We could send a quit here but we may have gotten here due
> > > to
> > > ** an I/O error so we don't want to try to make things worse.
> > > */
> > > So it might be useful to check the messages file for error
> > messages
> > > related to general system starvation ( memory, file system, /tmp ,
> > > etc.)
> > > 
> > > When everything else fails try run strace -o <output file> -tfp
> > <pid
> > > of milter-greylist> and check for errors.
> > 
> > After checking many things, logs "NOQUEUE to error state" are
> > related to
> > nagios monitoring.
> > /usr/lib64/nagios/plugins/check_nrpe -H $IP -c check_mailq -t 10
> > 
> > > Best
> > > 
> > > John
> > > 
> > > 
> > > Den 16-03-2018 kl. 17:00 skrev Christian P�lissier
> > > Christian.Pelissier@... [milter-greylist]:
> > > 
> > > > 
> > > > Le vendredi 16 mars 2018 � 12:40 +0100, John Damm S�rensen
> > > > john@... [milter-greylist] a �crit :
> > > > > 
> > > > > So both greylist and mimedefang fails. Do you see anything in
> > the
> > > > > logs? Are they failing on the same email maessage?
> > > > 
> > > > Both have always the same sendmail PID 17925 in the example
> > > > > How are they defined in the .cf/.mc file?
> > > > 
> > > > Well ... I hope
> > > > 
> > > > INPUT_MAIL_FILTER(`greylist',
> > > > `S=local:/var/milter-greylist/milter-greylist.sock,
> > > > T=C=6m;S:10m;R:10m;E:10m')dnl
> > > > INPUT_MAIL_FILTER(`mimedefang',
> > > > `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T,
> > > > T=S:360s;R:360s;E:15m')
> > > > 
> > > > INPUT_MAIL_FILTER(`opendkim', `S=inet:4445@127.0.0.1')dnl
> > > > 
> > > > I can try to use an inet socket, but I have other milter with
> > local
> > > > socket and they do not log NOQUEUE messages.
> > > > 
> > > > Milter API evolved with time. Could we have both in mimedefang
> > and
> > > > milter-greylist and old style milter callback indirectly related
> > > > with
> > > > theses log lines ??
> > > > 
> > > > Another cause (the stange period of 5mn) could be a nagios
> > > > monitoring
> > > > occuring regularly but in that case why only 2 milters are
> > > > affected ?
> > > > 
> > > > I found inside sendmail source and KNOWBUGS file a bug related
> > to
> > > > NOQUEUE: but not related with milter 
> > > > 
> > > > =====
> > > > * accept() problem on Linux.
> > > > 
> > > > The accept() in sendmail daemon loop can return ETIMEDOUT. An
> > > > error is reported to syslog:
> > > > 
> > > > Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
> > > > getrequests: accept: Connection timed out
> > > > 
> > > > "Connection timed out" is not documented as a valid return from
> > > > accept(2) and this was believed to be a bug in the Linux kernel.
> > > > Later information from the Linux kernel group states that Linux
> > > > 2.0 kernels follow RFC1122 while sendmail follows the original
> > BSD
> > > > (now POSIX 1003.1g draft) specification. The 2.1.X and later
> > kernels
> > > > will follow the POSIX draft.
> > > > =====
> > > > 
> > > > I have a 2.6.X kernel so both kernel and sendmail are POSIX ...
> > and
> > > > I
> > > > have no such message
> > > > > 
> > > > > /john
> > > > > 
> > > > > 
> > > > > 
> > > > > Den 16-03-2018 kl. 12:32 skrev Christian P�lissier
> > > > > Christian.Pelissier@... [milter-greylist]:
> > > > > 
> > > > > > 
> > > > > > Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
> > > > > > john@... [milter-greylist] a �crit :
> > > > > > >
> > > > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
> > > > > > 
> > > > > > I have no 10s timeout. I've changed C:5m to c:6m. Logging
> > period
> > > > is
> > > > > > always 5mn.
> > > > > > 
> > > > > > Mimedefang log the same thing at the same time but opendkim,
> > > > > > opendmarc
> > > > > > clamav do not log NOQUEUE message.
> > > > > > 
> > > > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter
> > (greylist):
> > > > to
> > > > > > error state
> > > > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter
> > > > (mimedefang): to
> > > > > > error state
> > > > > > 
> > > > > > Opendkim and Opendmarc have default flags
> > > > > > 
> > > > > > -- 
> > > > > > Christian P�lissier
> > > > > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > > > > \ue201 34419
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Virusfri. www.avast.com 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > -- 
> > > > Christian P�lissier
> > > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > > \ue201 34419
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > Virusfri. www.avast.com 
> > > 
> > > 
> > > 
> > 
> > -- 
> > Christian P�lissier
> > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > \ue201 34419
> > 
> > 
> > 
> > 
> 
> 
> 
> Virusfri. www.avast.com 
> 
> 
> 

-- 
Christian P�lissier
\ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
\ue201 34419

From the latest source code for the check_mailq it doesn't seem as if 
the plugin makes connections to mail server in order to determine what 
type of server your are using. Instead the plugin test for the existence 
of certain directories and files, which I believe could lead to wrong 
tests if you have more than one mail server installed.

Best

John


Den 20-03-2018 kl. 14:19 skrev John Damm S�rensen john@... 
[milter-greylist]:
>
> By default the Nagios check_mailq plugin tries to autodetect the mail 
> server type. I guess this check results in the NOQUEUE errors. You can 
> tell the Nagios check_mailq plugin what type of mail server you are 
> using via the -M |[ sendmail | qmail | postfix | exim | nullmailer ]| 
> option for the plugin.
>
> Best
>
> John
>
>
> Den 20-03-2018 kl. 10:18 skrev Christian P�lissier 
> Christian.Pelissier@... [milter-greylist]:
>>
>> Le vendredi 16 mars 2018 � 17:40 +0100, John Damm S�rensen
>> john@... [milter-greylist] a �crit :
>> >
>> > The sendmail code issuing the error message is in the milter_error()
>> > function which has this comment:
>> >
>> > /*
>> > ** We could send a quit here but we may have gotten here due
>> > to
>> > ** an I/O error so we don't want to try to make things worse.
>> > */
>> > So it might be useful to check the messages file for error messages
>> > related to general system starvation ( memory, file system, /tmp ,
>> > etc.)
>> >
>> > When everything else fails try run strace -o <output file> -tfp <pid
>> > of milter-greylist> and check for errors.
>>
>> After checking many things, logs "NOQUEUE to error state" are related to
>> nagios monitoring.
>> /usr/lib64/nagios/plugins/check_nrpe -H $IP -c check_mailq -t 10
>>
>> > Best
>> >
>> > John
>> >
>> >
>> > Den 16-03-2018 kl. 17:00 skrev Christian P�lissier
>> > Christian.Pelissier@... [milter-greylist]:
>> >
>> > >
>> > > Le vendredi 16 mars 2018 � 12:40 +0100, John Damm S�rensen
>> > > john@... [milter-greylist] a �crit :
>> > > >
>> > > > So both greylist and mimedefang fails. Do you see anything in the
>> > > > logs? Are they failing on the same email maessage?
>> > >
>> > > Both have always the same sendmail PID 17925 in the example
>> > > > How are they defined in the .cf/.mc file?
>> > >
>> > > Well ... I hope
>> > >
>> > > INPUT_MAIL_FILTER(`greylist',
>> > > `S=local:/var/milter-greylist/milter-greylist.sock,
>> > > T=C=6m;S:10m;R:10m;E:10m')dnl
>> > > INPUT_MAIL_FILTER(`mimedefang',
>> > > `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T,
>> > > T=S:360s;R:360s;E:15m')
>> > >
>> > > INPUT_MAIL_FILTER(`opendkim', `S=inet:4445@127.0.0.1')dnl
>> > >
>> > > I can try to use an inet socket, but I have other milter with local
>> > > socket and they do not log NOQUEUE messages.
>> > >
>> > > Milter API evolved with time. Could we have both in mimedefang and
>> > > milter-greylist and old style milter callback indirectly related
>> > > with
>> > > theses log lines ??
>> > >
>> > > Another cause (the stange period of 5mn) could be a nagios
>> > > monitoring
>> > > occuring regularly but in that case why only 2 milters are
>> > > affected ?
>> > >
>> > > I found inside sendmail source and KNOWBUGS file a bug related to
>> > > NOQUEUE: but not related with milter
>> > >
>> > > =====
>> > > * accept() problem on Linux.
>> > >
>> > > The accept() in sendmail daemon loop can return ETIMEDOUT. An
>> > > error is reported to syslog:
>> > >
>> > > Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
>> > > getrequests: accept: Connection timed out
>> > >
>> > > "Connection timed out" is not documented as a valid return from
>> > > accept(2) and this was believed to be a bug in the Linux kernel.
>> > > Later information from the Linux kernel group states that Linux
>> > > 2.0 kernels follow RFC1122 while sendmail follows the original BSD
>> > > (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels
>> > > will follow the POSIX draft.
>> > > =====
>> > >
>> > > I have a 2.6.X kernel so both kernel and sendmail are POSIX ... and
>> > > I
>> > > have no such message
>> > > >
>> > > > /john
>> > > >
>> > > >
>> > > >
>> > > > Den 16-03-2018 kl. 12:32 skrev Christian P�lissier
>> > > > Christian.Pelissier@... [milter-greylist]:
>> > > >
>> > > > >
>> > > > > Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
>> > > > > john@... [milter-greylist] a �crit :
>> > > > > >
>> > > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
>> > > > >
>> > > > > I have no 10s timeout. I've changed C:5m to c:6m. Logging period
>> > > is
>> > > > > always 5mn.
>> > > > >
>> > > > > Mimedefang log the same thing at the same time but opendkim,
>> > > > > opendmarc
>> > > > > clamav do not log NOQUEUE message.
>> > > > >
>> > > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter (greylist):
>> > > to
>> > > > > error state
>> > > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter
>> > > (mimedefang): to
>> > > > > error state
>> > > > >
>> > > > > Opendkim and Opendmarc have default flags
>> > > > >
>> > > > > --
>> > > > > Christian P�lissier
>> > > > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
>> > > > > \ue201 34419
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > Virusfri. www.avast.com
>> > > >
>> > > >
>> > > >
>> > >
>> > > --
>> > > Christian P�lissier
>> > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
>> > > \ue201 34419
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> > Virusfri. www.avast.com
>> >
>> >
>> >
>>
>> -- 
>> Christian P�lissier
>> \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
>> \ue201 34419
>>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virusfri. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 



---
Denne e-mail blev kontrolleret for virusser af Avast antivirussoftware.
https://www.avast.com/antivirus

Is the NOQUEUE message also generated if you execute the mailq command 
as the nagois user?

Best

John


Den 20-03-2018 kl. 15:35 skrev Christian P�lissier 
Christian.Pelissier@... [milter-greylist]:
>
> Le mardi 20 mars 2018 � 14:19 +0100, John Damm S�rensen
> john@... [milter-greylist] a �crit :
> >
> > By default the Nagios check_mailq plugin tries to autodetect the mail
> > server type. I guess this check results in the NOQUEUE errors. You can
> > tell the Nagios check_mailq plugin what type of mail server you are
> > using via the -M [ sendmail | qmail | postfix | exim | nullmailer ]
> > option for the plugin.
> >
> > Best
> >
> > John
> Thanks but it's not a solution to add -M because in fact we log the
> lines everytime we launch mailq as a non root account. For example
>
> On a standard sendmail gateway config we have :
>
> # su - nagios -c mailq
> can not chdir(/var/spool/mqueue/): Permission denied <<<<
> Program mode requires special privileges, e.g., root or TrustedUser.
>
> And this related log
>
> Mar 20 14:49:39 onera sendmail[3708]: NOQUEUE: SYSERR(nagios): can not
> chdir(/var/spool/mqueue/): Permission denied
>
> On this customized and miltered antispam/antivirus config with
> different /var/spool/mqueue/ permissions
>
> # su - nagios -c mailq
> You are not permitted to see the queue <<<<
> Total requests: 0
>
> Mar 20 14:41:18 emix2 sendmail[5921]: NOQUEUE: Milter (greylist): to
> error state
> Mar 20 14:41:18 emix2 sendmail[5921]: NOQUEUE: Milter (mimedefang): to
> error state
>
> We have same sendmail patch level version on both server.
>
> Theses differences are the result of sendmail.mc choices. However if I
> understand the different mailq messages : can not
> chdir(/var/spool/mqueue/): Permission denied AND You are not permitted
> to see the queue,
> I don't understand which relation between mailq non root attempt to list
> the queue and mimedefang and milter-greylist milter ?
>
> >
> > Den 20-03-2018 kl. 10:18 skrev Christian P�lissier
> > Christian.Pelissier@... [milter-greylist]:
> >
> > >
> > > Le vendredi 16 mars 2018 � 17:40 +0100, John Damm S�rensen
> > > john@... [milter-greylist] a �crit :
> > > >
> > > > The sendmail code issuing the error message is in the
> > > milter_error()
> > > > function which has this comment:
> > > >
> > > > /*
> > > > ** We could send a quit here but we may have gotten here due
> > > > to
> > > > ** an I/O error so we don't want to try to make things worse.
> > > > */
> > > > So it might be useful to check the messages file for error
> > > messages
> > > > related to general system starvation ( memory, file system, /tmp ,
> > > > etc.)
> > > >
> > > > When everything else fails try run strace -o <output file> -tfp
> > > <pid
> > > > of milter-greylist> and check for errors.
> > >
> > > After checking many things, logs "NOQUEUE to error state" are
> > > related to
> > > nagios monitoring.
> > > /usr/lib64/nagios/plugins/check_nrpe -H $IP -c check_mailq -t 10
> > >
> > > > Best
> > > >
> > > > John
> > > >
> > > >
> > > > Den 16-03-2018 kl. 17:00 skrev Christian P�lissier
> > > > Christian.Pelissier@... [milter-greylist]:
> > > >
> > > > >
> > > > > Le vendredi 16 mars 2018 � 12:40 +0100, John Damm S�rensen
> > > > > john@... [milter-greylist] a �crit :
> > > > > >
> > > > > > So both greylist and mimedefang fails. Do you see anything in
> > > the
> > > > > > logs? Are they failing on the same email maessage?
> > > > >
> > > > > Both have always the same sendmail PID 17925 in the example
> > > > > > How are they defined in the .cf/.mc file?
> > > > >
> > > > > Well ... I hope
> > > > >
> > > > > INPUT_MAIL_FILTER(`greylist',
> > > > > `S=local:/var/milter-greylist/milter-greylist.sock,
> > > > > T=C=6m;S:10m;R:10m;E:10m')dnl
> > > > > INPUT_MAIL_FILTER(`mimedefang',
> > > > > `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T,
> > > > > T=S:360s;R:360s;E:15m')
> > > > >
> > > > > INPUT_MAIL_FILTER(`opendkim', `S=inet:4445@127.0.0.1')dnl
> > > > >
> > > > > I can try to use an inet socket, but I have other milter with
> > > local
> > > > > socket and they do not log NOQUEUE messages.
> > > > >
> > > > > Milter API evolved with time. Could we have both in mimedefang
> > > and
> > > > > milter-greylist and old style milter callback indirectly related
> > > > > with
> > > > > theses log lines ??
> > > > >
> > > > > Another cause (the stange period of 5mn) could be a nagios
> > > > > monitoring
> > > > > occuring regularly but in that case why only 2 milters are
> > > > > affected ?
> > > > >
> > > > > I found inside sendmail source and KNOWBUGS file a bug related
> > > to
> > > > > NOQUEUE: but not related with milter
> > > > >
> > > > > =====
> > > > > * accept() problem on Linux.
> > > > >
> > > > > The accept() in sendmail daemon loop can return ETIMEDOUT. An
> > > > > error is reported to syslog:
> > > > >
> > > > > Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
> > > > > getrequests: accept: Connection timed out
> > > > >
> > > > > "Connection timed out" is not documented as a valid return from
> > > > > accept(2) and this was believed to be a bug in the Linux kernel.
> > > > > Later information from the Linux kernel group states that Linux
> > > > > 2.0 kernels follow RFC1122 while sendmail follows the original
> > > BSD
> > > > > (now POSIX 1003.1g draft) specification. The 2.1.X and later
> > > kernels
> > > > > will follow the POSIX draft.
> > > > > =====
> > > > >
> > > > > I have a 2.6.X kernel so both kernel and sendmail are POSIX ...
> > > and
> > > > > I
> > > > > have no such message
> > > > > >
> > > > > > /john
> > > > > >
> > > > > >
> > > > > >
> > > > > > Den 16-03-2018 kl. 12:32 skrev Christian P�lissier
> > > > > > Christian.Pelissier@... [milter-greylist]:
> > > > > >
> > > > > > >
> > > > > > > Le vendredi 16 mars 2018 � 09:46 +0100, John Damm S�rensen
> > > > > > > john@... [milter-greylist] a �crit :
> > > > > > > >
> > > > > http://thread.gmane.org/gmane.mail.sendmail.milter.greylist/2827
> > > > > > >
> > > > > > > I have no 10s timeout. I've changed C:5m to c:6m. Logging
> > > period
> > > > > is
> > > > > > > always 5mn.
> > > > > > >
> > > > > > > Mimedefang log the same thing at the same time but opendkim,
> > > > > > > opendmarc
> > > > > > > clamav do not log NOQUEUE message.
> > > > > > >
> > > > > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter
> > > (greylist):
> > > > > to
> > > > > > > error state
> > > > > > > Mar 16 12:27:10 mx sendmail[17925]: NOQUEUE: Milter
> > > > > (mimedefang): to
> > > > > > > error state
> > > > > > >
> > > > > > > Opendkim and Opendmarc have default flags
> > > > > > >
> > > > > > > --
> > > > > > > Christian P�lissier
> > > > > > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > > > > > \ue201 34419
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Virusfri. www.avast.com
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Christian P�lissier
> > > > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > > > \ue201 34419
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > Virusfri. www.avast.com
> > > >
> > > >
> > > >
> > >
> > > --
> > > Christian P�lissier
> > > \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> > > \ue201 34419
> > >
> > >
> > >
> > >
> >
> >
> >
> > Virusfri. www.avast.com
> >
> >
> >
>
> -- 
> Christian P�lissier
> \ue40aONERA DSI/ISR BP72 92322 Chatillon CEDEX\ue409
> \ue201 34419
>
> 



---
Denne e-mail blev kontrolleret for virusser af Avast antivirussoftware.
https://www.avast.com/antivirus