Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alessandro Vesely wrote:
> Michael Deutschmann wrote:
> > That said, I believe making reject-on-SPF-fail a MUST is a bad idea,
> > [...] And recipients who have whitelisted all forwarders are very
> > interested to make that distinction.
>
> How can a recipient whitelist all forwarders? That seems a daunting
> task, and requiring it may hinder setting up new mail servers.
>
> Having shared lists of "reputable" forwarders available on the web has
> the same limitations of DNSBLs, that SPF was supposed to overcome.

Forwarder whitelisting is supposed to be a local and subjective thing, not
a global undertaking. You're absolutely right that the latter wouldn't
work.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhS/lwL7PKlBZWjsRAkXEAKDEhbWCMrsuG4tu0BuO8ss7tbjLVACgine3
IjV/m5B6wavz6foR9emA93I=
=eOKr
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83929247-54baf9
Powered by Listbox: http://www.listbox.com

Julian,

I appreciate your explanation to Alessandro, as it better clarifies
the thinking behind not requiring actions on the receiver side in the
specification for me. Even so, I think his is point is well taken
(unless I'm missing something else), in that offering recommendations
in RFC specs is not unusual. Simply couch them in words like
"should" or "may".

If there is an underlying reason why "some things are better left
unspecified" that you can either share here or simply assure me is
true, but not for public consumption, I'll leave this issue entirely
and accept what you say on this point without additional questions.

Best,

AlanM
The Commerce Company
TZ.Com - Travel Zippy


At 01:33 PM 1/9/2008, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Alessandro Vesely wrote:
> > Julian Mehnle wrote:
> > > I'd really like to avoid telling receivers what to do with "Fail".
> >
> > I beg your pardon, but I don't understand this point. Besides that,
> > as you say, its very name tells what to do, the purpose of a spec
> > is to formally tell what to do, isn't it?
>
>SPF, "Sender Policy Framework", is a standardized way to declare your mail
>sending policies to receivers, i.e., through which hosts you send and
>through which you don't send. The main aspect of the SPF spec is to
>define how to construct these declarations and what they mean. What it
>does NOT define is how receivers should react to those declarations and
>to the results of evaluating them (with very few exceptions like "Neutral
>must be treated exactly like None").
>
>If you observe what e-mail receivers are doing in the wild, you'll quickly
>notice that they frequently violate all kinds of RFCs because it turns
>out better for them that way (some violations being reasonable, others
>merely due to stupidity of course). So about two years ago, when we were
>finalizing the SPF spec, we deliberately decided against requiring
>receivers to react in specific ways. Choosing the best universal
>behavior to put in the spec is very difficult, and many receivers are
>going to ignore it anyway.
>
>What would you think of a law that required you, whenever you encountered
>a false banknote, to stop whatever you were doing and bring it to the
>central bank AT ONCE? Lawmakers might have thought it would be a good
>idea, but those subject to the law might often find themselves in a
>completely different position.
>
> > Perhaps, you mean that telling receivers what to do after various
> > checks should be the subject of a separate rfc?
>
>Some things are better left unspecified, best practice recommendations
>notwithstanding.
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.6 (GNU/Linux)
>
>iD8DBQFHhS+KwL7PKlBZWjsRAmIqAKC9c7OXVIqYbwDSSRWI+sATFHD1PACg8qn9
>rDsntyf3gacKJ1kja1tM/to=
>=Hqfq
>-----END PGP SIGNATURE-----
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org
>Archives: http://v2.listbox.com/member/archive/735/=now
>RSS Feed: http://v2.listbox.com/member/archive/rss/735/
>Modify Your Subscription:
>http://v2.listbox.com/member/?&
>Powered by Listbox: http://www.listbox.com


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83944054-52612f
Powered by Listbox: http://www.listbox.com

On Wed, Jan 09, 2008 at 08:41:26PM +0100, Alessandro Vesely wrote:

> >That said, I believe making reject-on-SPF-fail a MUST is a bad idea, [...]
> >And recipients who have whitelisted all forwarders are very interested to
> >make that distinction.
>
> How can a recipient whitelist all forwarders? That seems a daunting task,
> and requiring it may hinder setting up new mail servers.

If 'X' is the original sender, and 'Y' is to where a mail was sent,
and 'Z' is where mail eventually ends up:

Y knows whereto it forwards mail. The same person should, at Z, make
sure Y is whitelisted.

And maybe X->Y->Z is not the only path. Perhaps there's also P->Q->Z,
as well as A->B->Z.

Now Y,Q,B are all forwarders to be whilelisted by Z. I think that
is what Michael ment.

Alex

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83953003-ff999c
Powered by Listbox: http://www.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

WebMaster@commerco.net wrote:
> I appreciate your explanation to Alessandro, as it better clarifies
> the thinking behind not requiring actions on the receiver side in the
> specification for me. Even so, I think his is point is well taken
> (unless I'm missing something else), in that offering recommendations
> in RFC specs is not unusual. Simply couch them in words like
> "should" or "may".

Understood. However the specification is already making such a suggestion
for receivers' reaction to the "Fail" result:

| The checking software can choose to mark the mail based on this or to
| reject the mail outright.

I don't have a problem with such soft-talk. What I am against is making
one reaction or the other _mandatory_.

> If there is an underlying reason why "some things are better left
> unspecified" that you can either share here or simply assure me is
> true, but not for public consumption, I'll leave this issue entirely
> and accept what you say on this point without additional questions.

There's no secret magic at work here. I'm merely trying to get my point
across that strictly specifying some things is counter-productive.
You're free to dissent.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhUGBwL7PKlBZWjsRApyLAJ9aCWRA2/UhRTVjhudEODEfYiVJTwCfW18b
22pXCuSr9I9rrH2NnE41HKI=
=fCCm
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83958406-3d3ebe
Powered by Listbox: http://www.listbox.com

Julian,

At 02:49 PM 1/9/2008, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>WebMaster@commerco.net wrote:
> > I appreciate your explanation to Alessandro, as it better clarifies
> > the thinking behind not requiring actions on the receiver side in the
> > specification for me. Even so, I think his is point is well taken
> > (unless I'm missing something else), in that offering recommendations
> > in RFC specs is not unusual. Simply couch them in words like
> > "should" or "may".
>
>Understood. However the specification is already making such a suggestion
>for receivers' reaction to the "Fail" result:
>
>| The checking software can choose to mark the mail based on this or to
>| reject the mail outright.

Well, that is certainly fine. I guess my concern stemmed from how
the mail was rejected... again getting back to the bounce
issue. While common sense certainly suggests that no bounce should
occur, I was just concerned that some might not follow common sense.

>I don't have a problem with such soft-talk. What I am against is making
>one reaction or the other _mandatory_.

Agreed.

> > If there is an underlying reason why "some things are better left
> > unspecified" that you can either share here or simply assure me is
> > true, but not for public consumption, I'll leave this issue entirely
> > and accept what you say on this point without additional questions.
>
>There's no secret magic at work here. I'm merely trying to get my point
>across that strictly specifying some things is counter-productive.
>You're free to dissent.

lol. Thanks, though I really do try not to be a trouble maker, I'm
just an interested domain holder wanting to make sure I get the best
level of protection I can against misuse and identity theft of my
domains and the consequential headaches from email resources being
overtaxed. ;-)

And by the way, I do agree that making things mandatory on the
receiver side is entirely counterproductive (and likely impossible or
the entire SMTP/POP3 environment would probably have been replaced
with something else by now).

That said, placing suggestions as to how to implement SPF does not
seem too problematic and will help coders do a better job of
following the intent of a specification. Still doing so is always
something of a balancing act which is subjective and bound to cause
some dissent.

Best,

AlanM
The Commerce Company
TZ.Com - Travel Zippy


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83972116-02bebd
Powered by Listbox: http://www.listbox.com

Alessandro Vesely wrote:

> I apologize if that has been answered already

No "answer", but "related", some days ago Daryl posted
lots of interesting things GMail might do with a FAIL:

| I'm utterly amazed that no one has yet to mention the
| value in getting the DATA of a spam.

| If you, however you wish, generate signatures of spam
| originating from a bunch of dynamic IPs and then use
| those signatures against mail received from IPs that
| you're not sure if they're dynamic or not you can easily
| identify spam (coming from the not known to be dynamic
| IPs) that you've already seen copies of from dynamic
| IP'd hosts. You would not be able to do this if you
| didn't accept the DATA from the dynamic hosts.

| It's free, shall I say, DATA, for their anti-spam
| systems. If they can afford the bandwidth (and I have
| no reason to believe that they can't) then why not?
| Besides, there has been no evidence presented that says
| that they don't, after accepting the same spam from the
| same host a bunch of times, start ignoring such hosts
| for some period of time.
http://permalink.gmane.org/gmane.mail.spam.spf.discuss/23755

Thinking about this, GMail could roll their own SURBL with
the FAILing and other DATA. The real SURBL has some delay,
for one of their sources (spamcop) spam has to be reported,
identified spam-URIs have to arrive at SURBL, where they
are counted and double-checked against a SURBL white list,
verified spam-URIs are added to SURBL, huge users need to
rsync SURBL (e.g. four times per hour), and the overall
processing might add up to more than a hour.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=84041346-0e41ba
Powered by Listbox: http://www.listbox.com

Julian Mehnle wrote:
> Alessandro Vesely wrote:
>> Julian Mehnle wrote:
>>> I'd really like to avoid telling receivers what to do with "Fail".
>> I beg your pardon, but I don't understand this point.
>
> SPF, "Sender Policy Framework", is a standardized way to declare your mail
> sending policies to receivers, i.e., through which hosts you send and
> through which you don't send. The main aspect of the SPF spec is to
> define how to construct these declarations and what they mean. What it
> does NOT define is how receivers should react to those declarations and
> to the results of evaluating them (with very few exceptions like "Neutral
> must be treated exactly like None").

That makes sense. I would stress that SPF also exerts to make sure that
those declarations are authored by the subjects who have the legal rights
to do so.

>> Perhaps, you mean that telling receivers what to do after various
>> checks should be the subject of a separate rfc?
>
> Some things are better left unspecified, best practice recommendations
> notwithstanding.

I beg to disagree. A fuzzy definition is not helpful when it comes to
tools one needs to rely upon. RFCs should also provide terms that can
be used in legal writings aimed at granting civil rights.

SPF allows domains owners to state they bear no responsibility for
messages that FAIL to comply with the relevant policy, including
implied authorship and possible effects on the domains' reputation.
Then, who should be held responsible for the consequences of
delivering FAILed messages to an end user?

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=84164820-2c5d29
Powered by Listbox: http://www.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alessandro Vesely wrote:
> SPF allows domains owners to state they bear no responsibility for
> messages that FAIL to comply with the relevant policy, including
> implied authorship and possible effects on the domains' reputation.
> Then, who should be held responsible for the consequences of
> delivering FAILed messages to an end user?

Who cares as long as it's not the owner of the domain that was forged?
It's not for the domain owner or for _us_ to assign responsibility for
that case.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhlPawL7PKlBZWjsRAhDgAJ990bERmUOjWf3pPcDB2fJtgulrkQCeIbtW
+7sxYNGwu2cZxLpixGXgEl4=
=yCz+
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=84328975-adb1c5
Powered by Listbox: http://www.listbox.com

On Thu, 10 Jan 2008, Julian Mehnle wrote:

> > Then, who should be held responsible for the consequences of
> > delivering FAILed messages to an end user?
>
> Who cares as long as it's not the owner of the domain that was forged?
> It's not for the domain owner or for _us_ to assign responsibility for
> that case.

Ultimately, some bozo will file suit when their identity is stolen
because they responded to an SPF FAIL message from their bank.
The courts will decide for whoever has the most money for lawyers
(hopefully the bank in this case), but we can certainly discuss what the
decision *ought* to be.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=84335507-963876
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:

> Ultimately, some bozo will file suit when their identity is stolen
> because they responded to an SPF FAIL message from their bank.

> The courts will decide for whoever has the most money for lawyers
> (hopefully the bank in this case), but we can certainly discuss
> what the decision *ought* to be.

The bank would feel more comfortable with "standards track" than
"experimental" in this case, assuming that the careless receiver
pulls that as excuse, and the court is willing to accept it.

Technically the difference is zilch, nobody is forced to check SPF,
to publish FAIL, or to reject FAIL, no matter what the status of
the RFC is, but when lawyers enter the picture it can get weird.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=84584058-0f25a8
Powered by Listbox: http://www.listbox.com