----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Sent: Friday, December 17, 2004 4:32 PM
Subject: [spf-discuss] Re: spf-statement-on-SenderID
There is only one vague reference to the supposed problem of
Sender-ID causing problems when using spfv=1 records - viz:
| SenderID re-purposes the v=spf1 records.
Period. You don't need more info to come to some very simple
and obvious conclusions like "PRA doesn't work behind any SPF
forwarder doing only SRS".
I'm only dealing with SPF - not SRS or anything else.
| This will cause failures in cases where deployed SPF records
| currently work.
Exactly. For similar scenarios look for "Olson objection" in
articles written by Meng, look for "Sympa" in articles written
by Meng, look for "moderated newsgroups", etc.
| Where SenderID breaks the function of existing v=spf1
| records, domain owners will only learn of it when legitimate
| mail is not delivered.
Note the careful wording here: "mail is not delivered". As far
as the sender gets a bounce it's still a normal SMTP situation,
and if the sender deletes all bounces without ever reading them
it's his problem.
But Meng said again and again that PRA is a solution for MUAs,
and MUAs don't bounce, all they can do is delete mail directly
or indirectly. So for PRA on v=spf1 "mail is not delivered"
actually stands for "some legit mails lost".
I don't see any reference to a specific problem here
An enumeration of all potential problems would be far too long.
If you don't like the SES example use something else, how about
"many mailing lists use Errors-To instead of Sender, and this
results in false positives (FAIL) for PRA applications abusing
But actually you can simply sign the SPF pledge, use a linkk to
your spf-help.net/other-protocols.html as your "organization",
and link to the SPF pledge from your chapter about "Sender ID".
The technical details are only relevant for technical experts.
Exactly - and spf-help.net is *not* for experts - it's an atempt to guide
the average sysadmin and/or DNS publisher through the maze that is SPF.
The vast majority of queries are about publishing records, or un-expected
rejections, and that is the area being dealt with.