Alex,
Thank you for your attached. I think we are mostly in sync.
At 03:26 PM 2/10/2005, you wrote:
On Thu, Feb 10, 2005 at 01:58:34PM -0700, Commerco WebMaster wrote:
> my company is telling any parties checking (and fully expect them to
> understand in publishing the above) that this domain does not send email
> messages at all - EVER. Therefore, what I also expect to happen is that a
> receiving MTA / SMTP server will simply junk anything seen with a FROM
> address using that domain or any sub domain in it.
You can advertise your policy but you cannot make the receiver do what
your want.
Absolutely true. But if a receiver application or add in is going to claim
it supports SPF, it really should follow the basic SPF specification for
published SPF Version 1 DNS txt records.
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 syntax
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.
> From my selfish publisher perspective, absolutely any and all other issues
> are moot, if the basic premise of the SPF system is no longer
> applicable. At that point, we might as well just pack our bags and leave
> the project and I for one have no intention of doing that. The base
stated
> functionality of SPF MUST supercede any other concern without exception.
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
off for today. My concern was from thinking that some were suggesting that
the -all syntax might indicate subjective behavior depending upon the
implementation provider's view.
I think that is good enough reason not to reject. I do agree that one
should not bounce, auto-reply or whatever to such messages.
My company is currently working to hunt down individuals who send out mass
email messages misusing the company's domain names in the message
FROM. Obviously the nature of and participants in that investigation
process is private. The problems we face from this kind of misuse is that
the bounce problem is seemingly getting to be almost as abusive to the
company's network as the spam problem itself. Of course, I believe that
issue will tend to go away as support for SPF publishing becomes more
universally supported by MTA / SMTP servers.
That is why my company is a big proponent for getting SPF adopted and
published by companies and seeing SPF implemented by MTA / SMTP server
providers. There are some really big companies who have not implemented
SPF and cause us (and other who experience domain name theft abuse in email
like us) difficulty from all the bounced records received from them. Not
to mention the reputation damage done to any company's domains when a
delivered message actually gets through and the domain name is unfairly and
wrongly associated in the minds of recipients with something the domain
owner would never want their domain to become associated.
regards,
Alex
Best,
Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/