http://www.schlitt.net/spf/spf_classic_libspf2/draft-schlitt-spf-02.txt
----------------------------------------------------------------------
| 1. Introduction
|
| The current e-mail infrastructure has the property that any host
| injecting mail into the mail system can identify itself as any domain
| name it wants.
Hosts do not identify themselve as domains! Hosts can use domain as part
of the host's FQDN though.. So change wording in some fashion, I suggest:
1. Introduction
The current e-mail infrastructure has the property that any host
injecting mail into the mail system can identify itself as any
name it wants and use any domain as part of it.
----------------------------------------------------------------------
| 2.4 Checking Authorization
|
| A mail receiver can perform an SPF compliant check for each mail
| message it receives. This check tests the authorization of a client
| host to inject mail with a given "MAIL FROM" identity. This check
| MAY also be applied to the "HELO" identity. Typically, such checks
| are done by a receiving MTA, but can be performed elsewhere in the
| mail processing chain so long as the required information is available.
|
| Checking other identities against SPF records is NOT RECOMMENDED
| because there are cases that are known to give incorrect results.
I have serious problem with this. The information may be available but
it maybe old as such SPF record may have changed, also deciding on if
information is available is not quite right because you can not be sure
such "available" information is actually accurate unless its MTA doing
authorization directly.
May I suggest that you use instead the text recommended by Andy Bakun at
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200412/0370.html
2.4 Checking Authorization
A mail receiver can perform an SPF compliant check for each mail
message it receives. This check tests the authorization of a client
host to inject mail with a given "MAIL FROM" identity. This check
MAY also be applied to the "HELO" identity.
SPF records SHOULD NOT be used for any other purpose - such use is not
guaranteed to yield predictable results or results that the domain
owner expects. This includes checks of SPF records performed at times
other than during mail submission or SMTP transmission. In most cases
only mail software that is on the edge of the local network and that
is directly accepting email from remote MTA can correctly perform
SPF tests.
| It is expected that mail receivers will use SPF check as part of
| a larger set of tests on incoming mail. The results of other tests
| may influence whether or not a particular SPF check is performed.
The above sounds like policy recomendation (not appropriate for IETF
protocol document), I suggest changing one word for it to become:
Is is possible that mail receivers will use SPF check as part of
a larger set of tests on incoming mail. The results of other tests
may influence whether or not a particular SPF check is performed.
| Care must be taken to correctly extract the <domain> from the
| <sender> as many MTAs will still accept such things as source routes
| (see [RFC2821] appendix C), the percent hack (see [RFC2162]) and bang
| paths (see [RFC1983]). Spammers often use of such archaic features
| to try and trick MTAs into being open relays.
I only have problem with last sentence (I think it not right to mention
spammers in spf protocol document not to mention sentense is not gramaticly
correct, i.e. "Spammers often use of such"). I suggest changing this into
Care must be taken to correctly extract the <domain> from the
<sender> as many MTAs will still accept such things as source routes
(see [RFC2821] appendix C), the percent hack (see [RFC2162]) and bang
paths (see [RFC1983]) and that may be inappropriatly used to trick
MTAs into being an open relays".
| Software can perform the authorization after the corresponding SMTP
| transaction has completed. There are two problems with this
| approach: 1) It may be difficult to accurately extract all the
| required information such as client IP address and HELO domain name.
| 2) If the authorization fails, then generating a non-delivery
| notification to the alleged sender is problematic due to the large
| number of forged emails on the Internet today. Such an action would
| go against the explicit wishes of the alleged sender.
I recommend changing this into:
Software SHOULD NOT perform the authorization after the corresponding
SMTP transaction has completed unless its done immediatly after on
behalf of the receiving mail server system as parts of its processing.
The following are the problems that exist if authorization check is
done after the SMTP transaction:
1) It may be difficult to accurately extract all the required
information such as client IP address and HELO domain name.
2) If the authorization fails, then generating a non-delivery
notification to the alleged sender is problematic due to the
large number of forged emails on the Internet today. Such an
action would go against the explicit wishes of the alleged sender.
----------------------------------------------------------------------
| 2.5.5 SoftFail
| ...
| Because the domain has discouraged any legitimate use of this IP
| address, receivers MAY try to inform either the sender or the
| recipient of the e-mail. For example, the MUA could highlight the
| SoftFail status for the receiver, or the MTA could issue an SMTP
| reply code of 451 and the 4.3.0 DSN code, in addition to an with a
| note the first time the message was received, but accept it the
| second time.
There are some grammer problems with above and in any case you might as
well explicitely mention greylisting after explanation like that. Plus
use of SPF for MTA checking should not be encoranged, so I would like to
see changes as follows:
Because the domain has discouraged any legitimate use of this IP
address, receivers MAY try to inform either the sender or the
recipient of the e-mail. For example MTA could issue an SMTP
reply code of 451 and the 4.3.0 code DSN with special note,
the first time the message was received, but accept it the
second time (this technique is sometimes called greylisting).
----------------------------------------------------------------------
Ok. That is it for tonight, I'll resume reading the document and send
my comments and notes (if any) for sections 3.0 and above tomorrow.
Overall good job though, better then previous drafts...
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net