I agree this is a NAT/DNS prob. Tks for the tips - I'll try them but really was hoping for a courier specific answer.
It's not a courier specific problem. If you really want a courier-specific answer, there may be a fourth option, in addition to those listed in my last message. See the man page for courier(8), and read the section on "esmtproutes".
The issue isn't quite as you expanded upon however - check the logs I originally included again. Courier initiated the connection to send email. The other internal box replied with a SYN/ACK and then my courier box reset the connection!
Respectfully, I don't think you understand how TCP works. A RST packet is generated by the kernel when it receives a packet that's not part of an open connection (at least, that's why you're seeing it). Courier has nothing to do with it. Applications don't generate RST packets.
It looked to me like you were dumping traffic on the machine that was receiving the connection. What you should have seen from the server initiating the connection was:
local ip -> NAT box's public IP: SYN
# The NAT box translates the packet and resends it, you may or
# may not see it from the server initiating the connection, the packet
# looks like:
# local ip -> internal destination: SYN
internal destination -> local ip: SYN/ACK
local ip -> internal destination: RST
See the problem? The return path for the connection doesn't go through the NAT router, so the SYN/ACK packet comes from a different IP address than the courier server sent the SYN to.
The boxes are talking - just my courier box won't play nicely.
I caught that part. You said that the problem occurs because DNS is resolving to the public IP on the NAT box. If that is an accurate description, then you're facing a problem like I described.
> I
think the problem is with my courier box and DNS. I wanted to know if there was a place in Courier that you can configure to overcome the issue of couriertcpd having a brainfart over already having sent a request to the internal server and receiving a reply from it but then rejecting it because it checked the IP address from DNS and its resolving to a different address, and only configure this in a limited fashion to still maintain security.
That's not what's happening at all. The connection is never coming up. If courier were rejecting the connection because of some internal check, the conversation would look like:
A -> B: SYN B -> A: SYN/ACK A -> B: SYN # The connection is up, application does checks, closes connection: A -> B: FIN
Since that's not what you're seeing, you should be looking at making TCP work between the two machines. The easiest fix depends a lot on the equipment in use. If your NAT box is a Linux or BSD server, then I'd put in a rule to forward packets between the internal machines without mangling them before the rules for NAT.
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
