spf-discuss
[Top] [All Lists]

why I decided to freeze the design with macros still in it

2003-12-15 16:19:50
On Mon, Dec 15, 2003 at 01:18:22PM -0800, Hallam-Baker, Phillip wrote:
| 
| The other issue that would delay certainty is adding complex and unnecessary
| features. Eric is right, you need to jettison the macro capability and
| anything else that is not absolutely essential, particularly if it is tricky
| to specify.
| 

In designing SPF, I have tried to balance as many stakeholder
perspectives as possible.  I understand that macros may be daunting, but
I believe that in combination with "exists:" and "exp=" they are a net
win, and the consensus on this list agrees.  In any case, it's past time
for SPF to stop being a moving target, why is why I declared the SPF
design "frozen".  Considering that people have already implemented
macros, it doesn't seem like a good idea to unfreeze the design just to
delete them.  If there is a major MTA or antivirus company out there
whose programmers find macros hard to program for, contact me and I will
pay someone to do it for you.

Eric Allman has argued for a simpler format that can be implemented in
sendmail rulesets alone.  He has explicitly told me that because SPF has
a more complex language, he thinks it is inferior to DMP which is
simpler.  I don't want to go over old arguments about the "simple to
parse vs. complex to write" equation.  Instead, I should let the people
who have already independently implemented SPF speak for themselves:

On Mon, Dec 15, 2003 at 05:27:53PM -0500, Terence Way wrote:
|
| I started the Python implementation on 11:00PM Tuesday of last week.  By
| 3:00AM I had working code (sans ptr: and macros).  Macros took about 3
| hours of work.
|

On Mon, Dec 15, 2003 at 05:33:47PM -0500, R. Scott Perry wrote:
|
| FWIW, we have just about finished the macro support for Declude JunkMail (a
| commercial product).  The coding can be a bit tricky, but a good developer
| shouldn't have problems implementing it.  Anyone with a successful
| commercial anti-spam product should have no problems implementing the
| macros (unless they are only successful due to marketing!).
|
| As for the need, it is very useful -- for many years, DNS-based spam
| databases have had TXT records that have a URL to go to for more details,
| that includes dynamic information (such as "Your mailserver is listed in
| OURSPAMDATABASE, see
| http://www.our_spam_database.com/checkip.cgi?ip=192.0.2.25";).  Over the
| years, that has saved a lot of people a lot of work (*lots* of mailserver
| admins do not know the IP address of their mailserver, and often think it
| is something other than what it really is).
|                                                 -Scott
|

If Sendmail decides to support DMP, I will add more code to the Wizard
(http://spf.pobox.com/wizard.html) to autogenerate the needed DMP
records, and I will add a warning that says: you will need to come here
and re-run the wizard every time you or your ISP changes mail servers.
You may not know in advance when your ISP will change mail servers.  We
therefore recommend that you come here and re-run the wizard every 24
hours, or sooner if possible.

-------
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.4.txt
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡


<Prev in Thread] Current Thread [Next in Thread>