At 05:52 PM 2/10/2005, you wrote:
On Thu, Feb 10, 2005 at 04:47:15PM -0700, Commerco WebMaster wrote:
> Absolutely true. But if a receiver application or add in is going to
> it supports SPF, it really should follow the basic SPF specification for
> published SPF Version 1 DNS txt records.
It should, yes. Therefore it should assume a message is a forgery (if
-all is hit). But I don't think the specification sais one MUST reject
the message. Think SpamAssassin and the like.
Yes, I see your point. My chief concern in publishing SPF records for my
company's domains is that any forged mail is "assassinated" before it gets
to a human being and that nothing is returned to the real domain holder in
a bounce unless requested by some other possible to be
discussed/implemented modifier for an SPF record.
The joy of receiving some message stating "our advanced spam filter has
determined you sent the following" when it is an obviously forged from IP
address in another country is starting to wear a bit thin with me. Even
more so when said "advanced spam filter" company appears to pay no
attention to requests they consider implementing SPF support in their software.
> >And I'm not entirely sure about the status of looking up the zone cut.
> >Most likely there are plenty of clients that do not look at subdomains.
> This is disappointing to learn. When you say clients, I think (hope) you
> mean MTAs supporting SPF. The feature allowing for the SPF REDIRECT
> was part of SPF version 1 and seems an obvious thing to support for larger
> companies with delegated internal DNS zones as well as those others who
> chose to implement wildcard DNS records for their domains where such
> flexibility is required.
You think publishing redirect covers an entire zone ?
Well, not easily, but I'll send you an off list email message with an
actual domain, where you can try to get an SPF txt record for
FOO.example.com via Dig and it will successfully present a redirect to
_spf.example.com txt record even though FOO.example.com does not actually
exist (wildcard DNS). FWIW, the reason I chose to implement this way was
as a convenience so as to only have to adjust the _spf.example.com record
if TXT changes were required. Thinking about it I suppose those could just
as easily be set to v=spf1 -all in the current case, but for larger
companies who really need to delegate zones, the answer is not that simple.
Others please step in if I'm the one getting this wrong:
I query "a.b.c.something.whatever.example.com TXT", you (example) publish
"v=spf1 redirect:_spf.example.com", you think I get an answer ?
Having just double checked, yes, in our case, you will.
If you do think this: Forget about it. You could as well publish
I could, but in some cases down the road I may not wish to achieve kind of
behavior for every sub domain on the domain.
If OTOH you publish "v=spf1 redirect:_spf.example.com" for each and
every domain (not: host!) then you get what you think you get.
This is unless the zone-cut, tree-walking or whatever it is called makes
it into the spec. I do think it should be there, eventually, but I doubt
it is in right now.
> >At the moment there are plenty of domains experimenting with SPF. Some
> >of those _are_not_ sure, yet they do publish -all.
> Again, I think we agree. If a publisher goes with other than a -all
> syntax, then the behavior may not be to reject, but rather whatever the
> specification indicates. Given that some might argue "correct" behavior
> could be vague or get misinterpreted when specifying ~all (I am not too
> sure that is true), I suppose all bets on behavior for ~all syntax may be
Trust me. Some misguided DNS hosting company or such has published an
SPF record for its clients (without them knowing about it) and people
get their mail rejected.
While such behavior as you point to seems entirely inappropriate, it is
also not the fault of the SPF, those who publish SPF records for their own
domains or those who support published records in their MTA / SMTP software.
Knowing this, you cannot blame the customers of this hosting company for
publishing -all. Would you block? The answer might be yes and that wouldn't
be a bad decision. However, the answer may be no and this too wouldn't be
a bad decision.
I think I see where you are going, but I really believe that the subjective
treatment of what should be an absolute is still not good design. Rather,
perhaps such things should be handled via an ~all with appropriate modifiers.
The Commerce Company - Making Commerce Simple(sm)