|
Home > Archive > IIS and SMTP > February 2006 > Fixed but no idea why.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Fixed but no idea why.
|
|
| David Thielen 2006-02-20, 8:48 pm |
| 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
| |
| David Thielen 2006-02-20, 8:48 pm |
| 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.
??? - thanks - dave
On Mon, 20 Feb 2006 18:10:45 -0700, David Thielen <david@windward.net>
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
david@at-at-at@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com
| |
| Sanford Whiteman 2006-02-21, 2:49 am |
| >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
| |
| David Thielen 2006-02-21, 5:54 pm |
| Hi;
First off, thank you for the detailed explanation. That makes this a
lot clearer.
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.
thanks - dave
On Tue, 21 Feb 2006 00:26:20 -0500, Sanford Whiteman
<sandy@cypressintegrated.com> wrote:
>
>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.
>
>
>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 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
david@at-at-at@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com
| |
| Sanford Whiteman 2006-02-21, 5:54 pm |
| >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
| |
| David Thielen 2006-02-21, 8:48 pm |
| Hi;
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.
thanks - dave
On Tue, 21 Feb 2006 14:27:47 -0500, Sanford Whiteman
<sandy@cypressintegrated.com> wrote:
>
>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.
>
>
>Then they should also have distinct PTRs, and thus different FQDNs.
>
>
>As above, being an MX is not a requirement to originate mail. Passing
>a DNS roundtrip check _is_ a requirement.
>
>--Sandy
>
david@at-at-at@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com
| |
| Sanford Whiteman 2006-02-22, 2:48 am |
| >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
| |
| David Thielen 2006-02-27, 5:53 pm |
| Hi;
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?
thanks - dave
On Tue, 21 Feb 2006 21:53:27 -0500, Sanford Whiteman
<sandy@cypressintegrated.com> wrote:
>
>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
david@at-at-at@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com
| |
| Sanford Whiteman 2006-02-28, 7:51 am |
| >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?
When mail is destined for a domain, the only records consulted are the
MX and corresponding A records for that exact domain (not parent
domains, not subdomains). There's no "walking the tree" that occurs
in either direction.
Best practice is that you should have an MX record for any domain that
appears on the right-hand side of e-mails generated by your systems.
If you ever send mail from username@smtp.domain.com, smtp.domain.com
should have an MX and corresponding A record. If you don't have an MX
record (that in turn points to an A record, like all MX records) you
still _must_ at least have an A record for smtp.domain.com. (This
latter option, while not encouraged, will work because the SMTP RFCs
specify that in the absence of an MX record, an A record for the
domain is to be used as an "implicit MX" record.)
Either way, the MX/implicit MX _must_ accept incoming connections on
port 25, and _must_ accept mail for every username that may be used to
generate mail.
I hope that gets a little closer to an answer for you.
--Sandy
|
|
|
|
|