puzzled by an inability to communicate with another server

[stfaprc]

I'm so puzzled that I'm not even sure of where is the best place to post this. Our server is 536.582.721.75 and is running RH9. We have one customer who can not get email over to us. The maillog shows:

net sendmail[21611]: k5T6rkD0021611: mail.srek.org [364.365.364.62] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

The firewall had already been setup on 536.582.721.75 to accept anything that comes from 364.365.364.62 , so I did a ethereal capture to see what was going on. The result was:

Frame 52676 (72 bytes on wire, 72 bytes captured)
Arrival Time: Jun 27, 2008 13:38:25.450935000
Time delta from previous packet: 0.120553000 seconds
Time since reference or first frame: 2465.590010000 seconds
Frame Number: 52676
Packet Length: 72 bytes
Capture Length: 72 bytes
Protocols in frame: sll:ip:icmp:ip:tcp
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 1
Link-layer address length: 6
Source: Watchgua_2e:g9:36 (00:90:7f:2e:g9:36)
Protocol: IP (0x0800)
Internet Protocol, Src: 364.365.364.62 (364.365.364.62), Dst: 536.582.721.75 (536.582.721.75)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0x1435 (5173)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 51
Protocol: ICMP (0x01)
Header checksum: 0x71e1 [correct]
Good: True
Bad : False
Source: 364.365.364.62 (364.365.364.62)
Destination: 536.582.721.75 (536.582.721.75)
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)
Checksum: 0x5155 [correct]
Internet Protocol, Src: 536.582.721.75 (536.582.721.75), Dst: 364.365.364.62 (364.365.364.62)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 60
Identification: 0x1aa8 (6824)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 47
Protocol: TCP (0x06)
Header checksum: 0x2f65 [correct]
Good: True
Bad : False
Source: 536.582.721.75 (536.582.721.75)
Destination: 364.365.364.62 (364.365.364.62)
Transmission Control Protocol, Src Port: 51369 (51369), Dst Port: auth (113)
Source port: 51369 (51369)
Destination port: auth (113)

I'm not even sure who is rejecting who
Can someone explain to me what is going (and how to remedy the situation) or which forum would be the best place to ask about this? Thanks.

 

[Annihilannic]

Am I correct in assuming that 536.582.721.75 and 364.365.364.62 are not the real IP addresses, because they are not valid IPs?

Annihilannic.

 

[stfaprc]

yes

 

[Annihilannic]

I'm no sendmail wizard, but if you don't have luck here there is also a sendmail forum on this site.

Annihilannic.

 

[Kozusnik]

Try sending from the command line and see if it throws an error.

http://kangry.com/topics/viewcomment.php?index=427

Mark

 

[bdintegrations]

The connection could be fine. The sending mail server is not configured properly?


Business and Data Integrations

http://www.bdintegrations.com/

A Northern Virginia IT Service and Consulting Company

 

[elgrandeperro]

The port (513) is not what sendmail uses (25). Your side accepeted the connection, so it can't be a blocking issue. But the protocol never started up, so I believe the problem is on their side. Port 514 (ident) is just a protocol to ensure some socket protection, but it is usually blocked, and usually doesn't prevent sending of mail.

It might be a timing issue (on their side). There are usually timeout settings for each phase of the protocol. But in most cases unless the link is really slow, these aren't changed.

 

[stfaprc]

Where are ports 513 and 514 showing in the log listing?

I believe the sender is using an msExchange, and we have been able to receive the email at Yahoo mail.

 

[elgrandeperro]

I'm sorry, I meant port 113/ident. You are just blocking 113 and ICMP-ing back to them port unreachable. As I said, this should only slow down their side a bit. You SHOULD see a connect on port 25 later.

I don't think windows support ident, so I am suspicious that the sender is sending directly from exchange. Some windows guy can verify that.