Mail delivery wierdness

[Ryan Thompson]

keith at smmc.qld.edu.au wrote to ryan at sasknow.com:

> Hi Ryan...

Hi Keith,

> Yep I can confirm it was NOT listening on :25
> The techie on the ground swore black & blue it was (always follow what you
> know!). I figured it wasn't but maybe it was somethjing I didn't
> understand?? He changed the config on exchange and voila! Now I can chat
> with smtp on the mail server from outside!

:-)

> Next question.  Squid is also on the gateway/firewall.

Squid has nothing to do with SMTP.

> Mail is still not being delivered.

What do you mean? Messages are being accepted for delivery, but are not
arriving (indicating a problem with the innards of the Exchange config)?
Or the SMTP sessions themselves are not completing? Be specific. Send
actual output, where possible.

> Can I assume if I can chat via telnet to the exchange server : 25 Then
> mail can also get thru?

Unless something really funny is happening, you've ruled out connection
and firewall issues. See below, though. You definitely *haven't* ruled
out SMTP issues, which is why you should verify the config of the
Exchange server before you go any further. You've already confirmed one
bug. Until you can deliver messages on the server itself, you won't
learn much more by trying from other hosts.

> Surely that means a persistent session is set up and mail should also
> get to it.

Actually, it means that you have an application-layer connection, in
this case, over TCP. So far, no guarantees (or even promises) have been
made by the server about mail delivery. At least, if you received any,
you didn't include them in your message. :-)

> It isn't being delivered to mailboxes there so what the???

You mean *when* you use telnet to manually negotiate the SMTP session?
Or are you assuming that, if you get any SMTP response, that other MUAs
will behave correctly with the server, and that the server will behave
predictably with the request? Output from a telnet session can be very
enlightening, and easier to get than tcpdump output, for text-based
protocols. :-)

>From your gateway, try a complete SMTP session, including delivery, with
appropriate MAIL FROM, RCPT TO and header information. If SMTP isn't a
second language to you, here's a real example. Lines beginning with (a
decorative!) + indicate lines of actual input:

    $ telnet earl 25
    Trying 207.195.92.130...
    Connected to earl.sasknow.net.
    Escape character is '^]'.
    220 earl.sasknow.net ESMTP Sendmail 8.12.6p2/8.12.6; Mon, 21 Jul 2003
    21:55:45 -0600 (CST)
  + HELO stimpy.sasknow.com
    250 stimpy.sasknow.com Hello stimpy [207.195.92.132], pleased to meet you
  + MAIL FROM: ryan at sasknow.com
    250 2.1.0 ryan at sasknow.com... Sender ok
  + RCPT TO: ryan at sasknow.com
    250 2.1.5 ryan at sasknow.com... Recipient ok
  + DATA
    354 Enter mail, end with "." on a line by itself
  + From: ryan at sasknow.com
  + To: ryan at sasknow.com
  + Subject: Test message #1
  +
  + THis is a test.
  + .
    250 2.0.0 h6M3tjQA009987 Message accepted for delivery
  + QUIT
    221 2.0.0 earl.sasknow.net closing connection
    Connection closed by foreign host.

A second or so later, this message was delivered to my local mailbox
(capitalization typo and all) on another inner server, indicating that
things worked fine. Headers added by the server confirmed the HELO and
envelope information.

If you receive anything other than 2xx replies from the first three
lines (HELO, MAIL FROM, RCPT TO), it may indicate that you've supplied
information that the server won't allow. (i.e., an invalid relay
address, or maybe it's configured to only accept mail from hosts which
resolve correctly... a potential show-stopper if, for example, you're
using RFC1918 IPs with ipnat and haven't configured Windows to resolve
them fwd+rev. Another good reason *not* to bother with further network
testing until you've successfully delivered mail *on* the mail server in
question through the loopback interface. One step at a time).

If you get the "message accepted for delivery" (or other 2xx code from
Exchange), the message should be delivered. If it isn't, you have more
goofiness to resolve on the Windows server.

If you're not sure of your results, send them to the list. So far, there
isn't much related to FreeBSD, here, but I suppose this is of general
interest to FreeBSD admins... so it is still marginally on-topic for
-questions. :-)

Hope this helps,
- Ryan

-- 
  Ryan Thompson <ryan at sasknow.com>

  SaskNow Technologies - http://www.sasknow.com
  901-1st Avenue North - Saskatoon, SK - S7K 1Y4

        Tel: 306-664-3600   Fax: 306-244-7037   Saskatoon
  Toll-Free: 877-727-5669     (877-SASKNOW)     North America