wrote:

>Hi;
>
>I called PSS and got this fixed - but I don't know why this is
>necessary.
>
>I had to add a second domain to the SMTP server, one named
>windward.net (name of our domain). I then set it to forward all mail
>to smart host [123.123.123.123] (fake IP - showing that the [] is
>needed).
>
>As to why this is needed - no idea.
>
>thanks - dave
>
>david@at-at-at@windward.dot.dot.net
>Windward Reports -- http://www.WindwardReports.com
>me -- http://dave.thielen.com

>Ok, here is what I think is happening (thank you to a MS PSS tech for
>this). I entered maail.windward.net as the FQDN for the SMTP server so
>when it sends mail, reverse DNS checks will work.

>However, that entry also tells the SMTP server who it is and therefore
>any mail to windward.net it won't send because it is windward.net.

>I think that field in the properties should be split in to two fields.

<sandy@cypressintegrated.com> wrote:

>>Ok, here is what I think is happening (thank you to a MS PSS tech for
>>this). I entered maail.windward.net as the FQDN for the SMTP server so
>>when it sends mail, reverse DNS checks will work.
>
>The only reason this would be necessary is if both your IIS and
>Exchange boxes are getting NATted to the same public IP, and your
>firewall can't handle any other setup.
>
>IF the above is true, what you've done is sensible. The canonical
>name of the server's public IP is mail.example.com, so that's what you
>want it to answer with (220 hostname) and what you want to announce
>itself as (EHLO/HELO hostname). It's also the hostname you have as
>the PTR for that server's public IP. IMO, if your firewall is truly
>this broken, there is absolutely no reason to alter the IIS behavior,
>or to expect any other options to exist. The more round-trip-safe
>your setup, the more likely it is that you will be able to send mail
>to the outside world. If you want more flexibility, that should come
>from your firewall.
>
>If the first paragraph above is NOT true, then there was no reason not
>to give your IIS box its own canonical hostname and standardize your
>PTR, A, 220 and EHLO against that hostname.
>
>>However, that entry also tells the SMTP server who it is and therefore
>>any mail to windward.net it won't send because it is windward.net.
>
>Yes, if you call the machine mail.example.com, and the MX record
>specifies mail.example.com as the MX for your domain, then the
>resolution of this name will take place locally. And it absolutely
>should, even if you don't think of the SMTP settings as being as
>"intimate" with _themselves_ as the SMTP settings are with HOSTS and
>DNS.
>
>The same would be true if the Windows name of the machine were
>mail.example.com, even if the IIS SMTP FQDN setting were not (the
>Windows name is used by default in this field, with good reason, since
>it forces some amount of uniqueness). In both cases, you're choosing
>to say that the machine _is_ host <hostname> at a hard-coded level,
>overriding remote DNS resolution, at least within the context of IIS.
>So to get mail off the box, you need to override this at another
>hard-coded level that takes precedence: the hard-coded Remote Domain.
>
>Since you hadn't mentioned that you were calling this machine by
>another machine's name (the very name of the machine you were
>expecting it to find off-box), it's natural that we weren't able to
>get to the meat of the problem.
>
>>I think that field in the properties should be split in to two fields.
>
>I don't think so at all. As I note above, you want your system to be
>as round-trip-safe as possible to/from the outside, meaning as few
>"one-off" settings as possible. Introducing additional bells and
>whistles will just make your setup harder to manage. So, if you're
>ready to call the machine mail.example.com, you must assume that
>subsequent behavior on that box will "believe" this setting and call
>the machine by that name. There's _nothing_ that says the FQDN is
>cosmetic; rather, the IIS documentation introduces the setting as
>"involved in the processing of MX records." Which indeed it is!
>
>Furthermore, the method of forcing off-box mailrouting is quite
>simple, as you have seen: a Remote Domain. This is the method used by
>anyone running a dedicated IIS MX in front of an Exchange box to
>prevent DNS loop conditions. Since you're not using this machine as
>an MX, you normally wouldn't have had any such looping worries. I'm
>thus interested to find the answer to my very first query above, that
>is: why did you need to have this machine impersonate the other
>machine's canonical hostname?
>
>--Sandy

>I put mail.windward.net as the FQDN because of posts in this NG saying
>that was necessary so spam filters do not throw away messages as they
>would be coming from a box that is not a MX record for us.

>Our topology is that the IIS SMTP server box is outside our firewall
>(going to a co-lo facility soon) while our exchange box is inside our
>firewall. So they have distinct IP addresses.

>Do I not need to set the FQDN? Or is that necessary as the box has an
>IP address that is not in our MX.

<sandy@cypressintegrated.com> wrote:

>>I put mail.windward.net as the FQDN because of posts in this NG saying
>>that was necessary so spam filters do not throw away messages as they
>>would be coming from a box that is not a MX record for us.
>
>That was a pretty nonsensical suggestion. There is no requirement --
>zip, nada -- that messages from your domain originate from a published
>MX from your domain! The only time a similar restriction exists is
>when _you_ deliberately publish a policy, using SPF for example, that
>instructs those remote machines that check SPF records to reject mail
>that does not originate from a specified collection of senders.
>
>Furthermore, setting your mailserver, which is on a different IP with
>(presumably) its own PTR entry or no PTR entry at all, to impersonate
>another IP's canonical name is _more_ likely to cause rejections
>because you fail the PTR/A roundtrip check. What you want is
>simplicity and circularity. The mailserver IP's PTR --> the A record
>for that PTR --> the IP your of your mailserver.
>
>>Our topology is that the IIS SMTP server box is outside our firewall
>>(going to a co-lo facility soon) while our exchange box is inside our
>>firewall. So they have distinct IP addresses.
>
>Then they should also have distinct PTRs, and thus different FQDNs.
>
>>Do I not need to set the FQDN? Or is that necessary as the box has an
>>IP address that is not in our MX.
>
>As above, being an MX is not a requirement to originate mail. Passing
>a DNS roundtrip check _is_ a requirement.
>
>--Sandy
>

>Ok, I set the FQDN to the name of the box it is on and it seems to be
>running fine. I guess if this is a spam issue we'll hear soon that
>people are not receiving their email.

<sandy@cypressintegrated.com> wrote:

>>Ok, I set the FQDN to the name of the box it is on and it seems to be
>>running fine. I guess if this is a spam issue we'll hear soon that
>>people are not receiving their email.
>
>If the PTR-A-IP roundtrip checks out for this server, there are no
>other issues to worry about (well, except for the completely separate
>issues of actually sending spam, or sharing a netblock with a
>spammer).
>
>Trust me. Ever hear of an outbound SMTP gateway? That's a box used
>only to send mail. It does not accept mail for the domain, and in
>kind is not a published MX for the domain. Every large provider or
>corporation uses such boxes, and many small companies do as well.
>
>--Sandy

>Do I still need a domain in SMTP for my domain? Or will it find my
>mail server fine now that my SMTP server has a different name?