Just Another (small-time) Email Admin. Long time subscriber, first time
poster.
On Tue, 2003-10-28 at 08:51, wayne wrote:
Maybe I'm the only one, but I *really* don't like this exp= thing.
No, you're not the only one, I just couldn't put my finger on the
problem.
First, it does not support multiple languages. Anyone from
Switzerland or (worse) Quebec Canada is going to want to be able to
support more than one language.
Heh, personally, that didn't even occur to me, but I'm notorious for
being self-centered. :) I am going to agree.
Second, I have my doubts that this will ever be widely used either by
SPF publishers or by SPF clients. It smacks of featuritis.
I think part of the problem here is that there is no valid, useful
example purpose. Who is supposed to see it? Must it go into a bounce
message -- and will users all of a sudden start actually reading their
bounce messages (that's the big question)? From the RFC:
Provides a space for the publishing domain to communicate further
information about its policy: for instance, a short message, or a
URL pointing to a longer message. SPF clients SHOULD convey this
message to the SMTP client when rejecting
What kind of further policy could there be other than the policy
described by the actual machine-parsable and machine-usable directives?
If the intent and purpose of the other directives is spelled out,
then a useful human readable text message about policy can be built
up based on those -- perhaps that should be spelled out in the RFC.
Third, sticking this long(?) text in with the rest of the SPF config
means that every client that checks the SPF status will get more DNS
traffic, even if that client doesn't use it.
bandwidth ... always our nemesis, and as such I agree here also. We
should focus on keeping the SPF strings small, to speed parsing and
transfer time and avoid as much delay as possible between connection and
final rejection. Ideally, the addition of SPF shouldn't cause any
significant noticeable delay to someone watching on-the-wire
transactions. Although, multiple DNS transactions don't really help in
that case, but if it the RFC spells out that SPF clients SHOULD grab the
exp and include that in a response to the SMTP client, there's no
incentive to do that, especially if it is not guaranteed that the SMTP
client will use it in a bounce message.
Fourth, there appears to be no quote requirements so this option *has*
to be the final option on the SPF TXT record. People tend to stick
new options on the end and I suspect that a common error is going to
be that what is intended to be an option is going to get swallowed up
into the exp= text.
This is one of my biggest concerns. This stuck out to me immediately,
but I don't have a lot of experience in this RFC-creation arena and
figured everyone knew what they were doing (heh, don't worry, I still
believe that, if my opinion matters). But after reviewing my own lazy
habits, I could see myself having to edit records two or three times
because I forgot that, on top of order being important overall,
something needs to go _last_ too.
My suggestion is to either drop this, or do something along the lines
of most of the other options and have the exp not specify the text,
but rather specify a domain where the text can be found.
Something like "v=spf1 exp:.example.com" would look up the text in
"$(LANG).exp._client_smtp.example.com", where $(LANG) is on of the
standard(?) language tags found in I18N::LangTags::List. So, someone
in Quebec could have both en.exp._client_smtp.example.com and
fr-ca.exp._client_smtp.example.com.
As a side benefit, these text records could be as long as you want
because they would only be used by SPF clients that want them, and
only when they actually *need* them. If the TXT record is too large,
falling back from UDP DNS to TCP is not a problem.
This seems like a good way to go if exp is going to stick around, mainly
because it makes it similar to the other options. Using standard i18n
tags is a great idea, but I'm unfamiliar with how the SPF client would
know which language to grab -- where does the remote SMTP client specify
a language for the SPF client to use? In Quebec, would the SPF client
put both en _and_ fr messages in the response to the STMP client? What
if the SPF admin for a domain hasn't included a certain language? That
is, admins in Quebec could put multiple languages in, but those messages
are not necessarily intended for internal use (ignoring statistics that
would show most people only emailing people who speak the same
language), and you don't necessarily know which language is going to be
asked for. I like being able to generate useful human readable messages
better, as I suggested above, because it keeps the language determinacy
closer to the people who are actually going to read it. And in that
case, it may make sense to have SPF clients tell SMTP clients the full
SPF directive list it used to determine the SPF restrictions (or some
other kind of abbr or code that can be expanded in the local language),
and have the SMTP client generate human readable messages when, and if,
it generates a bounce.
--
Andy Bakun <abakun(_at_)thwartedefforts(_dot_)org>
-------
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.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡