2008/11/22 Sandy Drobic <suse-linux-e@japantest.homelinux.com>:
Per Jessen wrote:
Medwinz, I know you're trying to be helpful, but do you really think I have not done so already? I have (obviously) checked the log, I'm running full debug on that particular client and I've captured tcpdump for further analysis.
For example some email server restrict the envelope or do reverse checking and unintentionally reject the good email.
In which case I would have a perfectly good SMTP-level error message, and I would have had no reason to start looking at the tcp level data.
From what I saw in the dump your server resent the last "200 2.1.5" message sereval times after the rcpt to. It seems as if the protocol went out of sync.
The one thing you can try is to restrict possible options for the remote system how it can mess up the communication. Try not to offer pipelining to the trouble system. I suspect that the other system doesn't support pipelining correctly.
/etc/postfix/main.cf: smtpd_discard_ehlo_keyword_address_maps = hash:/etc/postfix/dumb_down_idiots
/etc/postfix/dumb_down_idiots: 195.65.248.162 pipelining, silent-discard
If have little hope that you will find a competent admin on the other end if the system uses an internal name for helo.
Good luck!
-- Sandy
Interesting, taking notes :) But, If using pipelining, shouldn't we see something like this?: -------Commands in batch-------- 23:01:13.421803 IP mail.udena.ch.62821 > mxzhh.bluewin.ch.smtp: P 141:432(291) ack 375 win 65535 <nop,nop,timestamp 3247067002 1162153702> 0x0000: 4500 0157 b0ad 4000 4006 efe6 3e0c 83b6 E..W.. at . at ...>... 0x0010: c3ba 1390 f565 0019 c006 5b8c 4e5d b7a6 .....e....[.N].. 0x0020: 8018 ffff 9a56 0000 0101 080a c18a 4f7a .....V........Oz 0x0030: 4545 0ee6 5253 4554 0d0a 4d41 494c 2046 EE..RSET..MAIL.F 0x0040: 524f 4d3a 3c77 6572 6b73 7461 7474 4066 ROM:<xxx at f 0x0050: 656d 6e65 742e 6368 3e20 5349 5a45 3d33 emnet.ch>.SIZE=3 0x0060: 3730 340d 0a52 4350 5420 544f 3a3c 636f 704..RCPT.TO:<co 0x0070: 7269 6e6e 6573 6965 6766 7269 6564 4062 xxx at b 0x0080: 6c75 6577 696e 2e63 683e 0d0a 5243 5054 luewin.ch>..RCPT 0x0090: 2054 4f3a 3c62 7269 6769 7474 652e 686f .TO:<xxx.xx 0x00a0: 6573 6c69 4062 6c75 6577 696e 2e63 683e esli at bluewin.ch> 0x00b0: 0d0a 5243 5054 2054 4f3a 3c77 6172 746f ..RCPT.TO:<xxx 0x00c0: 7474 6940 626c 7565 7769 6e2e 6368 3e0d tti at bluewin.ch>. 0x00d0: 0a52 4350 5420 544f 3a3c 6769 7573 796d .RCPT.TO:<xxxxx 0x00e0: 4062 6c75 6577 696e 2e63 683e 0d0a 5243 at bluewin.ch>..RC 0x00f0: 5054 2054 4f3a 3c73 7461 6c64 6572 2e77 PT.TO:<xxxxxxx.x 0x0100: 6f68 6c65 6e40 626c 7565 7769 6e2e 6368 ohlen at bluewin.ch 0x0110: 3e0d 0a52 4350 5420 544f 3a3c 616d 6475 >..RCPT.TO:<xxxx 0x0120: 6572 7240 626c 7565 7769 6e2e 6368 3e0d xxx at bluewin.ch>. 0x0130: 0a52 4350 5420 544f 3a3c 646f 7269 7368 .RCPT.TO:<xxxxxx 0x0140: 6573 7340 626c 7565 7769 6e2e 6368 3e0d ess at bluewin.ch>. 0x0150: 0a44 4154 410d 0a .DATA.. ------------------------- Instead of seeing ---------------- from_remote > Request 1 your_server > Answer 1 from_remote > Request 2 your_server > Answer 2 .... .. --------------- Maybe there's a broken firewall/NAT setup on the other side? Regards, Ciro
