spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Last changes to draft-schlitt-spf-classic

2006-01-11 20:20:33
In <200601120014(_dot_)35203(_dot_)julian(_at_)mehnle(_dot_)net> Julian Mehnle 
<julian(_at_)mehnle(_dot_)net> writes:

Wayne Schlitt wrote:
Julian Mehnle writes:
I also wonder if the following change, which I hadn't proposed[1] in
time for draft-schlitt-spf-classic-02, could make it into the last
edition? (Patch attached, too.)

--- draft-schlitt-spf-classic-02.xml
+++ draft-schlitt-spf-classic-02+ipv6-handling.xml
@@ -997,9 +997,13 @@
         When any mechanism fetches host addresses to compare with
         &lt;ip&gt;, when &lt;ip&gt; is an IPv4 address, A records are
         fetched, when &lt;ip&gt; is an IPv6 address, AAAA records are
-        fetched.  Even if the SMTP connection is via IPv6, an
-        IPv4-mapped IPv6 IP address (see <xref target="RFC3513"/>
-        section 2.5.5) MUST still be considered an IPv4 address.
+        fetched.  For SPF clients supporting IPv6, it is recommended that
+        it internally operates on IPv6 addresses only, and that it
+        converts any IPv4 addresses to IPv4-mapped IPv6 addresses
+        (::ffff:n.n.n.n, see <xref target="RFC3513"/> section 2.5.5)
+        internally. However, the client MUST still match any such
+        ::ffff:n.n.n.n addresses against n.n.n.n addresses in SPF records
+        and format them as n.n.n.n addresses when generating output text.

I don't see any reason to tell implementations how to do their job.

Heck, but this is what the current wording already does!

The current wording doesn't say anything about how implementations do
things internally, such as operating only with IPv6 addresses.


How about s/MUST still be considered an IPv4 address./MUST still be
treated in all ways like an IPv4 address from an IPv4 connection./ ?


This may be a good way of doing things, but I see no reason that should
be in the draft.  It is already too long. 

Then why don't you delete such sentences as...

Thanks, I like suggested deletions.


   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 and reliable.

...or...

   It is possible that mail receivers will use the 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.
   For example, finding the sending host's IP address on a local white
   list may cause all other tests to be skipped and all mail from that
   host to be accepted.

?  Those are _at_least_ as redundant as the above IPv6-related change!!

I didn't add either of those sections, but yeah, I find them somewhat
redundant.  However, there *were* long arguments about whether it was
*ever* acceptable to apply SPF anywhere other than the SMTP session.
There have been people who have said that what spamassassin does is
totally unacceptable.  I strongly disagree, and so I can see some
justification for leaving those explanations in.



-wayne


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
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