alex at ergens
Oct 23, 2006, 9:12 PM
Post #3 of 3
(1725 views)
Permalink
|
On Mon, Oct 23, 2006 at 08:24:20PM -0700, Bill Walton wrote:
> I would have thought that the outbound mail server is the only host I
> should include. Since my ISP (ihwy.com) tells me that my outgoing
> mail is relayed only by mail.rawbits.com (which is, apparently, the
> same as ms44.ihwy.net),
Your mail reached this list as follows:
> Received: from ms44.ihwy.net (ms44.webhostingprovider.com [207.114.164.244])
> by chiclet.listbox.com (Postfix) with ESMTP id A2C9A81B4B for
> <spf-help [at] v2>; Mon, 23 Oct 2006 23:25:41 -0400 (EDT)
Thus: a machine calling itself ms44.ihwy.net delivered the message.
SPF would look at this HELO parameter, and find no SPF record.
This produces a 'none' result, equivalent to 'neutral'.
Then SPF would look at the MAIL FROM parameter, and find this:
"v=spf1 a:mail.rawbits.com ~all"
which ask us to lookup mail.rawbits.com in DNS, and use the result
to compare against 207.114.164.244, which is a match.
If that host has a static address (it probably has!) then the following
would save a DNS lookup each time your SPF is processed:
"v=spf1 ip4:207.114.164.244 ~all". This will bite you when that host
suddenly changes it address. OTOH another host with another name
could replace the current box at the same address, and "ip4" would
not bite you where "a" would.
In other words: if changes are going to happen, "ip4" and "a" both
have a chance of turning bad. In such a case, I'd opt for the less
resource intensive option and choose ip4.
The only real solution would be that your provider does generate
an SPF record for you to include and, equally important, does
maintain it. Even include will fail if changes are not recorded
in the to-be-included record.
About HELO (which you cannot fix yourself):
Domain ms44.ihwy.net is not a canonical name and should not be used
as helo parameter. ms44.webhostingprovider.com (where ms44.ihwy.net
is pointing to) does seem to be the canonical name. I'm not sure if
this is a problem for large providers or not, but it certainly wouldn't
hurt to fix it.
> I thought it appropriate to authorize only
> that server. Also, since ihwy.com and ihwy.net don't have SPF
> records (I'm apparently the only customer asking for this at this
> time) I don't want to include:ihwy.net - as I understand it, that
> would result in a permanent FAIL result.
Indeed it would. You cannot include something that's not there.
> >Should your SPF Record include your outbound host
> >(ms44.ihwy.net)? Since ihwy.net probably has many outbound servers
> >you might want to use something like this:
> >
> > "v=spf1 ptr include:ihwy.net ~all"
ugh...
Maybe there are reasons why even the wizard discourages using PTR as
an SPF mechanism...
One of those reasons would be that users generally don't grasp the
concept. Another one would be that it is high-cost and little-profit.
Let's test:
quoting the spf validator:
> Input accepted, querying now...
>
> Mail sent from: 207.114.164.244
> Mail from (Sender): any [at] rawbits
> Mail checked using this SPF policy: v=spf1 ptr -all
> Results - FAIL Message may be rejected
ptr for domain rawbits.com does not match when a connection is
made from 207.114.164.244 and with MAIL FROM domain rawbits.com
because the address 207.114.164.244 is NOT named mail.rawbits.com
207.114.164.244 points to ms44.webhostingprovider.com. If
that name points back to 207.114.164.244 then the following
would match:
ptr:com
ptr:webhostingprovider.com
ptr:ms44.webhostingprovider.com
but not:
ptr:rawbits.com
n.b. The part starting with ':' is optional. In your case, because the
mail from domain is rawbits.com, 'ptr' and 'ptr:rawbits.com' are the same.
End result: apart from being a huge waste of resources, even if include
would not result in an error (but rather not match) then still this
record would match your host on "all" thus process "~" and return softfail.
Let's continue the rant about misconceptions:
Generally speaking, MX and PTR are for providers only. And I mean real
providers, not the computer shop running a web hosting side dish.
By definition, include can only be used when the other party (the one
mentioned after 'include:' has generated a record DESIGNED_FOR_THIS_PURPOSE.
If provider "example.com" sends mail as "sales [at] example", they would
publish an SPF record mentioning the servers _THEY_ use to send _THEIR_
mail. Example: "v=spf1 a:headoffice01.example.com -all"
When "billy [at] personaldomainname" sends mail via this provider,
his mail ends up at a server named "customer01.example.com".
Now, how is "include:example.com" going to help? Answer: it's not.
Billy may need to "include:_customers_spf.example.com", or maybe
"customers.example.com", or something different yet. But he certainly
should not "include:example.com" which is a waste of resources at best.
The only thing that works is to ask example.com what to do. Then
cross your fingers they know their business. Any provider telling
their customers to use the wizard (a power tool for providers) does
not understand SPF.
Alex
-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=cbdbbc81
|
