Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] SPF info



"Stephen J. Turnbull" <stephen@example.com> writes:

>>>>>> "Evan" == Evan Monroig <evan.monroig@example.com> writes:
>
>     Evan> there is SenderID, a Microsoft protocol derived from SPF and
>     Evan> defined is RFC 2822.
>
> That must be a typo, RFC 2822 is the current proposed standard to
> succeed RFC 822 as STD 11, the standard that defines message header
> syntax and semantics.

Sorry I checked again, it is RFC 4406. I copied the name a little too
fast. My bad.

>     Evan> The article is from September 2004, and I know from
>     Evan> openspf.org that the MARID working group "failed" (whatever
>     Evan> that means. My guess is that they couldn't produce the
>     Evan> standard that the group was set up for).
>
> That's usually what is meant.  The way that the process works is that
> ad hoc working groups put together drafts with a 6 month expiration
> date, and publish them as "internet drafts".  A given group may have
> several drafts available at any given time, so this is clearly not yet
> a candidate for a standard.  Once the group agrees on a single draft,
> there is some kind of vote and if passed, it becomes an RFC.

Thank you very much for the explanation, I didn't know about this
process. 

>     Evan> So to me, the story is that the current standard for email
>     Evan> sender domain verification is SPF,
>
> No.  There is an implementation of email sender domain verification
> called "SPF", and it has a standard, RFC 4408.  There may be other
> ways of accomplishing similar things which are also standard, eg,
> SenderID and DomainKeys.
>
> Why?  Because you may have different environments in mind.  Eg, IIRC,
> SPF is transparent to MTA topology, only the original sender is
> verified.  DomainKeys assumes a network of trust, so that when a
> message from A to C is relayed by B, B uses B's domain key to assure C
> that B trusts A.  If SPF uses a patent, then mailing lists can ignore
> it.  This is not true of DomainKeys, again IIRC.

Ok. I didn't know about DomainKeys (so many things new ^^. I will have a
look).

Concerning the multiple standards, as I wrote in my previous email,
there is a controversy between SPF and SenderID, where the SenderID
specification is not compatible with the SPF specification on one
point.

I don't remember which point exactly, but this raises a question. If we
have multiple standards and there are compatibility problems, then
different people will have different interpretations, and the utility of
those standards decrease.

Also, as far as I know, SPF will become really useful only if a vast
majority of domain owners use it. If there are different standards for
the same purpose, it might confuse wide acceptance of those standards.

>     Evan> and that for individual sender verification, we'd better use
>     Evan> GPG...
>
> Yes.  But unlike domain verification, it's not very well-defined in
> the Internet mail context.  Consider "sender" vs. "author" for
> starters, and then look at various forms of resending such as mailing
> lists or news-to-mail gateways.  GPG is much more appropriate to
> author verification, I should think.

Thanks for the clarification. Indeed, what I had in mind was "author"
and not "sender".

Thanks again,

Evan


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links