Re: Odd Problem

Matt,

If I am reading your original message properly, the following are the facts:

Issue: Failure of a message from a user at chilitech.net to a user at NCX.COM

(To Site Information):
NCX.COM
A - 216.107.0.2
MX - mail.ncx.com
mail.ncx.com -
A - 216.107.0.106

(Bounced Message Header Information):
First IP Received at Original Message information - 209.115.132.2

209.115.132.2
PTR - 209-115-132-2.DNS77.com
209-115-132-2.DNS77.com
A - NONE
TXT - NONE
DNS77.com
A - 209.115.132.55
TXT - NONE
MX - eg2.DNS77.com eg1.dns77.com
eg2.DNS77.com
A - 209.115.132.3
eg1.dns77.com
A - 209.115.132.2

(From Site Information):
chilitech.net
A - 63.174.244.8
MX - smtp-in.chilitech.net
TXT - v=spf1 a mx ptr ip4:63.174.244.0/24 -all
smtp-in.chilitech.net -
A - 63.174.244.105 63.174.244.106 63.174.244.3
TXT - NONE

- End of Facts

Observations:

The problem appears that the original chilitech.net user message sent to 
NCX.COM was relayed through 209-115-132-2.DNS77.com and not directly sent 
from smtp-in.chilitech.net to mail.ncx.com as the published DNS records 
suggests should have happened.
If NCX.COM's MTA (mail.ncx.com) checked who sent the message to it, based 
upon the headers, it seems to have come from 209-115-132-2.DNS77.com and 
not smtp-in.chilitech.net where the SPF record claimed it should have come 
from.
The chilitech.net SPF record is correct for mail from 
smtp-in.chilitech.net, but not from 209-115-132-2.DNS77.com
The question is why and how did the message relay through 
209-115-132-2.DNS77.com?  Based upon the DNS information, the 
smtp1-ha.chilitech.net machine should have sent the message to the 
mail.ncx.com machine.
There are four simple possibilities I can think of:

1) If it was that the message was filtered by 209-115-132-2.DNS77.com prior 
to reaching mail.ncx.com as a choice of the folks at NCX.COM, then 
mail.ncx.com should have know this because it would have had to send to 
DNS77.com and thus should have ignored the 209-115-132-2.DNS77.com header, 
instead going for the smtp1-ha.chilitech.net machine (the next one down in 
the list of senders) which did have the IP 63.174.244.3 matching a 
smtp1-ha.chilitech.net machine, per the chilitech.net DNS record.  I don't 
think this is the case (and I'm not sure it is even a possible scenario).
2) If it was that the message was filtered by 209-115-132-2.DNS77.com prior 
to reaching mail.ncx.com as a choice of the folks at chilitech.net, then 
the chilitech.net DNS TXT record should be changed to reflect an 
"include:DNS77.com" - unfortunately DNS77.COM does not seem to publish any 
SPF record information, though with an explicit Include placed in the 
chilitech.net SPF record, perhaps that might not matter and that the MX 
record of the include would be presumed valid - I just don't know how or if 
that is the behavior a server should exhibit to handle the include: 
syntax.  Even so, you will note that 209.115.132.2 reverses to the IP for 
one of DNS77.COM's MX servers, but the reverse lookup does not match the MX 
server name.  As a side note, sometimes, folks will block messages in 
situations where the MX records do not reverse match.
This brings up another question.  Does it make any sense at all or would it 
be needed to have an additional parameter associated with an "include:" to 
force MX compliance at the included domain if no SPF is published at the 
included domain (e.g., something like "include:DNS77.COM include-:MX")? 
Where the include-: could have all appropriate standard SPF syntax to 
follow (e.g. IP4:, A, MX, etc).  I realize that one is essentially 
publishing an SPF record for another domain in by doing this, but it does 
allow the publishing domain name owner to be more explicit in their desires 
if the include domain itself does not publish SPF records.  Perhaps a 
proposed "include-:" could actually use the "all" syntax for its characters 
to be more clear with intent - in other words, "include+:", "include-:", 
"include?:", etc.
3) If it was that the message was sent by 209-115-132-2.DNS77.com as a 
function of a user at chilitech.net somehow altering headers and sending 
directly via 209-115-132-2.DNS77.com, then tell the user in your best 
Arnold voice, "Don't do dat" and have them send messages directly through 
the smtp1-ha.chilitech.net machine.
4) If it was that the message was sent by 209-115-132-2.DNS77.com to 
mail.ncx.com, claiming to be from a user at chilitech.net, then using the 
published records as they are, SPF is doing its job.
Given the headers as stated in the original message, it seems that this 
message should not have passed because the message was not received from a 
published MX sender, as the publisher of the domain chilitech.net has only 
allowed messages from smtp-in.chilitech.net which seems correct.
Conclusion:
Insufficient data to come to a conclusion until we find out exactly how the 
DNS77.COM IP came into the picture.
Best,

Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/


At 11:39 AM 11/10/2004, you wrote:
> Ok,
> So I'm clearly not doing something right here, but I don't know what.
> The other day I got the following attached bounce back from a
> Barracude Spam Box.. but as far as I can tell my SPF records are
> correct, and this person sent mail out through one of the encompassed
> mail servers.. any thoughts?
>
>
> ---- SPF RECORD BEGIN ----
> v=spf1 a mx ptr ip4:63.174.244.0/24 -all
> ---- SPF RECORD END ----
>
>
>
> ----- BEGIN BOUNCE -----
>
> Subject: Undeliverable Mail
>
>
>
> >> undeliverable to gemabooks(_at_)ncx(_dot_)com
> >>
> >> Server response to MAIL FROM:
> >> 587 pioneer(_at_)chilitech(_dot_)net sender domain does not match SPF records
> >>
> >>
> >>
> >> Original message follows.
> >>
> >> Received: from eg1.dns77.com [209.115.132.2] by imail1.dns77.com with
>
> ESMTP
>
> >>   (SMTPD32-8.12) id A342136900F0; Tue, 09 Nov 2004 15:22:58 -0700
> >> X-ASG-Debug-ID: 1100038887-21246-341-0
> >> X-Barracuda-URL: http://209.115.132.2:1927/cgi-bin/mark.cgi
> >> Received: from smtp1-ha.chilitech.net (smtp1-ha.chilitech.net
>
> [63.174.244.3])
>
> >> by eg1.dns77.com (Spam Firewall) with ESMTP id EB7C5D0CFE94
> >> for <hofr(_at_)gemabooks(_dot_)com>; Tue,  9 Nov 2004 15:21:27 -0700 (MST)
> >> Received: (qmail 31598 invoked by uid 11193); 9 Nov 2004 22:21:20 -0000
>
> Received: from pioneer(_at_)chilitech(_dot_)net by smtp1-ha.chilitech.net by uid
> 502
> with qmail-scanner-1.20
>
> >>  (clamuko: 0.75.1. spamassassin: 2.64.  Clear:RC:1(198.69.197.61):.
>
> Processed in 0.279358 secs); 09 Nov 2004 22:21:20 -0000
>
> >> Received: from unknown (HELO thepurplebeast) ([198.69.197.61])
> >>           (envelope-sender <pioneer(_at_)chilitech(_dot_)net>)
> >>           by 0 (qmail-ldap-1.03) with SMTP
> >>           for <hofr(_at_)gemabooks(_dot_)com>; 9 Nov 2004 22:21:20 -0000
> >> Message-ID: <001001c4c6aa$1eb47760$3dc545c6(_at_)thepurplebeast>
> >> From: "kerry detrick" <pioneer(_at_)chilitech(_dot_)net>
> >> To: <hofr(_at_)gemabooks(_dot_)com>
> >> X-ASG-Orig-Subj: none
> >> Subject: none
> >> Date: Tue, 9 Nov 2004 17:18:59 -0500
> >> MIME-Version: 1.0
> >> Content-Type: multipart/alternative;
> >> boundary="----=_NextPart_000_000D_01C4C680.33A3C1A0"
> >> X-Priority: 3
> >> X-MSMail-Priority: Normal
> >> X-Mailer: Microsoft Outlook Express 5.50.4133.2400
> >> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> >> X-Virus-Scanned: by Barracuda Spam Firewall at dns77.com
> >> X-Barracuda-Spam-Score: 0.06
> >> X-Barracuda-Spam-Status: No, SCORE=0.06 using global scores of
>
> TAG_LEVEL=4.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests=HTML_30_40,
> HTML_MESSAGE
>
> >> X-Barracuda-Spam-Report: Code version 2.64, rules version 2.1.504 Rule
>
> breakdown below pts        rule name                      description
> ---- ---------------------- -------------------------------------------
> 0.06 HTML_30_40             BODY: Message is 30% to 40% HTML
>
> >> 0.00 HTML_MESSAGE           BODY: HTML included in message
> >>
> >> This is a multi-part message in MIME format.
> >>
> >> [message truncated]