|
|
You're in the
iis smtp nntp
group:Configuring SMTP in IIS 6.0 Questions
iis smtp nntp:
Hello,
I am trying to configure SMTP for outbound connections to the rest of the world from a Windows 2003 server running IIS 6.0 and I have installed SMTP and set up an SMTP virtual server that is all unassigned as far as its IP address is concerned. I am finding that the SMTP server is accepting emails on port 25, however, and I see them in the drop folder under Inetpub, however, they are never making the outbound connection as per the SMTP logs. I see some reference in previous posts to a PTR record, but I need more clarification on this. Is this the PTR record on my public DNS for this IP address? What should the PTR point to name wise? Please advise. Thanks -- __________________________ Richard Young, SBSC, CNE http://www.relyonit.com
[quoted text, click to view]
> I am trying to configure SMTP for outbound connections to the rest > of the world from a Windows 2003 server running IIS 6.0 and I have > installed SMTP and set up an SMTP virtual server that is all > unassigned as far as its IP address is concerned. OK; as long as you have not configured any other non-default settings that you have not documented here, you now have an SMTP server that will relay authenticated submissions to its Remote domains -- provided it is using properly functioning DNS servers, of course -- and which will deliver all submissions to its Local domains. [quoted text, click to view] > I am finding that the SMTP server is accepting emails on port 25, > however, and I see them in the drop folder under Inetpub, however, > they are never making the outbound connection as per the SMTP logs. The \Drop folder is for mail to Local domains: domains whose user mailboxes (primitive though it may appear, \Drop is essentially a mailbox store) are on-box. In contrast, Remote domains have their mailboxes off-box. So the messages in \Drop aren't supposed to go anywhere! The question is why they are being deposited there in the first place. It is likely that you set up the your mailbox domain as the Default Local domain. That won't do if the mailbox server is actually elsewhere. It must be a Remote domain, the off-box mailbox server set in the domain properties. [quoted text, click to view] > I see some reference in previous posts to a PTR record, but I need > more clarification on this. Is this the PTR record on my public DNS > for this IP address? What should the PTR point to name wise? In the reverse DNS zone for your netblock (which of course is public), your mailserver's public IP address must have a PTR entry that resolves to the HELO hostname it uses when making outbound connections. This hostname is the VS' fully qualified host name. In your domain's forward DNS zone, there must in turn be an A record that resolves that hostname back to your public IP. That completes the "roundtrip" of PTR-HELO-A necessary to ensure the highest rate of remote delivery. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc.
So the messages in \Drop aren't supposed to go anywhere! The question
[quoted text, click to view] > is why they are being deposited there in the first place. It is likely > that you set up the your mailbox domain as the Default Local domain. > That won't do if the mailbox server is actually elsewhere. It must be > a Remote domain, the off-box mailbox server set in the domain > properties. So I have one domain defined. Let's call this domain.com. The test emails are to the same domain and are placing all emails in the drop folder as you mention. Do I need to delete this domain and add a wildcard domain for remote email delivery as I want all emails that hit this SMTP server to make outbound SMTP connections to the appropriate domain based on the SMTP TO address. Also when I highlight a domain I don't see a way to delete it and I don't see a way to add a "*" domain for all other domains. How do I configure this SMTP virtual server to deliver all remote email to remote domains? Thanks. -- __________________________ Richard Young, SBSC, CNE http://www.relyonit.com [quoted text, click to view] "Sanford Whiteman" wrote:
> > I am trying to configure SMTP for outbound connections to the rest > > of the world from a Windows 2003 server running IIS 6.0 and I have > > installed SMTP and set up an SMTP virtual server that is all > > unassigned as far as its IP address is concerned. > > OK; as long as you have not configured any other non-default settings > that you have not documented here, you now have an SMTP server that > will relay authenticated submissions to its Remote domains -- provided > it is using properly functioning DNS servers, of course -- and which > will deliver all submissions to its Local domains. > > > I am finding that the SMTP server is accepting emails on port 25, > > however, and I see them in the drop folder under Inetpub, however, > > they are never making the outbound connection as per the SMTP logs. > > The \Drop folder is for mail to Local domains: domains whose user > mailboxes (primitive though it may appear, \Drop is essentially a > mailbox store) are on-box. > > In contrast, Remote domains have their mailboxes off-box. > > So the messages in \Drop aren't supposed to go anywhere! The question > is why they are being deposited there in the first place. It is likely > that you set up the your mailbox domain as the Default Local domain. > That won't do if the mailbox server is actually elsewhere. It must be > a Remote domain, the off-box mailbox server set in the domain > properties. > > > I see some reference in previous posts to a PTR record, but I need > > more clarification on this. Is this the PTR record on my public DNS > > for this IP address? What should the PTR point to name wise? > > In the reverse DNS zone for your netblock (which of course is public), > your mailserver's public IP address must have a PTR entry that > resolves to the HELO hostname it uses when making outbound > connections. This hostname is the VS' fully qualified host name. > > In your domain's forward DNS zone, there must in turn be an A record > that resolves that hostname back to your public IP. That completes the > "roundtrip" of PTR-HELO-A necessary to ensure the highest rate of > remote delivery. > > --Sandy > > > > > ------------------------------------ > Sanford Whiteman, Chief Technologist > Broadleaf Systems, a division of > Cypress Integrated Systems, Inc. > ------------------------------------
I found the problem.
The domain name of the SMTP virtual server did not resolve or match the DNS. I see outbound SMTP connections now and it seems to be working. So it seems that the internal smtp virutal server fqdn needs to match the DNS A record and PTR. Right now the name is like server1 and when it finds a domain that is different it knows to deliver remotely. So let's throw a wrench in the fire and clarify something here. If this same IIS SMTP virtual server is hosted at a colo and the server name is billing and the SMTP server name is billing, I'm confused on how to configure if the domain at the colo is the same as the domain at our coroporate exchange server. So, for example if my exchange server has a FDQN of mail.domain.com and points to an IP address ending in 199 and my colo server running IIS SMTP has a FQDN of billing.domain.com and has a public IP ending in 200 how do I configure the IIS SMTP domain name so that it knows to deliver all email for domain.com to the exchange server at IP 200 given that it shares the same domain name? Do I have to create an alias? or ?? Please advise. Thanks. -- __________________________ Richard Young, SBSC, CNE http://www.relyonit.com [quoted text, click to view] "Sanford Whiteman" wrote:
> > I am trying to configure SMTP for outbound connections to the rest > > of the world from a Windows 2003 server running IIS 6.0 and I have > > installed SMTP and set up an SMTP virtual server that is all > > unassigned as far as its IP address is concerned. > > OK; as long as you have not configured any other non-default settings > that you have not documented here, you now have an SMTP server that > will relay authenticated submissions to its Remote domains -- provided > it is using properly functioning DNS servers, of course -- and which > will deliver all submissions to its Local domains. > > > I am finding that the SMTP server is accepting emails on port 25, > > however, and I see them in the drop folder under Inetpub, however, > > they are never making the outbound connection as per the SMTP logs. > > The \Drop folder is for mail to Local domains: domains whose user > mailboxes (primitive though it may appear, \Drop is essentially a > mailbox store) are on-box. > > In contrast, Remote domains have their mailboxes off-box. > > So the messages in \Drop aren't supposed to go anywhere! The question > is why they are being deposited there in the first place. It is likely > that you set up the your mailbox domain as the Default Local domain. > That won't do if the mailbox server is actually elsewhere. It must be > a Remote domain, the off-box mailbox server set in the domain > properties. > > > I see some reference in previous posts to a PTR record, but I need > > more clarification on this. Is this the PTR record on my public DNS > > for this IP address? What should the PTR point to name wise? > > In the reverse DNS zone for your netblock (which of course is public), > your mailserver's public IP address must have a PTR entry that > resolves to the HELO hostname it uses when making outbound > connections. This hostname is the VS' fully qualified host name. > > In your domain's forward DNS zone, there must in turn be an A record > that resolves that hostname back to your public IP. That completes the > "roundtrip" of PTR-HELO-A necessary to ensure the highest rate of > remote delivery. > > --Sandy > > > > > ------------------------------------ > Sanford Whiteman, Chief Technologist > Broadleaf Systems, a division of > Cypress Integrated Systems, Inc. > ------------------------------------
[quoted text, click to view]
> So it seems that the internal smtp virutal server fqdn needs to > match the DNS A record and PTR. That is required for the PTR-HELO-A roundtrip, yes, but it is _not_ required to make every single outbound delivery. The roundtrip gives you delivery insurance, cooperating with remote anti-spam measures. But when a server does not employ those measures, you can still deliver. I don't want to devalue it in any context, since it is so vital, but the fact is that no MTA vendor that I know of enforces it within a single-server setup. It is left to the admin to know how to negotiate forward and reverse DNS properly for remote servers. [quoted text, click to view] > Right now the name is like server1 and when it finds a domain that > is different it knows to deliver remotely. 'server1' is an invalid, non-RFC host name, so it should not be used. You must use a valid FQHN at a public domain. [quoted text, click to view] > So let's throw a wrench in the fire and clarify something here. If > this same IIS SMTP virtual server is hosted at a colo and the server > name is billing and the SMTP server name is billing, I'm confused on > how to configure if the domain at the colo is the same as the domain > at our coroporate exchange server. Very simple. Such setups exist at least by the tens of thousands. The VS has the FQHN billing.example.com. The Local (Default) domain is billing.example.com. There is a Remote domain 'example.com' that has its 'Allow incoming mail to be relayed to this domain' checkbox checked. The radio button 'Forward all mail to smart host' is checked, and the hostname 'exchange.example.com' is entered in the textbox. N.B. at the VS level, do not allow relaying for everyone. This makes you an open relay. You may allow relaying for authenticated sessions and/or sessions from certain IP subnets, _plus_ you allow anonymous sessions to relay only to your known Remote domains by using the checkbox noted above. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc.
[quoted text, click to view]
> So I have one domain defined. Let's call this domain.com. The test > emails are to the same domain and are placing all emails in the drop > folder as you mention. Yep, appropriate behavior. [quoted text, click to view] > How do I configure this SMTP virtual server to deliver all remote > email to remote domains? As I mentioned in my most recent post, if you want to relay for unknown remote domains, then you do this by relaying only mail that has been submitted in authenticated sessions or from certain IP ranges. You don't relay _to_ unknown remote domains, _from_ unknown (anonymous) submissions. That unknown-to-unknown setup is called an open relay. Note that you do not need to have a literal 'Remote domain' entered into IIS for _every_ remote domain you're going to relay to... if you did, well, you obviously could relay to "unknown" ones, couldja? There is an implicit * wildcard in place for any domain [a] to which relay is allowed (through authenticated submission or submission from allowed IPs) and [b] for which there is no 'Remote Domain' entry. The only domains that need a 'Remote domain' entry are those for which DNS-based (MX-record-based) delivery would be inefficient or incorrect. - For one example, if the current machine is the sole MX record for a domain, it will receive all mail from the outside for that domain. It obviously can't use DNS to route to the true mailbox server for the domain, because DNS only knows of the MX: loopback conditions ensue. You need a Remote domain in this case. - For another example, if the current machine is a webserver relaying mail from form submissions or suchlike, doesn't appear in the MX records for any domains, and is on a datacenter subnet that doesn't have any mailbox servers on it, then it can relay to any domain using standard DNS and doesn't need any hard-coded Remote domains. - For a third example, if the current machine is a webserver that doesn't appear in the MX records for any domains, _but_ (as hinted above) is on the same private IP subnet as a mailbox server for one or more domains _and_ can't reach those servers using their public IPs (most enterprise firewalls won't allow this 'loopback NAT', though some SMB firewalls will), then you will need to have Remote domains for those mailbox servers. The Remote domains will be are smart-hosted to send straight to the private IP (or to a hostname that resolves to the private IP). --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc.
[quoted text, click to view] "Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> wrote in message news:op.tzuert1x6c17zw@gw02.broadleaf.local... > > So it seems that the internal smtp virutal server fqdn needs to > > match the DNS A record and PTR. > > That is required for the PTR-HELO-A roundtrip, yes, but it is _not_ > required to make every single outbound delivery. > > The roundtrip gives you delivery insurance, cooperating with remote > anti-spam measures. But when a server does not employ those measures, > you can still deliver. I don't want to devalue it in any context, > since it is so vital, but the fact is that no MTA vendor that I know > of enforces it within a single-server setup. It is left to the admin > to know how to negotiate forward and reverse DNS properly for remote > servers. > > > Right now the name is like server1 and when it finds a domain that > > is different it knows to deliver remotely. > > 'server1' is an invalid, non-RFC host name, so it should not be used. > > You must use a valid FQHN at a public domain. > > > So let's throw a wrench in the fire and clarify something here. If > > this same IIS SMTP virtual server is hosted at a colo and the server > > name is billing and the SMTP server name is billing, I'm confused on > > how to configure if the domain at the colo is the same as the domain > > at our coroporate exchange server. > > Very simple. Such setups exist at least by the tens of thousands. > > The VS has the FQHN billing.example.com. > > The Local (Default) domain is billing.example.com. > > There is a Remote domain 'example.com' that has its 'Allow incoming > mail to be relayed to this domain' checkbox checked. The radio button > 'Forward all mail to smart host' is checked, and the hostname > 'exchange.example.com' is entered in the textbox. > > N.B. at the VS level, do not allow relaying for everyone. This makes > you an open relay. You may allow relaying for authenticated sessions > and/or sessions from certain IP subnets, _plus_ you allow anonymous > sessions to relay only to your known Remote domains by using the > checkbox noted above. > > --Sandy > > > ------------------------------------ > Sanford Whiteman, Chief Technologist > Broadleaf Systems, a division of > Cypress Integrated Systems, Inc. > ------------------------------------
Yep, I'm listening... something on your mind? :)
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |