On Wed, Oct 27, 2004 at 10:06:56PM +0200, Koen Martens wrote:
|
| It sort of depends. Now that microsoft is using v=spf1 to do PRA
| checking if no spf2.0/pra record is present, you might get into trouble
| if your v=spf1 record does not cover the PRA stuff. There is however a
| simple solution: just publish "spf2.0/pra ?all" next to your v=spf1
| record, this will simply make sure pra is not applied to your domain.
|
| Of course, the less simple solution is to make sure that your v=spf1 record
| also works for PRA.
|
I see it as MS's responsibility to ensure that PRA works
well. It looks to me like Outlook and Hotmail are committed
to implementing it, so MS will have to figure out the
workarounds for any bugs in the PRA algorithm. I don't know
of any MTA vendors who are implementing PRA checking at this
time. Which kinda makes sense, because PRA is for MUAs, and
MUAs are ... mostly Outlook. 2821.mail-from is for MTAs,
and they're quite happy with SPF Classic.
SPF Classic / Mail-From, MTA, opensource, unix
Caller ID / PRA, MUA, commercial, Microsoft
spot the trend?
Fortunately with the merged Sender ID, we are free to do
SPF Classic and MS is free to do PRA and both are free to
say we're doing Sender ID. And that removes industry
confusion. Enough to move forward, at least.
As the first publisher of an SPF record, pobox.com does not
plan to make any changes in regard to PRA. We will not be
publishing an "spf2.0/pra ?all" record because we feel that
there is no need to override our spf1 record. We do this
knowing full well that MS software will read the record in
PRA context.
Unless, of course, it turns out that MS PRA readers have
some kind of non-spec-compliant syntax bug; only then would
we have to publish "spf2.0/pra". But, assuming this doesn't
happen, I think it's a good thing for MS to evangelize
v=spf1 records. It makes the story easier for publishers
who may not be as technically skilled as we are.