Hello!
On Tue, Dec 07, 2004 at 04:00:27PM -0500, Scott Kitterman wrote:
Microsoft and Sender-ID are a fact of life that we aren't going to change.
I don't like PRA, I don't like their license, and I really don't like them
reusing v=spf1 records. So what. Those are just facts of life. We need to
move forward.
Perhaps.
OTOH, I find especially the latter is more "abusing" than "reusing" the
spf1 records. If I personally (or the company I work for) have nothing
to do with PRA/SenderID, and I publish v=spf1 records only, with the
intention of them being used *as specified* (i.e. for mail from only),
and then I'll find my mail won't work because thisorthat receiving MTA
(or an MUA) abuses my SPF record, I will come to one of these
conclusions:
- remove SPF record, as it yields false positive rejection of mail I send
(or a customer sends)
- adapt the SPF record to PRA - *but*, live in the fear that if we are
at a position that we just reckon with any abuse of the SPF record,
that another MTA/MUA will abuse it in another way, perhaps even
incompatible to the intersection of SPF-classic and PRA I have adapted
to, so I'll have to adapt the record to all those abuses?
I don't like the latter.
And I wouldn't completely like the former, as if the impression is SPF
(v1 at least) risks false positives with a few popular implementations
of receiving MTAs/MUAs (like M$ Exchange, or Outlook...), SPF will
perhaps lose popularity, will perhaps be not used as much as those here
who see it as a good solution for envelope forgeries would like.
If they wanna do sender ID, they can, but they should use their own
records. And the IETF shouldn't make it part of the base infrastructure,
as long as there are silly software patents around it.
If the council is going to take positions, they should be in specific about
SPF or a positive assertion of general principle. For example, saying that
Sender_ID is bad because the license is incompatible with the GPL is true,
but problematic. It's better to say that the SPF Council believes that any
solution must be implementable by both commercial and free software.
Yeah.
And perhaps the Council should state that the records "we" (the
SPF/classic/v1/whatever community) specify should be used according to
exactly these specifications and only these, as otherwise the
functioning can't be guaranteed.
Focus on making SPF better. Don't waste your time tilting at windmills.
As far as Sender-ID goes, I'd support something along the lines of,
"Sender-ID includes mail from protection derived from SPF. The SPF Council
believes that mail from protection is an essential element of e-mail
authentication. To the extent that Sender-ID mail from protection remains
compatible with the pre-existing SPF usage, the SPF Council supports this."
Everyone who understands whats been going on will be able to read between
the lines. Those who don't get it, aren't going to get it anyway, so you
may as well avoid upsetting people.
I don't think we should hide the problems that can hit an SPF adopter
who publishes a v=spf1 record according to the SPF specs if the records
are abused for other checks.
Scott K
Kind regards,
Hannah.