On Wed, 27 Oct 2004 18:13:32 -0400, Meng Weng Wong
<mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> wrote:
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.
I guess I'm going to have to disagree with Meng and his belief that
there isn't a problem with applying (and evangelizing that this is ok)
PRA to SPF1 records.
Here is a link to a page on pobox holding up examples of how to do
things properly if you are a web generated emailer:
http://spf.pobox.com/webgenerated.html
Applying PRA to either of these approaches should cause mail to be
rejected by the recipient MTA if the domain of the true sender has
published an SPF1 record that makes any sense at all for protecting
the return path.
So what we have is a case of people doing the appropriate things to
conform to the requirements of SPF1 and being held up as examples of
how to do it properly..... and then having the "voice" of SPF saying
that it is ok to apply PRA to the properly published records and
proper way of mailing....that will cause mail to be rejected.
I can only scratch my head in bewilderment. I'm raising this as a
technical/implementation issue, not as a politicial issue. It took
more than 6 months to get buy-in from upper management that we had to
rewrite our systems to conform to SPF. It then took hundreds and
hundreds of hours to implement the changes (publishing the records was
the easy part). And now, even though our implementation is held up as
an example of how to do it.....things will break even though we
conform to the spec.
Mike