|
Home > Archive > IIS and SMTP > June 2007 > Is this a potential problem?
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 |
Is this a potential problem?
|
|
|
| I have a server with IIS SMTP running. I am suspecting that some emails are
not being delivered since I have some events (ID 4000) in my Event log
"Message delivery to the remote domain 'zmail.com' failed for the following
reason: The remote server did not respond to a connection attempt." So far I
have seen this for the following domains: apples.org, zmail.com, cmsdj.info,
xmails.net, hotmail.org, netmail.net
1. I am not using this SMTP server to receive any email just send email
(Form mail on websites both sent to myself, but also to others)
2. I have tested with yahoo and Gmail and users there are receiving email
OK.
3. The server is configured with multiple IPs. The SMTP is set up to receive
on one of these mail.domain.com (X.X.X.2). The sending IP is however not the
same server.domain.com (X.X.X.1) (I don't think you can force IIS SMTP to
send from a specific IP). This causes the following to happen:
Received: from mail.domain.com (server.domain.com [X.X.X.1]) by
mx.google.com
Could that be the reason mail seems to be denied by the servers in question
?
rDNS for X.X.X.1 is correctly set to server.domain.com
rDNS for X.X.X.2 is correctly set to mail.domain.com
MX Records points to a different server that I use to receive mail, but I
have added an entry with a high priority number ala:
(same as parent folder) Mail Exchanger [100] mail.domain.com
Just in case a remote server would be checking if a MX record was in place
for this server.
| |
| Sanford Whiteman 2007-06-23, 7:18 pm |
| > I have a server with IIS SMTP running. I am suspecting that some
> emails are not being delivered since I have some events (ID 4000) in
> my Event log "Message delivery to the remote domain 'zmail.com'
> failed for the following reason: The remote server did not respond
> to a connection attempt."
Your suspicion is correct. However, the Event Log should be only a
pitstop on your way to the real IIS logs. The EL gives a sort of
summary of a bad session; the real, SMTP-level failure will be noted
in the logs.
> 3. The server is configured with multiple IPs. The SMTP is set up to
> receive on one of these mail.domain.com (X.X.X.2). The sending IP is
> however not the same server.domain.com (X.X.X.1)
That can indeed cause delivery problems. It means you fail a full
PTR-A-EHLO-IP roundtrip set of anti-spam tests. Not at all servers are
so rigorous with these tests, which explains the interleaved failures
and successes (though without your logs, it's impossible to say this
is firmly _the_ reason).
> (I don't think you can force IIS SMTP to send from a specific IP).
The source IP will be the primary IP of a NIC, yes.
The bottom line is that you need to worry about outbound delivery
first and foremost, not inbound connections to your MX. So if a
virtual server is going to make deliveries from a given source IP, it
needs to have its HELO/EHLO (FQDN in IIS) match *that* IP's PTR, not
the PTR of an IP the receiving public will never see.
That will naturally change the hostname shown in the response to
inbound connections as well, but that's in practice a non-issue.
> I have added an entry with a high priority number ala: (same as
> parent folder) Mail Exchanger [100] mail.domain.com Just in case a
> remote server would be checking if a MX record was in place for this
> server.
There is no reason whatsoever to do this. HELO/EHLO hostnames of
outbound connections do not need to have MX records. (Note this
applies whether or not the same virtual server also accepts inbound
mail for a set of domains. You need MX records for the _domains_ that
receive mail.) All you've done is cluttered your DNS zone with
non-responsive servers.
--Sandy
| |
|
|
"Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> skrev i
en meddelelse news:op.tueba8q76c17zw@gw02.broadleaf.local...
>
> There is no reason whatsoever to do this. HELO/EHLO hostnames of
> outbound connections do not need to have MX records. (Note this
> applies whether or not the same virtual server also accepts inbound
> mail for a set of domains. You need MX records for the _domains_ that
> receive mail.) All you've done is cluttered your DNS zone with
> non-responsive servers.
>
> --Sandy
Hi Sandy
According to the following:
http://www.saas.nsw.edu.au/solutions/dns.html
Some servers will check these to validate the SMTP server they are talking
to. Is your take on this that this is incorrect?
| |
| Sanford Whiteman 2007-06-24, 7:21 am |
| > Some servers will check these to validate the SMTP server they are
> talking to. Is your take on this that this is incorrect?
The HELO/EHLO hostname of a server that performs direct delivery for a
range of domains is not required to accept mail -- neither must there
be a DNS MX RR for the HELO/EHLO hostname that would allow mail to
user@hostname to be routed to a separate box, nor must the server be
open on port 25 for direct inbound connections.
However, the HELO/EHLO hostname *is* required to exist on the public
Net: it must be a canonical hostname published in an A record in a
public zone. As mentioned before, you need to pass the PTR-A-EHLO-IP
roundtrip suite of tests. Having a fully-qualified HELO/EHLO, with an
A pointing back to the source IP, is part of passing.
[Note that, because SMTP's delivery algorithm states that an A record
will be used in the absence of an MX record ("implied MX") the fact
that you must have A record for the HELO/EHLO hostname *does*
secondarily imply that you are publishing a possible mailroute for
user@hostname. However, you are no more obligated to honor this
mailroute than you are for web servers, FTP servers, or any other
machine with an A record.]
To explain further, using a machine for direct remote delivery does
not imply that the hostname _of that machine_ has any mailboxes
associated with it. If I have outbound1.example.com,
outbound2.example.com, etc. as my array of delivery boxes, it does not
follow that I have accounts such as abuse@outbound2.example.com,
postmaster@outbound1.example.com; on the other hand, if my boxes send
MAIL FROM username@example1.com, username@example2.com, then it does
follow that example1.com and example2.com have explicit MX record(s)
published, and that *all* of the MXs accept mail to *all* usernames at
those domains that may ever appear in a MAIL FROM, and that there is a
good-faith effort to have all MXs accessible on the public Net at all
times other than system failure.
In any case, the page you're referring to mentions, under checks
performed on the HELO/EHLO hostname, that a DNS A *or* MX record (in
that order) must be found for the hostname. The A record is obviously
a requirement, as I mention above. Secondarily accepting an MX record
_instead_ of the A record is actually *less* strict than requiring the
A.
--Sandy
| |
|
| Ok,
1. Will it be a problem if I disallow connections by other IPs than my own
range under Access-Connection?
2. If emails sent from my SMTP server has a different domain in Mail From
than the one associated with the SMTP server could that be a problem?
| |
|
|
"Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> skrev i
en meddelelse news:op.tue4r4b86c17zw@gw02.broadleaf.local...
> To explain further, using a machine for direct remote delivery does
> not imply that the hostname _of that machine_ has any mailboxes
> associated with it. If I have outbound1.example.com,
> outbound2.example.com, etc. as my array of delivery boxes, it does not
> follow that I have accounts such as abuse@outbound2.example.com,
> postmaster@outbound1.example.com; on the other hand, if my boxes send
> MAIL FROM username@example1.com, username@example2.com, then it does
> follow that example1.com and example2.com have explicit MX record(s)
> published, and that *all* of the MXs accept mail to *all* usernames at
> those domains that may ever appear in a MAIL FROM, and that there is a
> good-faith effort to have all MXs accessible on the public Net at all
> times other than system failure.
Why is it when I send mail from an SMTP server with IP X.X.X.1 any bounced
mail will be returned to IP X.X.X.1 even when there are other MX records
with lower number - hence they should be the ones receiving the bounced
mail?
| |
| Sanford Whiteman 2007-06-24, 7:24 pm |
| > Why is it when I send mail from an SMTP server with IP X.X.X.1 any
> bounced mail will be returned to IP X.X.X.1 even when there are other MX
> records
> with lower number - hence they should be the ones receiving the bounced
> mail?
Bounced or *rejected*?
There is no preference given to the original submitting server's IP when
returning a DSN to username@domain.
--Sandy
| |
| Sanford Whiteman 2007-06-24, 7:24 pm |
| > 1. Will it be a problem if I disallow connections by other IPs than my
> own
> range under Access-Connection?
I would do it at the firewall, not at the app level, but they are
essentially the same.
> 2. If emails sent from my SMTP server has a different domain in Mail From
> than the one associated with the SMTP server could that be a problem?
No. Outbound gateways can deliver mail for a range of envelope sender
domains. What is important is that both the outbound server and the
sender domain be set up correctly. The only place the two sides are
*directly* interdependent is in the SPF record (the domain must allow the
server to send mail on its behalf); otherwise, they must both use
independent best practices. DNSStuff.com and DNSReport.com give you some
health checks for each side.
Also, you should stop thinking of "the [domain] associated with the SMTP
server." The outbound-only SMTP server is linked to a _hostname_ (the
HELO/EHLO), but it is best not to think of this FQHN as also being the
origin of an FQDN.
--Sandy
| |
|
| Lines: 13
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
NNTP-Posting-Host: 50a1b25b.flatrate.dk 80.161.178.91
Xref: leafnode.mcse.ms microsoft.public.inetserver.iis.smtp_nntp:718
"Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> skrev i
en meddelelse news:op.tuf1e1eg6c17zw@gw02.broadleaf.local...
>
> Bounced or *rejected*?
Bounced as in "No such user"
| |
| Sanford Whiteman 2007-06-24, 7:24 pm |
| >> Bounced or *rejected*?
> Bounced as in "No such user"
That's not specific enough.
If a remote system *bounces* your mail, that means that a remote MX
accepted the mail for delivery, then discovered it could not actually
perform delivery and the remote system sent a notification to the MAIL
FROM username@domain. These days, you more commonly get a bounce for
mailbox-full, account-disabled or other "deeper" reasons than for a
nonexistent user -- because mail to nonexistent users should never even be
accepted in the first place.
If a remote system *rejects* your mail, that means that the remote MX did
not allow your server to submit the mail data in the first place. In that
case, _your_ system sends a bounce message to the MAIL FROM
username@domain.
--Sandy
|
|
|
|
|