Hi,

I found the following error many times but only from the same sending
server in my sendmail log (never seen before, 2000K mails since setup):

---------------------------
Aug 19 12:22:17 server milter-greylist: p7JAME8U015316: addr 83.19.xx.xx
from <sender@domain.de> rcpt <recip@mydomain.de>: autowhitelisted for
another 768:00:00
Aug 19 14:51:45 server sm-mta[15316]: p7JAME8U015316:
from=<sender@domain.de>, size=125990, class=0, nrcpts=1,
msgid=<@OF45480D59.66ADE979-ONC12578F1.00339A09-
C12578F8.00294A3Adomain.de>,
proto=ESMTP, daemon=MTA-v4, relay=domino.domain.de [88.79.xx.xx]
Aug 19 14:51:45 server sm-mta[15316]: p7JAME8U015316: Milter (greylist):
write(L) returned -1, expected 50: Broken pipe
Aug 19 14:51:45 server sm-mta[15316]: p7JAME8U015316: Milter (greylist):
to error state
Aug 19 14:51:45 server sm-mta[15316]: p7JAME8U015316: Milter
(mimedefang):
write(L) returned -1, expected 50: Broken pipe
Aug 19 14:51:45 server sm-mta[15316]: p7JAME8U015316: Milter
(mimedefang):
to error state
Aug 19 14:51:45 server sm-mta[15316]: p7JAME8U015316: Milter: data,
reject=451 4.3.2 Please try again later
Aug 19 14:51:45 server sm-mta[15316]: p7JAME8U015316:
to=<recip@mydomain.de>, delay=02:29:28, pri=155990, stat=Please try
again later
---------------------------


my /etc/mail/sendmail.mc
---------------------------
INPUT_MAIL_FILTER(`greylist',`S=local:/var/run/milter-greylist/milter-
greylist.sock, F=, T=S:1m;R:1m')dnl

INPUT_MAIL_FILTER(`mimedefang',
`S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T,
T=S:5m;R:5m;E:10m')dnl
---------------------------

I can see the sending server hanging on DATA in the process table

---------------------------
21780 ? S 0:00 sendmail: MTA: p7QMGAME021780 domino.domain.de
[83.19.xx.xx]: DATA
---------------------------


The sending server came back with a slightly different error message 
(expected 31) today:

---------------------------
Aug 29 19:02:50 server sm-mta[31454]: p7TEVVaJ031454: Milter (greylist): 
write(L) returned -1, expected 31: Broken pipe
Aug 29 19:02:50 dexter sm-mta[31454]: p7TEVVaJ031454: Milter 
(mimedefang): write(L) returned -1, expected 31: Broken pipe
---------------------------

I started a tcpdump which shows a lot of TCP Retransmission from the 
sending server, while my server is always answering with an ACK:


---------------------------
787	10404.027462	83.19.xx.xx	211.xx.xx.xx	TCP	orbix-
locator > smtp [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=5
788	10404.027481	211.xx.xx.xx	83.19.xx.xx	TCP	smtp > 
orbix-locator [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
789	10404.044224	83.19.xx.xx	211.xx.xx.xx	TCP	orbix-
locator > smtp [ACK] Seq=1 Ack=1 Win=1048576 Len=0789	
790	10407.046338	211.xx.xx.xx	83.19.xx.xx	SMTP	S: 220 
mx.mydomain.de ESMTP MyDomain Mailer; Mon, 29 Aug 2011 16:31:31 +0200 
(CET)
791	10407.063540	83.19.xx.xx	211.xx.xx.xx	SMTP	C: EHLO 
domino.senderdomain.de
792	10407.063556	211.xx.xx.xx	83.19.xx.xx	TCP	smtp > 
orbix-locator [ACK] Seq=88 Ack=24 Win=5888 Len=0
793	10407.063748	211.xx.xx.xx	83.19.xx.xx	SMTP	S: 250-
mx.mydomain.de Hello domino.senderdomain.de [83.19.xx.xx], pleased to 
meet you | 250-ENHANCEDSTATUSCODES | 250-PIPELINING | 250-8BITMIME | 250-
SIZE 41943040 | 250-ETRN | 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN | 250-
STARTTLS | 250-DELIVERBY | 250 HELP
794	10407.082584	83.19.xx.xx	211.xx.xx.xx	SMTP	C: MAIL 
FROM:<firstname.lastname@senderdomain.de> SIZE=125838 | RCPT 
TO:<info@recipdomain.de> | DATA
795	10407.086341	211.xx.xx.xx	83.19.xx.xx	SMTP	S: 250 
2.1.0 <firstname.lastname@senderdomain.de>... Sender ok | 250 2.1.5 
<info@recipdomain.de>... Recipient ok | 354 Enter mail, end with "." on a 
line by itself
796	10407.113082	83.19.xx.xx	211.xx.xx.xx	SMTP	[TCP 
Previous segment lost] C: DATA fragment, 1460 bytes
797	10407.113097	211.xx.xx.xx	83.19.xx.xx	TCP	[TCP Dup 
ACK 795#1] smtp > orbix-locator [ACK] Seq=485 Ack=112 Win=5888 Len=0 
SLE=4206 SRE=5666
798	10408.929021	83.19.xx.xx	211.xx.xx.xx	SMTP	[TCP 
Retransmission] C: DATA fragment, 1460 bytes
799	10408.929036	211.xx.xx.xx	83.19.xx.xx	TCP	smtp > 
orbix-locator [ACK] Seq=485 Ack=1572 Win=8768 Len=0 SLE=4206 SRE=5666
800	10408.948966	83.19.xx.xx	211.xx.xx.xx	SMTP	[TCP 
Retransmission] C: DATA fragment, 1460 bytes
801	10408.948981	211.xx.xx.xx	83.19.xx.xx	TCP	smtp > 
orbix-locator [ACK] Seq=485 Ack=3032 Win=11712 Len=0 SLE=4206 SRE=5666
802	10408.951928	83.19.xx.xx	211.xx.xx.xx	SMTP	[TCP 
Retransmission] C: DATA fragment, 1460 bytes803	10408.951942
803	10408.951942	211.xx.xx.xx	83.19.xx.xx	TCP	smtp > 
orbix-locator [ACK] Seq=485 Ack=5666 Win=14656 Len=0 SLE=4206 
804	10408.968860	83.19.xx.xx	211.xx.xx.xx	SMTP	[TCP 
Retransmission] C: DATA fragment, 1460 bytes
[...]
987	12529.161226	83.19.xx.xx	211.xx.xx.xx	TCP	[TCP 
Previous segment lost] cesdinv > smtp [PSH, ACK] Seq=90632 Ack=485 
Win=1048064 Len=0
988	12557.025842	83.19.xx.xx	211.xx.xx.xx	SMTP	[TCP 
Retransmission] C: DATA fragment, 1460 bytes
989	12557.025861	211.xx.xx.xx	83.19.xx.xx	TCP	smtp > 
gte-samp [ACK] Seq=485 Ack=128592 Win=64128 Len=0
990	12557.044861	83.19.xx.xx	211.xx.xx.xx	IMF	subject: 
[restricted]
991	12557.082295	211.xx.xx.xx	83.19.xx.xx	TCP	smtp > 
gte-samp [ACK] Seq=485 Ack=129238 Win=64128 Len=0
992	12557.186893	211.xx.xx.xx	83.19.xx.xx	SMTP	S: 451 
4.3.2 Please try again later
993	12557.186905	211.xx.xx.xx	83.19.xx.xx	TCP	smtp > 
gte-samp [FIN, ACK] Seq=519 Ack=129238 Win=64128 Len=0
994	12557.203527	83.19.xx.xx	211.xx.xx.xx	TCP	gte-samp 
> smtp [RST, ACK] Seq=129238 Ack=519 Win=0 Len=0
995	12557.203656	83.19.xx.xx	211.xx.xx.xx	TCP	gte-samp 
> smtp [RST] Seq=129238 Win=0 Len=0
996	12640.632093	83.19.xx.xx	211.xx.xx.xx	SMTP	[TCP 
Retransmission] C: DATA fragment, 1460 bytes
---------------------------

my System:
sendmail             8.14.3-5+lenny1 
mimedefang           2.64-6
milter-greylist      4.3.5-3
libmilter1.0.1       8.14.3-5 patched [1]

[1] http://www.j-chkmail.org/download/libmilter/

Is there anything wrong with my mimedefang milter timeouts or is it just 
a buggy sending system/network problem (the sender is a reliable person) 
and not my problem?

Thanks
Marcus

Good Morning,

On Mon, 29 Aug 2011 17:14:28 +0000, Marcus Schopen wrote:
> I started a tcpdump which shows a lot of TCP Retransmission from the
> sending server, while my server is always answering with an ACK:

I analysed the tcpdump a little bit more and it shows that after 2.5 
hours the email is transmitted completely (ending with an ".", checked by 
follow tcpstream in wireshard), but the sendmail or the milter ignore 
this and send a "reject=451 4.3.2 Please try again later". It is strange 
that the sending servers needs up to 120 seconds to respond to an 
immediately ACK and answers with a Retransmission then. But even if the 
whole session takes 2.5 hours and I don't want to wait that long for such 
a small mail to be transmitted, I'd like to know which parameter/option 
is responsible for the timeout on my side. And is this just a strange 
network problem (MTU, firefall on sending side) or possibly my problem (as 
I sayed never seen such an error sind 2000K mails running through this 
system and only caused by this single server).

Ciao,
Marcus

The error message you mentioned usually means the milter has given up
and exited because of a timeout.

If it's taking 2.5 hours for the email to be transmitted, that's probably
the cause.  The suggested INPUT_MAIL_FILTER line for MIMEDefang has a
15-minute timeout.

Regards,

David.

Hi David,

On Wed, 31 Aug 2011 18:23:34 -0400, David F. Skoll wrote:

> The error message you mentioned usually means the milter has given up
> and exited because of a timeout.
> 
> If it's taking 2.5 hours for the email to be transmitted, that's
> probably the cause.  The suggested INPUT_MAIL_FILTER line for MIMEDefang
> has a 15-minute timeout.

Thanks for your answer. Is there a way to stop/close these long 
transmissions earlier on sendmail side, e.g. reject if data isn't 
finished after 30 minutes. Which timeout parameters would be responsible 
for this?

Ciao
Marcus

Marcus Schopen wrote:

> Thanks for your answer. Is there a way to stop/close these long
> transmissions earlier on sendmail side, e.g. reject if data isn't
> finished after 30 minutes. Which timeout parameters would be responsible
> for this?

http://lmgtfy.com/?q=sendmail+data+timeout

Regards,

David.

On Sat, 03 Sep 2011 19:24:51 -0400, David F. Skoll wrote:

> Marcus Schopen wrote:
> 
>> Thanks for your answer. Is there a way to stop/close these long
>> transmissions earlier on sendmail side, e.g. reject if data isn't
>> finished after 30 minutes. Which timeout parameters would be
>> responsible for this?
> 
> http://lmgtfy.com/?q=sendmail+data+timeout

Thanks David.

I already checked the timeout parameters in the bat book, but I don't see 
a parameter which closes the connection, because the DATA part never ends 
because of an network problem and never ending Retransmissions caused by 
the sending host. The sending MX sends DATA packages over hours, but 
never comes to a final ".". My confTO_DATAFINAL is set to 1h by default. 
If that option would fit, why is the communiction open for serveral hours?

sendmail.cf:# open connection cache timeout
sendmail.cf:O ConnectionCacheTimeout=5m
sendmail.cf:# timeouts (many of these)
sendmail.cf:#O Timeout.initial=5m
sendmail.cf:#O Timeout.connect=5m
sendmail.cf:#O Timeout.aconnect=0s
sendmail.cf:O Timeout.iconnect=2m
sendmail.cf:#O Timeout.helo=5m
sendmail.cf:O Timeout.mail=2m
sendmail.cf:#O Timeout.rcpt=1h
sendmail.cf:O Timeout.datainit=2m
sendmail.cf:#O Timeout.datablock=1h
sendmail.cf:#O Timeout.datafinal=1h
sendmail.cf:O Timeout.rset=1m
sendmail.cf:O Timeout.quit=2m
sendmail.cf:#O Timeout.misc=2m
sendmail.cf:O Timeout.command=5m
sendmail.cf:O Timeout.ident=0
sendmail.cf:#O Timeout.fileopen=60s
sendmail.cf:#O Timeout.control=2m
sendmail.cf:O Timeout.queuereturn=5d
sendmail.cf:#O Timeout.queuereturn.normal=5d
sendmail.cf:#O Timeout.queuereturn.urgent=2d
sendmail.cf:#O Timeout.queuereturn.non-urgent=7d
sendmail.cf:#O Timeout.queuereturn.dsn=5d
sendmail.cf:O Timeout.queuewarn=4h
sendmail.cf:#O Timeout.queuewarn.normal=4h
sendmail.cf:#O Timeout.queuewarn.urgent=1h
sendmail.cf:#O Timeout.queuewarn.non-urgent=12h
sendmail.cf:#O Timeout.queuewarn.dsn=4h
sendmail.cf:#O Timeout.hoststatus=30m
sendmail.cf:#O Timeout.resolver.retrans=5s
sendmail.cf:#O Timeout.resolver.retrans.first=5s
sendmail.cf:#O Timeout.resolver.retrans.normal=5s
sendmail.cf:#O Timeout.resolver.retry=4
sendmail.cf:#O Timeout.resolver.retry.first=4
sendmail.cf:#O Timeout.resolver.retry.normal=4
sendmail.cf:#O Timeout.lhlo=2m
sendmail.cf:O Timeout.auth=2m
sendmail.cf:O Timeout.starttls=2m

Thanks
Marcus

Marcus Schopen wrote:

> I already checked the timeout parameters in the bat book, but I don't see
> a parameter which closes the connection, because the DATA part never ends
> because of an network problem and never ending Retransmissions caused by
> the sending host. The sending MX sends DATA packages over hours, but
> never comes to a final ".". My confTO_DATAFINAL is set to 1h by default.
> If that option would fit, why is the communiction open for serveral hours?

You probably want Timeout.datablock set to a short limit (5m or 10m, say).

Regards,

David.

In article <9cjl8tFqt4U1@mid.dfncis.de>,
Marcus Schopen  <lists@localguru.de> wrote:
>On Sat, 03 Sep 2011 19:24:51 -0400, David F. Skoll wrote:
>
>> Marcus Schopen wrote:
>> 
>>> Thanks for your answer. Is there a way to stop/close these long
>>> transmissions earlier on sendmail side, e.g. reject if data isn't
>>> finished after 30 minutes. Which timeout parameters would be
>>> responsible for this?
>> 
>> http://lmgtfy.com/?q=sendmail+data+timeout
>
>Thanks David.
>
>I already checked the timeout parameters in the bat book, but I don't see 
>a parameter which closes the connection, because the DATA part never ends 
>because of an network problem and never ending Retransmissions caused by 
>the sending host. The sending MX sends DATA packages over hours, but 
>never comes to a final ".". My confTO_DATAFINAL is set to 1h by default. 
>If that option would fit, why is the communiction open for serveral hours?
>

** the line below waits for up to an hour *between* data blocks.

>sendmail.cf:#O Timeout.datablock=1h

** the line below waits for up to an hour *after* the last data block.
   (i.e., after receiving the block with the '\r\n.\r\n' EOF marker in it
    and sending the response code - e.g. '200 mail accepted for delivery')

>sendmail.cf:#O Timeout.datafinal=1h

>
Re-transmitted packets are handled at a level below the actual sendmail code,
so sendmail doesn't see them. So, adjusting the 'datablock' timeout to a
'much' smaller value should cause those connections to drop.