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.

[ Post a follow-up to this message ]

> 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

[ Post a follow-up to this message ]

"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?

[ Post a follow-up to this message ]

> 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

[ Post a follow-up to this message ]

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?

[ Post a follow-up to this message ]

"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?

[ Post a follow-up to this message ]

> 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

[ Post a follow-up to this message ]

> 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

[ Post a follow-up to this message ]

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"

[ Post a follow-up to this message ]

>> 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

[ Post a follow-up to this message ]