I believe you need to properly address the audience:
X.0 Implementating SPF
X.1 For SMTP Developers
SMTP developers should make all efforts to add SPF logic directly into the
state machine.......
X.2 For SMTP Administrators
X.2.1 If you have SMTP system with dynamic/direct integrating...
X.2.1 If you have a POST SMTP system....
etc.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)
----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, May 15, 2005 12:32 AM
Subject: Re: [spf-discuss] MUST SPF checking be done during SMTP time?
In <200505141427(_dot_)j4EERRZ2063686(_at_)asarian-host(_dot_)net> Mark
<admin(_at_)asarian-host(_dot_)net> writes:
I would just drop the entire last paragraph of section 2.4.
I think that it is important to leave the last paragraph in because it
gives reasons why you SHOULD perform the SPF check during the SMTP
transaction. I think it could, however, do a better job of making
that point. In particular the last paragraph starts out with "oftware
can also perform the authorization after the corresponding SMTP
transaction has completed."
I've been playing around with the last paragraph, and section 2.4 now
ends with this:
This authorization check SHOULD be performed during the processing of
the SMTP transaction that sends the mail. This allows errors to be
returned directly to the sending server by way of SMTP replies.
Performing the authorization after the corresponding SMTP transaction
has completed faces problems, such as: 1) It may be difficult to
accurately extract the required information from potentially
deceptive headers. 2) If the email is forged and the authorization
fails, then generating a non-delivery notification to the alleged
sender is abusive and is against their explicit wishes.
Again, I'm kind of playing around with this, I'm really not set on
this wording. Comments are very welcome. I was very tempted to point
out that bogus bounces can (now) be reported to spamcop and can get
your MTA listed on their DNSBL. ;-)
-wayne
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com