I think that Eric represents one of the MTA views on SPF. Other views
would be represented by the Milter viewpoint, qmail, etc. These folks
have one perspective.
The DNS implementors have another perspective. Happily (at the moment),
these people do not need to be involved as no changes are required.
The DNS deployers have a different perspective. They are concerned about
how to get the new records inserted into their customer's DNS. Some have
limits on the number of records, some have limits on the type of records.
The Domain operators probably fall into two (somewhat overlapping)
groups: vanity domain operators and Email provider operators. This last
group is by far the most numerous, and requires the most attention. This
group has two concerns: how to deploy compliant MTAs and how to publish
the SPF data. Deploying compliant MTAs should be easy -- especially as
the MTA implementors upgrade their implementations to support SPF.
Publishing the SPF data is more tricky -- but this depends on whether
the DNS deployers make it easy or not.
How might a DNS deployer make it easy? How about the following:
* Go to their DNS control panel and say 'I want to turn on SPF'. It
says: please send one or more emails to
'spfsetup-<randomstuff>@domain.name'.
* You do this.
* Go back to the DNS control panel and you are presented with some
information about the messages that you sent. It asks if these messages
are genuine.
* It has a number of checkboxes that provide extra options: [] Send
message from anywhere [] softfail [] reports to ...........
* You click the OK button and a suitable record is generated and
inserted into the DNS.
An advanced mode might also be available.
This type of scheme might be too complex to implement for a DNS
deployer, so you might have a SPF expert company that provides this as a
service. When the customer clicks the 'I want SPF', then the "v=spf1
redirect=%{d}.spf-expert.net" gets inserted, and the customer is sent to
the control panel provided by spf-expert.net.
Why is all this relevant? Eric complains that the complexity of SPF is
such that it cannot be implemented in sendmail.cf. I beleive him, but
this doesn't seem to be a good argument. SPF is clearly implementable in
a full featured language (these already exist). The bigger question is
whether SPF is powerful enough to support the real world. I.e. can it
support yahoo.com, aol.com, hotmail.com in any meaningful way? I would
suggest that these questions be explored urgently -- if the answer is
NO, then there is no point in pushing SPF forward. My suspicion is that
the use of macros mean that these domains could be supported by having a
complex _spf domain which is automatically generated.
Sorry for the rambling....
Philip
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.txt
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡