Chris Buechler wrote:
> On 10/27/05, James W. McKeand <james at mckeand dot biz> wrote:
>> Turned out that at
>> least one sender was trying to bypass the third party email filter by
>> delivering directly to the exchange server (not using the MX records
>> for the domain) they have fixed that issue. I have not heard
>> anything else from them. 
>> 
> 
> Sounds like a case of perception not matching reality, where the
> perception was "NAT is broken" while the reality was the other
> person's mail server was broken.  if it happens again, try to telnet
> to port 24 from the Internet and manually send an email.  Syntax is as
> follows, for the reference of anyone that doesn't know (lines with **
> around them are what you type in, rest is server output):

That was the first thing I tried. 

The first time it happened, the client noticed that expected email was
not coming - more than the direct delivery problem. When I don't get
even a response to the initial connection (i.e. telnet <host> 24) I know
something is amiss. Rebooting the m0n0wall seemed to fix the issue. The
strange thing was that after I did not get a response from the telnet, I
was able to connect via the PPTP and access the WebGUI. If I had
connected via PPTP first I would not of been able telnet to the mail
server - maybe this is a ID 10T issue (Maybe, I did connect to the PPTP
before the telnet test... Don't remember...)

_________________________________
James W. McKeand