On Fri, Oct 10, 2003 at 10:49:27PM -0500, wayne wrote:
| > Participating domains publish SPF records to indicate that only
| > certain hosts are permitted to send mail using that domain in the
| > envelope sender. In the case of a null envelope sender, the domain
| > from the HELO/EHLO command is tested instead.
|
| Couldn't/shouldn't the HELO/EHLO domain be verified all the time?
No. If a domain is too lazy to publish SPF data for its MX servers, the
consequences aren't that major --- the envelope sender will be blank, so
they won't get the bounces, and with any luck a smart MTA will refuse to
accept mail with more than one recipient.
What a domain can do, though, is add a "scope=envelope,header-from", and
that way it'll protect itself from messages that have null envelope
senders but forge the header From:. I expect PayPal will want to do this.
| > "v=spf1" indicates compliance with version 1 of the SPF protocol.
|
| I would recomend a version number being in the form of <major>.<minor>
| rather than a text string.
Future versions can be "v=spf1.1".
| > Scope := "scope=" ( ( "" | "envelope" ) | "header-from" | "errors-to"
) )
| > By default, envelope scope is assumed.
|
| What does a scope of "" do?
defaults to "envelope". This is so you can say scope=,header-from
| > Explanation := "exp=" ( literal string of maximum length 128 characters )
| > this string MAY be used by SPF clients in an SMTP
rejection message.
| > it should contain text explaining the policy decision or a
URL to such text.
|
| I'm not so sure about this exp thing. It opens up a huge can of worms
| with respect to different languages and such. Is the limit 128
| "characters", or 128 "bytes"? (UTF-32 is 4 bytes per character, IIRC.)
|
OK, I removed the restriction. I'll say implementations SHOULD provide
at least 128 bytes of that string to the SMTP client, but no more.
| > default-esd := ""
| > expanded by the SPF client to the sender-domain.
|
| I don't understand this either....
|
It's a shorthand.
Given MAIL FROM:<bob(_at_)example(_dot_)com>, and a lookup response of
"v=spf1 mx default=deny"
the "mx" is read as "mx:example.com".
| > ipv4-cidr-spec := standard IP number "/" cidr-range, eg. "127.0.0.1/8"
| >
| > ipv6-cidr-spec := uh, the same thing, but for IPv6. I really have no
idea about this.
|
| If we (tinw) are going to allow IPv6 specs (I think we should), then it will
| probably be a lot less confusing if we (tinw) don't use the colon for
| anything. IPv6 addresses, after all, make heavy use of the colon to
| shorten up the numbers.
I don't think this'll be a major difficulty for the parser.
I could switch to = if that really bothers people.
I'm using = for modifiers and : for mechanisms, but I'm not terribly invested.
-------
Sender Permitted From: http://spf.pobox.com/
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(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡