From: dogbert (no email)
Date: Fri Dec 02 2005 - 09:32:11 EST
Wietse Venema wrote:
> dogbert:
>>> If the text does not end on "<CR><LF>.<CR><LF>" then it does not
>>> comply with SMTP.
>>>
>>> Can I have a copy of the UNENCODED recording of a session that
>>> fails with "timeout after DATA".
>>>
>>> Can I have a copy of the logging that corresponds to that failed
>>> delivery.
>>>
>>> Wietse
>> I've used tcpdump to gather a plain binary snapshot of the tcpip session. You
>> will find it attached to this e-mail.
>>
>> Here is the corresponding log of the transaction:
>
> The time stamps in the recording are 14 minutes 8 seconds after
> the hour, and the logging is 15 minutes 36 seconds, but it does
> not matter. This recording shows all the symptoms that I needed.
>
Only because I took a different log track, I was unable to find the original one
and eventually every log reported the same errors.
>> Dec 2 08:15:36 derlnx-antispam postfix/smtpd[28439]: connect from
>> dddddddddddd.dddddd.aaa-aaa.it[192.168.40.33]
>> Dec 2 08:15:36 derlnx-antispam postfix/smtpd[28439]: discarding EHLO keywords:
>> PIPELINING
>> Dec 2 08:15:36 derlnx-antispam postfix/smtpd[28439]: AB5E038003:
>> client=dddddddddddd.dddddd.aaa-aaa.it[192.168.40.33]
>> Dec 2 08:20:36 derlnx-antispam postfix/smtpd[28439]: timeout after DATA from
>> dddddddddddd.dddddd.aaa-aaa.it[192.168.40.33]
>> Dec 2 08:20:36 derlnx-antispam postfix/smtpd[28439]: disconnect from
>> dddddddddddd.dddddd.aaa-aaa.it[192.168.40.33]
>>
>> If the problem is the total absence of "<CR><LF>.<CR><LF>" how can I resolve it
>> ? I don't like the solution "Don't use postfix". I'd like to understand if this
>> problem is a common issue also with mail server from internet or if it's limited
>> to a few servers.
>
> SMTP mail must end in "<CR><LF>.<CR><LF>".
>
> If it does not, all SMTP servers will have problems, not just Postfix.
>
Actually the first mail relay is working in my infrastructure and it's not
giving me a lot of problems. Maybe oll of my mail servers accept a less strictly
implementation of SMTP while Postfix stick to the RFC (it's not a bad thing).
> Running ethereal on your file shows your claim about EOM is inaccurate.
>
> ethereal sees no end of message, because no "<CR><LF>.<CR><LF>" was sent.
>
> Wietse
>
> 1 11:14:08.407158 192.168.40.33 -> 192.168.40.34 TCP 2447 > smtp [SYN] Seq=0 Ack=0 Win=64240 Len=0 MSS=1460
> 2 11:14:08.407304 192.168.40.34 -> 192.168.40.33 TCP smtp > 2447 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
> 3 11:14:08.407503 192.168.40.33 -> 192.168.40.34 TCP 2447 > smtp [ACK] Seq=1 Ack=1 Win=64240 Len=0
> 4 11:14:08.419630 192.168.40.34 -> 192.168.40.33 SMTP Response: 220 mailfilter.aaaaaaa.it
> 5 11:14:08.421914 192.168.40.33 -> 192.168.40.34 SMTP Command: EHLO mail1.aaaaaaa.it
> 6 11:14:08.421957 192.168.40.34 -> 192.168.40.33 TCP smtp > 2447 [ACK] Seq=28 Ack=24 Win=5840 Len=0
> 7 11:14:08.422363 192.168.40.34 -> 192.168.40.33 SMTP Response: 250-derlnx-antispam.dddddd.aaa-aaa.it
> 8 11:14:08.425494 192.168.40.33 -> 192.168.40.34 SMTP Command: MAIL FROM: <> SIZE=753
> 9 11:14:08.426345 192.168.40.34 -> 192.168.40.33 SMTP Response: 250 Ok
> 10 11:14:08.427694 192.168.40.33 -> 192.168.40.34 SMTP Command: RCPT TO: <>
> 11 11:14:08.438597 192.168.40.34 -> 192.168.40.33 SMTP Response: 250 Ok
> 12 11:14:08.440710 192.168.40.33 -> 192.168.40.34 SMTP Command: DATA
> 13 11:14:08.440949 192.168.40.34 -> 192.168.40.33 SMTP Response: 354 End data with <CR><LF>.<CR><LF>
> 14 11:14:08.441396 192.168.40.33 -> 192.168.40.34 SMTP Message Body
> 15 11:14:08.478940 192.168.40.34 -> 192.168.40.33 TCP smtp > 2447 [ACK] Seq=175 Ack=697 Win=6996 Len=0
>
> Note that ethereal reports no EOM, because there is no <CR><LF>.<CR><LF>.
>
I'm sending you another packet dump taken with ethereal from a third machine
inside the network while the one I sent you last time is taken with tcpdump
directly from the postfix server.
Opening it with Ethereal I can see a packet marked EOM:.
Regards,
Riccardo
|
|
|