Mailing List Archive

On Mon, Oct 25, 2004 at 06:31:40PM -0500, David Crooke wrote:
|
| I hope I haven't started too big of a food fight with my last question :-)
|
| Here goes with the underlying concern, and I'd be interested in a
| pragmatic, objective answer rather than bleeding edge or one that is
| partisan to one standard or another.....

My web page of advice to ESPs is online at http://spf.pobox.com/esps.html

I'd be happy to take feedback and make any changes
necessary. I will also address "what should ESPs do" in my
forthcoming whitepaper which will be officially released at
the MAAWG meeting November 2-3: http://www.maawg.org/

| 1. As an ESP (email marketing service provider), serving clients with a
| wide range of technical skill levels, what should we be doing right now?
|
| a. Continue to sit tight and wait for the SPF / Sender-ID dust to settle
| some more**
| b. Attempt to have individual customers roll out individual SPF records
| for each of their domains, as used in "From:" body headers
| c. Roll out a single SPF record for our bounce handler sending domain,
| as used in the "MAIL FROM:" SMTP command

definitely do this.

| d. Have our email software create an additional "purported responsible
| sender" header and add it to all outbound mail

this is probably a good idea too.

| 2. For option d. above, should we configure these for each client, or
| just use one "convio.net" sender?

either way works.

| Side question: what is the best place to look for
| documentation on how the "sender" address is calculated? I
| understand that the algorithms for SPF-Classic, Caller-ID,
| Sender-ID, SPF 2 all differ subtly.

the specs will make their way online soon. i'll follow up
again when they have a stable URL.

| 3. For whichever of the options is recommended for question 1., which
| DNS record types should we publish:
|
| a. v=spf1
| b. SPF 2.0
| c. "Caller ID style", i.e. _ep.foo.org with XML data
| d. Some combination of the above

(a) only --- all software reading the PRA will read v=spf1.

you can use spf2.0/pra as an override iff the information
for a domain when read in PRA context differs from the
information when read in mail-from context.

i should probably give some examples. but i'm working full
steam on the white paper and i'll all the examples in there :)

| 4. Applying question 1. to "tell a friend about this website"
| functionality, where we are generating email with "From:" addresses from
| all over the internet, option b. is not applicable ... should we do c.
| or d. or should we even consider not putting the user's address in the
| From: and using within a client's domain?

you can either set Sender: to be yourself, or change the
From: to be yourself and put the user's address in the Reply-To.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

In <417D8CDC.4030608@convio.com> David Crooke <dave@convio.com> writes:

> ** a previous poster indicated that Micosoft had more or less
> ** abandoned their efforts, but their PR would suggeste otherwise:
>
> http://www.computerworld.com/softwaretopics/software/groupware/story/0,10801,96923,00.html?nas=PM-96923

I see Meng gave good answers to your other questions. Being the
previous poster, I would like to point out that MS has apparently
abandoned CallerID, while the above link talks about SenderID.
According to that article, MS has released a brand new spec for
SenderID. My understanding is that one of the major changes made with
this new SenderID spec is that it no longer requires the use of SPF2.0
records.


Yes, this is confusing. Sorry.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Mon, 25 Oct 2004 19:38:47 -0400, Meng Weng Wong
<mengwong@dumbo.pobox.com> wrote:
> On Mon, Oct 25, 2004 at 06:31:40PM -0500, David Crooke wrote:

<snip>
>
> | d. Have our email software create an additional "purported responsible
> | sender" header and add it to all outbound mail
>
> this is probably a good idea too.
>
> | 2. For option d. above, should we configure these for each client, or
> | just use one "convio.net" sender?
>
> either way works.
>
<snip>

I think this is a particularly interesting question in light of the
FTC's full support of e-mail authentication as a method of simplifying
enforcement of Can Spam. It is clear that the authors of the law
consider the advertiser to be the responsible party in a commercial
e-mail message, not the "initiator"/ESP. It would seem to me that the
purported responsible sender should be a domain that would lead an
enforcement agency directly to the advertiser, to avoid the necessity
of having to deal with third (fourth?) parties and even court orders.

Not that I disagree that either way works, I'm just commenting on what
I think would be best supported by FTC and what would help ESPs keep
themselves out of conflict.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

From: Ron Schnell Sent: October 25, 2004 10:10 PM

<snip>

|I think this is a particularly interesting question in
|light of the FTC's full support of e-mail authentication as
|a method of simplifying enforcement of Can Spam.
|
|It is clear that the authors of the law consider the
|advertiser to be the responsible party in a commercial
|e-mail message, not the "initiator"/ESP.

<snip>

I disagree. The Act requires the person who initiates a
commercial e-mail to ensure the headers are accurate etc.
while imposing the requirement to include a functioning
opt-out and inclusion of a postal address on the sender of
a commercial e-mail.

The terms initiate (which includes the term procure),
procure and sender are defined in the Act and do not have
the same meaning as understood in common parlance.

A careful reading of the relevant provisions indicates that
an email service provider falls within the scope of the
definition of initiate and may depending on what is
included in the message by the email service provider also
be the sender.

For example many providers include a small signature file
along with a link to their sales page, so that the
recipient knows the name of the provider and if he or she
is interested can check out the provider's site.

As a result, the provider has both initiated the message
and advertised or promoted the providers service or web
site, so falling within the definition of sender.

Besides, what would a provider do if the message has more
than one sender, as that term is defined in the Act.

This is quite possible given how the Act is drafted. This
interpretation was acknowledged by the FTC in its initial
request for comments on the proposed rules to implement the
Act when it asked for thoughts concerning how to deal with
the issue of messages containing multiple advertisements.

See generally sections 3, 4 and 5 of the Act
http://www.learnsteps4profit.com/antispamus.html

The prudent course for a provider is to ensure the FQDN in
the EHELO/HELO and SMTP MAIL FROM are the provider's.

For this reason, MAIL FROM authentication is relatively
benign from an email provider's perspective.

Unfortunately, PRA authentication does pose a problem for
providers and their clients. Clients want to include their
domain in the From line for branding and individual
subscriber white listing purposes.

To ensure best compliance with both Mail From and PRA
authentication requirements, it seems providers now have to
ensure the FQDN in the SMTP SUBMITTER, EHELO/HELO and MAIL
FROM, along with the RFC 2822 From are the same.

In my opinion this is going to be a hassle for people. This
is just the start. By creating a new SMTP identity and
requiring it to match with the RFC 2822 From we have not
even touched on the whole issue of folks who send their own
email through shared servers. Ugh.

Quite honestly, depending on how this whole thing is
implemented, I can see significant problems with large
volumes of solicited email along with important
transactional messages simply not making it, while spammers
continue to break through.

If not dealt with, this will cause a huge uproar.

John

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.779 / Virus Database: 526 - Release Date: 19/10/2004


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

>-----Original Message-----
>From: owner-spf-deployment@v2.listbox.com
>[mailto:owner-spf-deployment@v2.listbox.com]On Behalf Of Meng Weng Wong
>Sent: Monday, October 25, 2004 7:39 PM
>To: spf-deployment@v2.listbox.com
>Subject: Re: [spf-deployment] Practical guidance for ESP's
>
>On Mon, Oct 25, 2004 at 06:31:40PM -0500, David Crooke wrote:
>|
>| 3. For whichever of the options is recommended for question 1., which
>| DNS record types should we publish:
>|
>| a. v=spf1
>| b. SPF 2.0
>| c. "Caller ID style", i.e. _ep.foo.org with XML data
>| d. Some combination of the above
>
>(a) only --- all software reading the PRA will read v=spf1.
>
>you can use spf2.0/pra as an override iff the information
>for a domain when read in PRA context differs from the
>information when read in mail-from context.
>
>i should probably give some examples. but i'm working full
>steam on the white paper and i'll all the examples in there :)
>
Could you at least give us one example of a TXT record that has both a
proper v=spf1 and spf2.0/pra record. Draft-lyon-senderid-core-00.txt is
devoid of examples.

Scott Kitterman

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Tue, Oct 26, 2004 at 08:32:35AM -0400, spf2@kitterman.com wrote:
| Could you at least give us one example of a TXT record that has both a
| proper v=spf1 and spf2.0/pra record. Draft-lyon-senderid-core-00.txt is
| devoid of examples.

Suppose an ESP has been contracted by bigbox.com. The ESP
sends mail using through outmta.esp.com. Bounces and
unsubscribes are directed to bounces.esp.com.

MAIL FROM:<handler-23451@bounces.esp.com>
From: Big Box Stores <nobody@bigbox.com>
Sender: <mailings-for-bigbox@esp.bigbox.com>
Reply-To: <unsubscribe-23451@bounces.esp.com>

If you wanted to distinguish PRA from mail-from scope, I
might recommend the following records:

1 bounces.esp.com
2 "v=spf1 a:outmta.esp.com"
3 "spf2.0/pra -all"
4
5 bigbox.com
6 "v=spf1 a:corp.bigbox.com -all"
7
8 esp.bigbox.com
9 "v=spf1 -all"
10 "spf2.0/pra a:outmta.esp.com"

Line 2 is for the MAIL FROM. The default is "?all" because
for this mailing we're more concerned about whitelisting
than about forgery prevention.

Line 3 is for the PRA. This states: We'll never use the
domain bounces.esp.com in a From: or Sender: header.

Line 6 is for the client, bigbox.com, which outsources all
of its mailings and only uses bigbox.com for corporate
accounts. It is more concerned about phishing than false
positives due to forwarding, so it sets -all.

Lines 9 and 10 are for the outsourced relationship domain
esp.bigbox.com. It indicates that ESP is a contractor for
bigbox.com. esp.bigbox.com is never used in the
return-path, so the v=spf1 record is -all (line 9). But it
is used in the Sender header, so there is an override by
spf2.0/pra that allows outmta.esp.com (line 10). It does
not end in a -all because again for this mailing we're more
concerned about whitelisting than about forgery prevention.

Incidentally, in this example bigbox.com's DNS admins have
delegated esp.bigbox.com to esp.com, so esp.com's
nameservers are the ones that actually answer
authoritatively for esp.bigbox.com. This makes it easier
for esp.com to fiddle with esp.bigbox.com's SPF records and
whatever else. The alternative to delegation is the
infrequent and troublesome need for ESP to call BigBox once
every eighteen months when the DNS details change.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

>-----Original Message-----
>From: owner-spf-deployment@v2.listbox.com
>[mailto:owner-spf-deployment@v2.listbox.com]On Behalf Of Meng Weng Wong
>Sent: Tuesday, October 26, 2004 9:41 AM
>To: spf-deployment@v2.listbox.com
>Subject: Re: [spf-deployment] Practical guidance for ESP's
>
>
>On Tue, Oct 26, 2004 at 08:32:35AM -0400, spf2@kitterman.com wrote:
>| Could you at least give us one example of a TXT record that has both a
>| proper v=spf1 and spf2.0/pra record. Draft-lyon-senderid-core-00.txt is
>| devoid of examples.
>
>Suppose an ESP has been contracted by bigbox.com. The ESP
>sends mail using through outmta.esp.com. Bounces and
>unsubscribes are directed to bounces.esp.com.
>
> MAIL FROM:<handler-23451@bounces.esp.com>
> From: Big Box Stores <nobody@bigbox.com>
> Sender: <mailings-for-bigbox@esp.bigbox.com>
> Reply-To: <unsubscribe-23451@bounces.esp.com>
>
>If you wanted to distinguish PRA from mail-from scope, I
>might recommend the following records:
>
> 1 bounces.esp.com
> 2 "v=spf1 a:outmta.esp.com"
> 3 "spf2.0/pra -all"
> 4
> 5 bigbox.com
> 6 "v=spf1 a:corp.bigbox.com -all"
> 7
> 8 esp.bigbox.com
> 9 "v=spf1 -all"
>10 "spf2.0/pra a:outmta.esp.com"
>
>Line 2 is for the MAIL FROM. The default is "?all" because
>for this mailing we're more concerned about whitelisting
>than about forgery prevention.
>
>Line 3 is for the PRA. This states: We'll never use the
>domain bounces.esp.com in a From: or Sender: header.
>
>Line 6 is for the client, bigbox.com, which outsources all
>of its mailings and only uses bigbox.com for corporate
>accounts. It is more concerned about phishing than false
>positives due to forwarding, so it sets -all.
>
>Lines 9 and 10 are for the outsourced relationship domain
>esp.bigbox.com. It indicates that ESP is a contractor for
>bigbox.com. esp.bigbox.com is never used in the
>return-path, so the v=spf1 record is -all (line 9). But it
>is used in the Sender header, so there is an override by
>spf2.0/pra that allows outmta.esp.com (line 10). It does
>not end in a -all because again for this mailing we're more
>concerned about whitelisting than about forgery prevention.
>
>Incidentally, in this example bigbox.com's DNS admins have
>delegated esp.bigbox.com to esp.com, so esp.com's
>nameservers are the ones that actually answer
>authoritatively for esp.bigbox.com. This makes it easier
>for esp.com to fiddle with esp.bigbox.com's SPF records and
>whatever else. The alternative to delegation is the
>infrequent and troublesome need for ESP to call BigBox once
>every eighteen months when the DNS details change.
>
Thanks.

DNS question then...

Can, for example, lines 2 and 3 be published in a single TXT record:

"v=spf1 a:outmta.esp.com ?all spf2.0/pra -all"

or does it have to be two:

"v=spf1 a:outmta.esp.com"
"spf2.0/pra -all"

The reason I ask is that some DNS providers (mine for instance) only allow a
single TXT record per domain. Trying to add a second returns an error.

While I know that the underlying DNS programs support multiple TXT records
per domain, if the user interface doesn't support it, the user is out of
luck.

Scott Kitterman

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Tue, Oct 26, 2004 at 09:49:52AM -0400, spf2@kitterman.com wrote:
|
| DNS question then...
|
| Can, for example, lines 2 and 3 be published in a single TXT record:
|
| "v=spf1 a:outmta.esp.com ?all spf2.0/pra -all"

that would've been nice, but it would've meant too many
major changes to the spf1 spec.

| or does it have to be two:
|
| "v=spf1 a:outmta.esp.com"
| "spf2.0/pra -all"
|
| The reason I ask is that some DNS providers (mine for instance) only allow a
| single TXT record per domain. Trying to add a second returns an error.

this was another reason I would've been in favour of doing
scoped redirects with a %{e} macro. But I don't know if
that would really help in this case.

In practice, I am very doubtful that any domain which is
being administered through a web interface will need
different records for different scopes ---

| >
| > 1 bounces.esp.com
| > 2 "v=spf1 a:outmta.esp.com"
| > 3 "spf2.0/pra -all"
| > 4

If you had to do that in a single line, your options are:

"v=spf1 a:outmta.esp.com ?all"
"v=spf1 a:outmta.esp.com -all"

How to choose between these two alternatives?

What matters more for your domain: fighting phishing, or
getting mail through in a world with potential false
positives due to forwarding (and the degree to which this is
a problem is still under debate. Wayne has been very
informative about this in the past.)

If you're citibank.com, you're more concerned about fighting
phishing.

If you're bounces.esp.com, you're more concerned about false
positives.

If you can't decide, you end up with "~all" until a major
phishing attack hits, and then you scramble to change it to
"-all" and you ask yourself who set the TTL to 86400. :)

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

Meng Weng Wong wrote:

>On Mon, Oct 25, 2004 at 06:31:40PM -0500, David Crooke wrote:
>|
>| I hope I haven't started too big of a food fight with my last question :-)
>|
>| Here goes with the underlying concern, and I'd be interested in a
>| pragmatic, objective answer rather than bleeding edge or one that is
>| partisan to one standard or another.....
>
>My web page of advice to ESPs is online at http://spf.pobox.com/esps.html
>
>
This stuff looks good for ESPs with larger clients, who would also be
using a dedicated IP for each client's outbound traffic and hence would
be set up to support "pre-MARID" old-style reverse lookup checks using
PTR records.

For us, with a larger number of smaller and less technically
sophisticated customers with no full time IT people, it would not be
tenable to ask them to set up and use dedicated email marketing
(sub)domains - we also host websites under customer hostnames, and just
talking them through getting the DNS for that correct can be a challenge :-)

I'd appreciate comments on this adaptation approach:

1. Keep the bounce address (MAIL FROM: aka Return-Path:) on a convio.net
hostname, and publish spf1 records for that, ending in ?all
2. Have customers publish appropriate spf1 records with a "+a" for our
outbound servers.
3. Add a "Sender:" header to "tell-a-friend" type emails that are sent
on behalf of a third party end user


Also, am I right in taking the understanding that "PRA style" SPF
checkers (which may or may not exist out there in the wild) will check
the PRA against the spf1 records for that domain if nothing else is
available?

Cheers
Dave

--
David Crooke, Chief Technology Officer
Convio Inc. - the online partner for nonprofits
11921 N Mopac Expy, Austin TX 78759
Tel: (512) 652 2600 - Fax: (512) 652 2699



-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Tue, Oct 26, 2004 at 11:02:14AM -0500, David Crooke wrote:
> I'd appreciate comments on this adaptation approach:
>
> 1. Keep the bounce address (MAIL FROM: aka Return-Path:) on a convio.net
> hostname, and publish spf1 records for that, ending in ?all
> 2. Have customers publish appropriate spf1 records with a "+a" for our
> outbound servers.
> 3. Add a "Sender:" header to "tell-a-friend" type emails that are sent
> on behalf of a third party end user

If you keep the bounce address on convio.net, and publish spf records
for that domain (and your HELO domains..) you're fine regarding spf1. As
regards pra.. You can ask your clients to put "spf2.0/pra ?all" in
there, and you won't have any trouble with pra. The pra impelementations
should look at the spf2.0/pra record if it's available.

> Also, am I right in taking the understanding that "PRA style" SPF
> checkers (which may or may not exist out there in the wild) will check
> the PRA against the spf1 records for that domain if nothing else is
> available?

I believe you are right, unfortunatelly.

Koen

--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

In the following news release:

http://www.microsoft.com/presspass/features/2004/oct04/10-25Sende
rID.asp

Ryan Hamlin , general manager of Microsoft's Safety
Technology and Strategy Group, is quoted as saying:

|The call to action is really for companies first to
|publish their Sender ID record. There is a tool on our
|site www.microsoft.com/senderid) that will help create
|that record. Once created, companies need to publish that
|information in the text record in DNS. For senders, this
|is the only thing they need to do.

However, this wizard is not working properly and only
produces records which support the pra scope.

I believe this is an issue which needs to come out at the
up coming FTC summit.

Some in the open source community don't like spf2.0 because
it supports PRA which is arguably flawed and subject to an
unacceptable patent license.

Microsoft on the other hand does not support MAIL FROM.

So, Microsoft puts together a wizard which produces records
which does not comply with the specification for spf2.0 and
only supports pra.

At the same time, the open source community, including
spf.pobox.com supports a wizard which does produce records
which comply with the specification for v=spf1, but does
not produce records which support the specification for
spf2.0

ESPs, ISPs and others are going to want to publish records
which work for both MAIL FROM and PRA.

It is this kind of stuff which is going to cause a mess.

This situation belies the politically correct statements
found in the opening paragraph of Sender ID: Authenticating
Email about people coalescing around one standard.

It also points out the underlying fly in the ointment,
being Microsoft's patent license.

If people are serious, I suggest it would help if the FTC
knocked a few heads together.

Otherwise, people will have two publish two records,
one for receivers working with SPF and one for receivers
working with Sender ID.

Of course maybe that is what people want?

John

John Glube
Toronto, Canada



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.779 / Virus Database: 526 - Release Date: 19/10/2004


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Tue, Oct 26, 2004 at 11:02:14AM -0500, David Crooke wrote:
|
| I'd appreciate comments on this adaptation approach:
|
| 1. Keep the bounce address (MAIL FROM: aka Return-Path:) on a convio.net
| hostname, and publish spf1 records for that, ending in ?all
| 2. Have customers publish appropriate spf1 records with a "+a" for our
| outbound servers.
| 3. Add a "Sender:" header to "tell-a-friend" type emails that are sent
| on behalf of a third party end user
|

Sorry, I just realized I never answered this question.

1) yes, or don't even end in ?all because falling off means neutral.

2) tell your customers to "include:" a special subdomain you
set up for them, rather than doing an a: directly.

3) yes, add a Sender: header.

|
| Also, am I right in taking the understanding that "PRA style" SPF
| checkers (which may or may not exist out there in the wild) will check
| the PRA against the spf1 records for that domain if nothing else is
| available?
|

yes, that is correct; that is what microsoft intends to do.

if you have a problem with this, publish a null spf2.0/pra
record. that will ensure it won't read the v=spf1 record.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

Meng Weng Wong wrote:

> yes, that is correct; that is what microsoft intends to do.

MS intends to break all published SPF standards and policies...

> if you have a problem with this, publish a null spf2.0/pra

...but there's a simple workaround, just publish another empty
spf2.0/pra record. And don't forget to inform the publishers
of several hundred thousands v=spf1 policies that they have to
add an empty record if they don't want their mail to be deleted
by non-conformant MS MUAs resp. rejected by MS MTAs.

Please submit the next PRA-draft directly to the RfC-editor on
April 1 2005, that's the only way to get it published as RfC,
as long as there's no "worst common practice" series of RfCs.


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

>-----Original Message-----
>From: owner-spf-deployment@v2.listbox.com
>[mailto:owner-spf-deployment@v2.listbox.com]On Behalf Of Meng Weng Wong
>Sent: Tuesday, October 26, 2004 10:18 AM
>To: spf-deployment@v2.listbox.com
>Subject: Re: [spf-deployment] Practical guidance for ESP's
>
>
>On Tue, Oct 26, 2004 at 09:49:52AM -0400, spf2@kitterman.com wrote:
>|
>| DNS question then...
>|
>| Can, for example, lines 2 and 3 be published in a single TXT record:
>|
>| "v=spf1 a:outmta.esp.com ?all spf2.0/pra -all"
>
>that would've been nice, but it would've meant too many
>major changes to the spf1 spec.
>
>| or does it have to be two:
>|
>| "v=spf1 a:outmta.esp.com"
>| "spf2.0/pra -all"
>|
>| The reason I ask is that some DNS providers (mine for instance)
>only allow a
>| single TXT record per domain. Trying to add a second returns an error.
>
>this was another reason I would've been in favour of doing
>scoped redirects with a %{e} macro. But I don't know if
>that would really help in this case.
>
>In practice, I am very doubtful that any domain which is
>being administered through a web interface will need
>different records for different scopes ---
>
There is at least one.

Well, I understand from another thread that Yahoo Groups will fail PRA. I
use Yahoo Groups. I guess I need to change my SPF record from -all to ?all
if anyone actually starts checking PRA. Of course given my shared MTA
problem, that would pretty much turn SPF into a no-op for me. Surely this
isn't good?

The problem is not limited to people with complex situations.

Scott Kitterman

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com