iis smtp nntp: Hi,
I've a really big problem sending mails to hotmail accounts.
Till some days ago email was correctly delivered to hotmail accounts
(although most of them where classified as spam).

Now there's no way to get mail sent by our Virtual SMTP server being
delivered to hotmail, nor in spam/junk folder.

We are on Windows Server 2003, IIS 6.
We have an ASP.NET application that uses SMTP Server through pickup
directory (mail are saved in files in "\Inetpub\mailroot\Pickup" dir).

The IIS SMTP Server is configured with this params:
- tab Access / Connection : selected "Only the list below" [the list
is empty]
- tab Access / Relay: selected "Only the list below" [the list is
empty] - Checked "Allow all computers with succesfully ...."
- tab Delivery / Advanced: Fully-qualified domain name:
"outmail.mydomain.com"

SPF - SenderID:
My SPF record is:
v=spf1 ip4:208.xxx.xxx.xxx a a:outmail.mydomain.com
include:aspmx.googlemail.com ~all

DNS:
- In DNS configuration, domain outmail.mydomain.com resolve to IP
208.xxx.xxx.xxx [the same of SPF record]
- ReverseDNS: if you reverseDNS the IP 208.xxx.xxx.xxx it gets
'mydomain.com'


The SPF-SenderID should be correctly configured.
Infact, looking at the headers of an mail sent by us to a gmail
account,
SPF passes the validation:

Received: from outmail.mydomain.com (mydomain.com [208.xxx.xxx.xxx])
by mx.google.com with ESMTP id i37si15464203wxd.
2007.10.08.23.02.07;
Mon, 08 Oct 2007 23:02:08 -0700 (PDT)
Received-SPF: pass (google.com: domain of ourmail@mydomain.com
designates 208.xxx.xxx.xxx as permitted sender) client-
ip=208.xxx.xxx.xxx;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of
ourmail@mydomain.com designates 208.xxx.xxx.xxx as permitted sender)
smtp.mail=ourmail@mydomain.com
Received: from mail pickup service by outmail.mydomain.com with
Microsoft SMTPSVC;
Tue, 9 Oct 2007 02:02:07 -0400


Furthermore our emails are accepted by Hotmail Servers. From SMTP log
we see:

2007-10-09 07:20:43 65.54.244.72 - 220+bay0-mc3-f19.bay0.hotmail.com
+Sending+unsolicited+commercial+or+bulk+e-mail+to+Microsoft's+computer
+network+is+prohibited.+Other+restrictions+are+found+at+http://
privacy.msn.com/Anti-spam/.+Violations+will+result+in+use+of+equipment
+located+in+California+and+other+states.+Tue,+9+Oct
+2007+00:20:43+-0700+ 308 0 62
2007-10-09 07:20:43 65.54.244.72 EHLO outmail.mydomain.com 4 0 62
2007-10-09 07:20:43 65.54.244.72 - 250-bay0-mc3-f19.bay0.hotmail.com
+(3.4.0.37)+Hello+[208.xxx.xxx.xxx] 67 0 156
2007-10-09 07:20:43 65.54.244.72 MAIL FROM:<ourmail@mydomain.com>
+SIZE=2959 4 0 156
2007-10-09 07:20:43 65.54.244.72 - 250+ourmail@mydomain.com....Sender
+OK 35 0 234
2007-10-09 07:20:43 65.54.244.72 RCPT TO:<hotmailaccount@hotmail.com>
4 0 234
2007-10-09 07:20:43 65.54.244.72 - 250+hotmailaccount@hotmail.com+ 29
0 312
2007-10-09 07:20:43 65.54.244.72 BDAT 2959+LAST 4 0 312
2007-10-09 07:20:43 65.54.244.72 - 250+
+<xswadfebcrYP0QzBxh00000157@outmail.mydomain.com>+Queued+mail+for
+delivery 78 0 406
2007-10-09 07:20:43 65.54.244.72 QUIT - 4 0 422
2007-10-09 07:20:43 65.54.244.72 - 221+bay0-mc3-f19.bay0.hotmail.com
+Service+closing+transmission+channel 70 0 500


I've run also run a DNSreport from dnsstuff.com and there's no FAIL
and 2 WARNS:
[NS Section]
Single Point of Failure
WARNING: Although you have at least 2 NS records, they may both point
to the same server (one of our two tests shows them being the same,
the other could not complete the test), which would result in a single
point of failure. You are required to have at least 2 nameservers per
RFC 1035 section 2.2.
[Mail Section]
Mail server host name in greeting
WARNING: One or more of your mailservers is claiming to be a host
other than what it really is (the SMTP greeting should be a 3-digit
code, followed by a space or a dash, then the host name). If your
mailserver sends out E-mail using this domain in its EHLO or HELO,
your E-mail might get blocked by anti-spam software. This is also a
technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the
hostname given in the SMTP greeting should have an A record pointing
back to the same server. Note that this one test may use a cached DNS
record.
alt2.aspmx.l.google.com claims to be non-existent host mx.google.com:
<br /> 220 mx.google.com ESMTP 62si8885422wri <br /
[quoted text, click to view]
<br /> 220 mx.google.com ESMTP f45si15088475pyh
.............

The second WARN ("WARNING: One or more of your mailservers is claiming
to be...") was present also when mails were delivered to hotmail
account..
I dont' remember about first warn.


The strange thing is that I've tryed to send an email using a
different SMTP Server (the one I use for my personal mails)
using as sender the same email address that fails, the SMTP does not
have a rDNS and is not allowed by SPF record
and... it has been delivered! And has passed the spam/junk filters
too! It seems to me incredible this behaviour...

Sorry, I know I've wrote a long post... But it's two day I'm getting
mad on this issue and I really don't know what else to do...

If you have any idea of where I can start for solving this problem
it'll be really appreciated...

Thank you very much in advance!

[quoted text, click to view]

Please don't obfuscate your domain if you want people to
corroborate/extend your findings. It's an admission that keeping your
"secrets" (which are actually visible to the public on every SMTP
connection) is more important than solving your problems.

[quoted text, click to view]

Okay, so they're being silently dropped. That means we will have to
use a lot of intuition; and for that, your real configuration is
essential.

[quoted text, click to view]

You want to run a report for your mailserver's public IP address as
much as for your domain.

You are correct that your forward DNS report shows only very minor
problems. But what about the reverse?

[quoted text, click to view]

Um, you did a lookup on google.com?

[quoted text, click to view]

It's only incredible if you can give us an apples-to-apples comparison
with real data.

It's certainly possible for a mailserver that has distinctly
_conflicting_ configuration information to have its mail dropped,
while another mailserver that has _missing_ information can get mail
through. Frustrating, but true.

[quoted text, click to view]

Search the recent posts of this list for an explanation of the
PTR-HELO-A roundtrip. Establish that you pass this test by providing
the actual hostnames and IP addresses. Nothing makes me roll my eyes
more than when someone is trying to find down an elusive error in
their _public_ DNS/SMTP/routing configuration, but won't provide real
information to the people reading their post!

--Sandy


------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.

Thanks for your help.
I'm sorry about obfuscating IP and hostname, I thought it could be
resolved without leaving them visible....

Hower that may be, your help was really useful!
The PTR-HELO-A roundtrip was somewhat not perfect:
the PTR resolved the top level domain and not the FQDM of HELO
the HELO FQDN was not in A record but in CNAME.
We'fe fixed them and had partially solved the problem

[quoted text, click to view]
they are Text-Only or HTML-Only, but accepts them if are mixed Text/
Html (multipart/alternative), although it delivers them to Junk
folder.

The last thing that should solve the Junk problem could be the Header
added by IIS SMTP server
"Received: from mail pickup service" for mails saved to pickup dir.

[quoted text, click to view]
UNPARSEABLE_RELAY test match...
Unfortunately seems that the implied header could not be removed...

Thanks again for support & help!

[quoted text, click to view]

No, not when published involves the relationship between published
forward and reverse DNS records, their public reputations, and your
local config.

But you are still hiding your data.

[quoted text, click to view]

Good to hear.

[quoted text, click to view]

OK, good fixup. (Technically, the matching CNAME is acceptable there,
but it creates more DNS traffic and there should be no reason to not
use an A. The idea, as you may now know, is that what the machine says
about itself is corroborated on both sides of the public DNS.)

[quoted text, click to view]

That is a non-RFC header, but can you prove that mail that is
submitted using SMTP doesn't have the same delivery issues as that
submitted through \Pickup? One low-scored SA rule is unlikely to make
a difference.

Please provide your domain, source IP, and HELO data this time around
so it may be analyzed.

--Sandy


------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.