Mailing List Archive

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

Alessandro Vesely wrote:
> The current paragraph reads
>
> 2.5.4. Fail
>
> A "Fail" result is an explicit statement that the client is not
> authorized to use the domain in the given identity. The checking
> software can choose to mark the mail based on this or to reject the
> mail outright.
>
> I'd rather see
>
> A "Fail" result is an explicit statement that the client is not
> authorized to use the domain in the given identity. The checking
> software MUST reject the mail outright.
>
> Marking may allow messages with abused names to hit users. SPF should
> avoid exactly that. There are no false positives, since the domain
> owner is the direct origin of such "explicit statement". (Yes, there
> may be errors in the SPF setup, that's why SOFTFAIL exists. See next
> post.)

The problem with mandating receiver policy is that receivers are going to
ignore it at will. Receivers will always do what they think is best for
them.

The current wording merely suggests possible reactions to the "Fail"
result but does not mandate anything. I think it's better that way.

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

iD8DBQFHf2n1wL7PKlBZWjsRArjpAJ4smrsz+pPM8x+Nhv8BSr55BtnUgACeNwoE
NfHDInI8QHFY3dVoiKv1lhI=
=kefx
-----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=82136607-1611f8
Powered by Listbox: http://www.listbox.com

On Sat, 5 Jan 2008, Allesandro Vesely wrote:
> A "Fail" result is an explicit statement that the client is not
> authorized to use the domain in the given identity. The checking
> software MUST reject the mail outright.
>
> Marking may allow messages with abused names to hit users. SPF should
> avoid exactly that. There are no false positives, since the domain
> owner is the direct origin of such "explicit statement". (Yes, there
> may be errors in the SPF setup, that's why SOFTFAIL exists. See next
> post.)

I strongly disagree with this. It effectively forbids the client from
taking measures to mitigate traditional-forwarding false positives.

This relates to the key issue I tried to bring up during the last SPF
election. Many SPF partisans seem to want to rush receiverside SPF
deployment, getting entire ISPs to move to a reject-on-SPF-fail-policy
all at once, disregarding the FP risk caused by traditional forwarders.
They hope that, confronted with a unified wall of SPF-implementing
recipients, forwarders will give up the simple traditional forwarding
methods and adopt SRS.

I think this is folly. It's a chicken game, with four states:

1A - forwarders use SRS, recipients do not enforce SPF
1B - forwarders use SRS, recipients enforce SPF
2A - forwarders operate traditionally, recipients do not enforce SPF
2B - forwarders operate traditionally, recipients enforce SPF

We are presently in state 2A, and would like to reach 1B. The forwarders
generally aren't willing to move to 1A, so we can only either remain in 2A
or move to 2B. 2B is the state where the false positives occur.

True, the forwarders have less to lose by moving to SRS than recipients
have to gain by deploying SPF (after the forwarders give up). But it's
the forwarders, not the recipients who have the *power* here. They'll
probably just tough out state 2B until the recipients give up and roll
back to state 2A.

But that's not the real problem, for there is a third party -- the
ultimate sender. The sender only cares about avoiding state 2B, and can
unilaterally force a rollback to state 2A by simply *not publishing a -all
SPF record*.

It's very bad if the sender does this. If an individual recipient gives
up, only he is affected. But there's also an elite class of recipients
who can get the benefits of state 1B by enumerating all forwarders and
exempting them from local SPF checking. If the sender gives up, these
innocent elite users *also* get knocked back into a virtual state 2A.

Your statement -- ``There are no false positives, since the domain owner
is the direct origin of such "explicit statement".'' is basically saying
that it's the duty of the sender to retreat from SPF unless he wants to
accept responsiblity for forwarding false positives.

Since sender-SPF deployment is far more critical than receiverside-SPF
deployment, I call that a destructive stand.

(I think the way forward is to make forwarder-whitelisting easier, so
that eventually everyone can join the elite class who can deploy
receiverside-SPF safely.)

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
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=82139862-af652b
Powered by Listbox: http://www.listbox.com

Michael Deutschmann <michael@talamasca.ocis.net> writes:

> I think this is folly. It's a chicken game, with four states:
>
> 1A - forwarders use SRS, recipients do not enforce SPF
> 1B - forwarders use SRS, recipients enforce SPF
> 2A - forwarders operate traditionally, recipients do not enforce SPF
> 2B - forwarders operate traditionally, recipients enforce SPF

3 - forwarders use their own address in the RFC2821 Mail From.

If A sends a mail to B and B forwards it to C, it is B not A who is
sending the mail to C. Once B (or rather a server referenced in B's MX
records) has accepted the mail during the SMTP session, B has also
accepted responsibility to deliver the mail[1]. So any delivery problems
between B & C should be reported to (and resolved by) B not A.

[1] And if C further forwards it to D, then C takes over responsibility
to deliver it.


-------------------------------------------
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=82143505-e92f3b
Powered by Listbox: http://www.listbox.com

On Sat, 5 Jan 2008, Graham Murray wrote:
> Michael Deutschmann <michael@talamasca.ocis.net> writes:
> > I think this is folly. It's a chicken game, with four states:
> >
> > 1A - forwarders use SRS, recipients do not enforce SPF
> > 1B - forwarders use SRS, recipients enforce SPF
> > 2A - forwarders operate traditionally, recipients do not enforce SPF
> > 2B - forwarders operate traditionally, recipients enforce SPF
>
> 3 - forwarders use their own address in the RFC2821 Mail From.

Okay, I was lazy and said "use SRS" when I really meant "do anything to
the MAIL FROM: so that SPF won't fault it". So your 3 is just a minor
variation on 1A/1B.

Still, this brings up one thing that I'd probably do if called to
forward. Rather than do either traditional forwarding or SRS, I'd adopt a
strategy I call "Sham SRS".

In Sham SRS, the MAIL FROM is rewritten to the same address for every
forward. The address cannot be the same as the forward address (otherwise
a bounce creates a mail-laser), but might be a trivial modification.

So if <jane_roe@example.com> writes to <john_doe@example.org> who is
really <joe_smith@example.net>, the MAIL FROM on the second leg might be
<forward-john_doe@example.org>.

Unlike SRS, this doesn't handle bounces. But we don't care. If someone
tries to mail from <> to <forward-john_doe@example.org>, I might 250 the
RCPT TO: line merely to bypass any SAV nonsense. But at DATA, the would
be bouncer gets:

550 That was forwarded mail. It's NOT BOUNCABLE.

So if the ultimate recipient tries to spamfilter forwarded mails, his
server fills up with doublebounces and I just laugh.

(This will earn an RFC-Ignorant listing, but even fewer people care about
RFCI than SPF. And taking the RFC-Ignorant hit avoids the more dangerous
backscatterer.org blacklisting, since it is not viable for a forwarder to
refuse incoming mail with ambiguous or absent SPF information.)

There's still the problem of 550s in-transaction when the forwarder sends
to the ultimate recipient, but that problem has solutions and is not
unique to Sham SRS.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
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=82146588-606997
Powered by Listbox: http://www.listbox.com

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

Graham Murray wrote:
> Michael Deutschmann <michael@talamasca.ocis.net> writes:
> > I think this is folly. It's a chicken game, with four states:
> >
> > 1A - forwarders use SRS, recipients do not enforce SPF
> > 1B - forwarders use SRS, recipients enforce SPF
> > 2A - forwarders operate traditionally, recipients do not enforce SPF
> > 2B - forwarders operate traditionally, recipients enforce SPF
>
> 3 - forwarders use their own address in the RFC2821 Mail From.

That's in effect sender rewriting, of which SRS is just a specific
implementation. So it's basically the same as 1 in the above.

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

iD8DBQFHf4/gwL7PKlBZWjsRAk/TAKC0UpKy4wWQEyUhtor/3YRK1ULnRQCg6DtD
He8dAjafpHOHZIcQv0zB6e4=
=MfzF
-----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=82147897-7f875a
Powered by Listbox: http://www.listbox.com

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

Michael Deutschmann wrote:
> Still, this brings up one thing that I'd probably do if called to
> forward. Rather than do either traditional forwarding or SRS, I'd adopt
> a strategy I call "Sham SRS".
>
> In Sham SRS, the MAIL FROM is rewritten to the same address for every
> forward. The address cannot be the same as the forward address
> (otherwise a bounce creates a mail-laser), but might be a trivial
> modification.
>
> So if <jane_roe@example.com> writes to <john_doe@example.org> who is
> really <joe_smith@example.net>, the MAIL FROM on the second leg might
> be <forward-john_doe@example.org>.

That's essentially the same as "database-backed SRS" as described in [1],
section 2.10. A "sham SRS" database would merely map origin addresses to
forwarder-domain addresses and vice versa.

> Unlike SRS, this doesn't handle bounces. But we don't care. If
> someone tries to mail from <> to <forward-john_doe@example.org>, I
> might 250 the RCPT TO: line merely to bypass any SAV nonsense. But at
> DATA, the would be bouncer gets:
>
> 550 That was forwarded mail. It's NOT BOUNCABLE.

Heh, that's a novel idea! But handling bounces actually isn't a problem
as long as you have a _two-way_ mapping between origin addresses and
forwarder-domain addresses.

References:
1. http://www.libsrs2.org/srs/srs.pdf

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

iD8DBQFHf5OpwL7PKlBZWjsRAh9CAJ9jXTjIpvjKonU+9f/dM/JyjZmPDACg4Jgv
U4tOjjV7xvc0CiqoeRluRj4=
=Vdf+
-----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=82150514-c27e02
Powered by Listbox: http://www.listbox.com

On Sat, Jan 05, 2008 at 11:28:53AM +0000, Julian Mehnle wrote:

> > The current paragraph reads
> >
> > 2.5.4. Fail
> >
> > A "Fail" result is an explicit statement that the client is not
> > authorized to use the domain in the given identity. The checking
> > software can choose to mark the mail based on this or to reject the
> > mail outright.
> >
> > I'd rather see
> >
> > A "Fail" result is an explicit statement that the client is not
> > authorized to use the domain in the given identity. The checking
> > software MUST reject the mail outright.
> >
> > Marking may allow messages with abused names to hit users. SPF should
> > avoid exactly that. There are no false positives, since the domain
> > owner is the direct origin of such "explicit statement". (Yes, there
> > may be errors in the SPF setup, that's why SOFTFAIL exists. See next
> > post.)
>
> The problem with mandating receiver policy is that receivers are going to
> ignore it at will. Receivers will always do what they think is best for
> them.

True. But one could argue that SPF is a way to ask a receiver to cooperate
with the domain owner. The text could read something like:

A "Fail" result is an explicit statement that the client is not
authorized to use the domain in the given identity. The host is
encouraged to reject the message outright. If the message is not
rejected, it MUST NOT result in automated replies including but not
limited to DSNs.

I think this does give the receiver the option to receive the message,
but at the same time it makes clear that the domain owner should not be
bothered with the resulting problems. This is (IMHO) the spirit of SPF.

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=82151835-d725f2
Powered by Listbox: http://www.listbox.com

On Sat, 5 Jan 2008, you wrote:
> That's essentially the same as "database-backed SRS" as described in [1],
> section 2.10. A "sham SRS" database would merely map origin addresses to
> forwarder-domain addresses and vice versa.

Not really. In Sham SRS the second-leg MAIL FROM does not change for
different first-leg MAIL FROMs. So there's nothing to key the database from.

A constant second-leg MAIL FROM is advantageous since it allows the ultimate
recipient forwarder to whitelist the forwarder. While whitelisting will no
longer be needed to avoid SPF FPs, the recipient will still have to do it,
because the forwarder will react to a single 5xx by suspending the forwarding
service....

> Heh, that's a novel idea! But handling bounces actually isn't a problem
> as long as you have a _two-way_ mapping between origin addresses and
> forwarder-domain addresses.

Recovering the original MAIL FROM after rewriting it isn't the problem. The
problem is that the original message may itself have been forged, in which
case bouncing may earn the forwarder a backscatter blacklisting.

In theory, the forwarder could protect himself from this by rejecting on SPF
Softfail, None, and Unknown status (in addition to Fail, of course). But
that's not reasonable in practice.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
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=82158246-eba8c6
Powered by Listbox: http://www.listbox.com

On Saturday 05 January 2008 07:47, Michael Deutschmann wrote:

> (I think the way forward is to make forwarder-whitelisting easier, so
> that eventually everyone can join the elite class who can deploy
> receiverside-SPF safely.)
>

SPF checks can only safely be done at the boundary between the sender's
network and the receiver's network. Forwarders are agents of the receiver
and so downstream reciever MTAs should not check SPF for messages forwarded
to them.

Recievers can:

1. Not check SPF at downstream MTAs
2. Whitelist forwarders
3. Ignore the problem and accept the false positive risk for forwarded mail

For many receivers, forwarded mail is a noise level problem. Additionally, in
every case of forwarded mail being rejected due to SPF that I've
investigated, the correct final e-mail address was included in the reject
message making it trivial to resend to the correct address.

For others the false positive rate is to much to bear. Forwarder whitelisting
is supported in the current version of Python Postfix policy server:

http://www.openspf.org/Software#python-postfix-policyd-spf

Per-user forwarder whitelisting is on my TODO list for the application.

Scott K

-------------------------------------------
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=82195400-6698ae
Powered by Listbox: http://www.listbox.com

Alessandro Vesely wrote:

>| A "Fail" result is an explicit statement that the client is not
>| authorized to use the domain in the given identity. The checking
>| software MUST reject the mail outright.

No, the checking software might be not in the position where it
still can reject the mail. It's at best a SHOULD in a not yet
existing "receiver policy" RFC. For SPF it's actually a feature
that spammers cannot simply probe who rejects FAIL, there might
be also receivers moving FAIL silently into a trash folder.

As long as spammers must fear that SPF FAIL never makes it they
can't abuse FAIL protected addresses anywhere. With your proposal
they could abuse SPF FAIL protected addresses at all receivers not rejecting FAIL outright.

> There are no false positives, since the domain owner is the
> direct origin of such "explicit statement".

Right, but the domain owner isn't always the same as the domain
user, and the receiver mailbox can be a user forwarding his mail
to an address at a third party checking SPF. Arguably that is a
kind of "false positive", and in that case I really hope that a
FAIL is rejected, and doesn't vanish silently in a trash folder.

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=83019269-c8790c
Powered by Listbox: http://www.listbox.com

Frank Ellermann wrote:
> Alessandro Vesely wrote:
>
>> | A "Fail" result is an explicit statement that the client is not
>> | authorized to use the domain in the given identity. The checking
>> | software MUST reject the mail outright.
>
> No, the checking software might be not in the position where it
> still can reject the mail. It's at best a SHOULD in a not yet
> existing "receiver policy" RFC.

A "SHOULD" is weaker, but it can handle a transition period nicely.

> For SPF it's actually a feature
> that spammers cannot simply probe who rejects FAIL,

Why would that be an advantage?

> there might
> be also receivers moving FAIL silently into a trash folder.

Hmm... If the client (relay host) is a spammer, rejection is
appropriate and saves bandwidth. If it is an innocent forwarder,
a bounce may be useful for diagnostic purposes.

> As long as spammers must fear that SPF FAIL never makes it they
> can't abuse FAIL protected addresses anywhere. With your proposal
> they could abuse SPF FAIL protected addresses at all receivers
> not rejecting FAIL outright.

I assume that by "never makes it" you mean "is never delivered".
Still, I have some difficulty understanding what you mean. Do you
mean that if rejecting were the mandatory behavior, spammers could
easily argue that not rejected messages will be delivered?

At any rate, I've seen spammers getting more cautious over time.
While they used to play like crazy, mixing FROM and MAIL FROM
addresses with no apparent reason, today's spam quite often shows
the same address in both headers, effectively masquerading as a
human2human message. I guess it is just easier for spammers to
play correctly.

>> There are no false positives, since the domain owner is the
>> direct origin of such "explicit statement".
>
> Right, but the domain owner isn't always the same as the domain
> user,

They have to trust each other, anyway.

> and the receiver mailbox can be a user forwarding his mail
> to an address at a third party checking SPF. Arguably that is a
> kind of "false positive", and in that case I really hope that a
> FAIL is rejected, and doesn't vanish silently in a trash folder.

Agreed. And the RFCs never mention silently dropping messages,
AFAIK.

-------------------------------------------
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=83044766-debc1a
Powered by Listbox: http://www.listbox.com

Alessandro Vesely wrote:
> Frank Ellermann wrote:
>> Alessandro Vesely wrote:
>>
>>> | A "Fail" result is an explicit statement that the client is not
>>> | authorized to use the domain in the given identity. The checking
>>> | software MUST reject the mail outright.
>>
>> No, the checking software might be not in the position where it
>> still can reject the mail. It's at best a SHOULD in a not yet
>> existing "receiver policy" RFC.
>
> A "SHOULD" is weaker, but it can handle a transition period nicely.
>
I think that SHOULD is perfect. SPF defines what FAIL means, what the
receiver chooses to do with unauthorized source e-mail once they've
identified it as such can be flexible. I can honestly think of several
things to actually do with known forged e-mails, mostly revolving around
getting to the root of any criminal activities that might be associated
with hiding behind deliberate forgeries or fixing technical issues that
would cause apparent forgeries.

>> For SPF it's actually a feature
>> that spammers cannot simply probe who rejects FAIL,
>
> Why would that be an advantage?
>
>> there might be also receivers moving FAIL silently into a trash folder.
>
> Hmm... If the client (relay host) is a spammer, rejection is
> appropriate and saves bandwidth. If it is an innocent forwarder,
> a bounce may be useful for diagnostic purposes.
>
Absolutely. Most receivers SHOULD reject.

>> As long as spammers must fear that SPF FAIL never makes it they
>> can't abuse FAIL protected addresses anywhere. With your proposal
>> they could abuse SPF FAIL protected addresses at all receivers
>> not rejecting FAIL outright.
>
> I assume that by "never makes it" you mean "is never delivered".
> Still, I have some difficulty understanding what you mean. Do you
> mean that if rejecting were the mandatory behavior, spammers could
> easily argue that not rejected messages will be delivered?
>
> At any rate, I've seen spammers getting more cautious over time.
> While they used to play like crazy, mixing FROM and MAIL FROM
> addresses with no apparent reason, today's spam quite often shows
> the same address in both headers, effectively masquerading as a
> human2human message. I guess it is just easier for spammers to
> play correctly.
>
I've noticed this too. The Internet is a highly selective environment
for spam sources. It's adapt or die, essentially.

>>> There are no false positives, since the domain owner is the direct
>>> origin of such "explicit statement".
>>
>> Right, but the domain owner isn't always the same as the domain
>> user,
>
> They have to trust each other, anyway.
>
To some extent. There are an awful lot of naive users out there who will
break all the rules if they aren't enforced like gravity. Admins, also.

>> and the receiver mailbox can be a user forwarding his mail
>> to an address at a third party checking SPF. Arguably that is a
>> kind of "false positive", and in that case I really hope that a
>> FAIL is rejected, and doesn't vanish silently in a trash folder.
>
> Agreed. And the RFCs never mention silently dropping messages,
> AFAIK.
>
Black holes for e-mail messages are generally in conflict with the
concept of reliable delivery that is explicit in a lot of the SMTP
specs. Unfortunately, they are more common than ever since that is all
that many receivers (admins and end-users alike) have the time to deal with.

--
Daniel Taylor VP Operations Vocal Laboratories, Inc.
dtaylor@vocalabs.com http://www.vocalabs.com/ (952)941-6580x203

-------------------------------------------
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=83063066-5d1290
Powered by Listbox: http://www.listbox.com

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

Julian Mehnle wrote:
> Alessandro Vesely wrote:
> > The current paragraph reads
> >
> > 2.5.4. Fail
> >
> > A "Fail" result is an explicit statement that the client is not
> > authorized to use the domain in the given identity. The checking
> > software can choose to mark the mail based on this or to reject
> > the mail outright.
> >
> > I'd rather see
> >
> > A "Fail" result is an explicit statement that the client is not
> > authorized to use the domain in the given identity. The checking
> > software MUST reject the mail outright.
> >
> > Marking may allow messages with abused names to hit users. SPF should
> > avoid exactly that. There are no false positives, since the domain
> > owner is the direct origin of such "explicit statement". (Yes, there
> > may be errors in the SPF setup, that's why SOFTFAIL exists. See next
> > post.)
>
> The problem with mandating receiver policy is that receivers are going
> to ignore it at will. Receivers will always do what they think is best
> for them.
>
> The current wording merely suggests possible reactions to the "Fail"
> result but does not mandate anything. I think it's better that way.

Since there seems to be some desire to make the "Fail" definition more
explicit with regard to messages getting rejected, how about that:

| A "Fail" result is an explicit statement that the client is not
| authorized to use the domain in the given identity. Domain owners
| should be aware that mail receivers typically reject messages on this
| result. Alternatively, some receivers decide to mark the mail based on
| this.

?

This conveys both a heads-up to domain owners as well as a warm fuzzy
feeling to receivers that others, too, are rejecting on "Fail", without
actually mandating receiver policy.

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

iD8DBQFHg8YQwL7PKlBZWjsRAk6QAJsEXg36Dpk2pdLr66Or/jOLipbIFQCdFkpw
lIw22WAnmrJYQj4mEvJt2w4=
=oW/P
-----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=83236122-6dc327
Powered by Listbox: http://www.listbox.com

At 11:50 AM 1/8/2008, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Julian Mehnle wrote:
> > Alessandro Vesely wrote:
> > > The current paragraph reads
> > >
> > > 2.5.4. Fail
> > >
> > > A "Fail" result is an explicit statement that the client is not
> > > authorized to use the domain in the given identity. The checking
> > > software can choose to mark the mail based on this or to reject
> > > the mail outright.
> > >
> > > I'd rather see
> > >
> > > A "Fail" result is an explicit statement that the client is not
> > > authorized to use the domain in the given identity. The checking
> > > software MUST reject the mail outright.
> > >
> > > Marking may allow messages with abused names to hit users. SPF should
> > > avoid exactly that. There are no false positives, since the domain
> > > owner is the direct origin of such "explicit statement". (Yes, there
> > > may be errors in the SPF setup, that's why SOFTFAIL exists. See next
> > > post.)
> >
> > The problem with mandating receiver policy is that receivers are going
> > to ignore it at will. Receivers will always do what they think is best
> > for them.
> >
> > The current wording merely suggests possible reactions to the "Fail"
> > result but does not mandate anything. I think it's better that way.
>
>Since there seems to be some desire to make the "Fail" definition more
>explicit with regard to messages getting rejected, how about that:
>
>| A "Fail" result is an explicit statement that the client is not
>| authorized to use the domain in the given identity. Domain owners
>| should be aware that mail receivers typically reject messages on this
>| result. Alternatively, some receivers decide to mark the mail based on
>| this.
>
>?
>
>This conveys both a heads-up to domain owners as well as a warm fuzzy
>feeling to receivers that others, too, are rejecting on "Fail", without
>actually mandating receiver policy.
-- snip --
Looks good. May I offer this minor wording change...

| A "Fail" result is an explicit statement that the client is not
| authorized to use the domain in the given identity. Domain owners
| should be aware that, while most mail receivers typically reject
messages on this
| result as suggested, some receivers may decide to mark the mail
based on this.

I'm playing with semantics a little here in saying suggested, in that
what I mean is what the word Fail suggests rather than the making of
an actual recommendation. If developers were to take it as a
recommendation, I would not be heartbroken. After all, when I
publish an SPF record with "-ALL", such that the outcome is an
explicit Fail for that domain, I would prefer the result was, in
fact, a rejected message.

FWIW, in future versions of SPF it might be nice to introduce a
"FAIL-REJECT" vs a "FAIL-BOUNCE" concept with some trigger in the SPF
record to further indicate and further qualify the preference of the
domain holder as to what the receiver should do with a "Fail". I'm
not sure which would be considered the default, but perhaps the way
to handle that might be to follow an "-all" with a "-reject" or
"-bounce" or some such thing to indicate the domain holders
desire. Personally, I think the default should be "-reject" to avoid
having to receive the bounces from a "Fail". After all, I know it
should fail because I created the SPF record, the receiver knows I
want it to fail because they read and interpreted my intent, so let's
just drop the problem message and save both our systems further time
and energy.

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=83357688-e6d4bb
Powered by Listbox: http://www.listbox.com

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

WebMaster@commerco.net wrote:
> May I offer this minor wording change...
>
> | A "Fail" result is an explicit statement that the client is not
> | authorized to use the domain in the given identity. Domain owners
> | should be aware that, while most mail receivers typically reject
> | messages on this result as suggested, some receivers may decide to
> | mark the mail based on this.
>
> I'm playing with semantics a little here in saying suggested, in that
> what I mean is what the word Fail suggests rather than the making of
> an actual recommendation. If developers were to take it as a
> recommendation, I would not be heartbroken. After all, when I
> publish an SPF record with "-ALL", such that the outcome is an
> explicit Fail for that domain, I would prefer the result was, in
> fact, a rejected message.

Well, if the word "Fail" suggests rejecting, then why do we need to spell
it out?

I'd really like to avoid telling receivers what to do with "Fail".

> FWIW, in future versions of SPF it might be nice to introduce a
> "FAIL-REJECT" vs a "FAIL-BOUNCE" concept with some trigger in the SPF
> record to further indicate and further qualify the preference of the
> domain holder as to what the receiver should do with a "Fail". I'm
> not sure which would be considered the default, but perhaps the way
> to handle that might be to follow an "-all" with a "-reject" or
> "-bounce" or some such thing to indicate the domain holders
> desire. Personally, I think the default should be "-reject" to avoid
> having to receive the bounces from a "Fail". After all, I know it
> should fail because I created the SPF record, the receiver knows I
> want it to fail because they read and interpreted my intent, so let's
> just drop the problem message and save both our systems further time
> and energy.

Please let's not do the receiver policy thing.

I know it is difficult for domain owners to decide on how to qualify their
policies, not knowing how receivers will act on them. However it will be
even more difficult for domain owners if they make assumptions about how
receivers will act based on recommendations that we put in the spec but
will actually be ignored by receivers, because receivers will always just
do what's best for _them_. I know that I, as a receiver, would. (For
example, I treat "Neutral" the same as "None" not because the spec tells
me to, but only because I happen to agree with the spec.)

Furthermore, why do you care whether the receiver rejects "Fail" messages
from your domain, or marks them, or drops them on the floor, or feeds
them into their /dev/random? What difference does it make to you?

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

iD8DBQFHhBXuwL7PKlBZWjsRApTXAJ9wgLZQ+3j+waCl8tGZM8CuMZI5zgCffp1L
E8uBnFZegLXcXEXQKyT/Md8=
=8kxO
-----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=83436964-5140a1
Powered by Listbox: http://www.listbox.com

Julian,

At 05:31 PM 1/8/2008, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>WebMaster@commerco.net wrote:
> > May I offer this minor wording change...
> >
> > | A "Fail" result is an explicit statement that the client is not
> > | authorized to use the domain in the given identity. Domain owners
> > | should be aware that, while most mail receivers typically reject
> > | messages on this result as suggested, some receivers may decide to
> > | mark the mail based on this.
> >
> > I'm playing with semantics a little here in saying suggested, in that
> > what I mean is what the word Fail suggests rather than the making of
> > an actual recommendation. If developers were to take it as a
> > recommendation, I would not be heartbroken. After all, when I
> > publish an SPF record with "-ALL", such that the outcome is an
> > explicit Fail for that domain, I would prefer the result was, in
> > fact, a rejected message.
>
>Well, if the word "Fail" suggests rejecting, then why do we need to spell
>it out?
>
>I'd really like to avoid telling receivers what to do with "Fail".

It was just a thought. No harm, no foul. I'm not sure that a
recommendation for processing in a spec is really telling them what
to do. I guess it is the difference between telling vs recommending
is using words like must as opposed to should. However, as I
originally said, your version looks good.


> > FWIW, in future versions of SPF it might be nice to introduce a
> > "FAIL-REJECT" vs a "FAIL-BOUNCE" concept with some trigger in the SPF
> > record to further indicate and further qualify the preference of the
> > domain holder as to what the receiver should do with a "Fail". I'm
> > not sure which would be considered the default, but perhaps the way
> > to handle that might be to follow an "-all" with a "-reject" or
> > "-bounce" or some such thing to indicate the domain holders
> > desire. Personally, I think the default should be "-reject" to avoid
> > having to receive the bounces from a "Fail". After all, I know it
> > should fail because I created the SPF record, the receiver knows I
> > want it to fail because they read and interpreted my intent, so let's
> > just drop the problem message and save both our systems further time
> > and energy.
>
>Please let's not do the receiver policy thing.

I'm not meaning to do that, I'm simply wanting to express a desired
response to a receiver from a domain holders perspective. I could
envision times when I would like to see bounces and have the ability
to shut them down from at least some of the MTAs who might respect my
wishes if the bounces become overly burdensome on my servers. That's
really all I had in mind.

>I know it is difficult for domain owners to decide on how to qualify their
>policies, not knowing how receivers will act on them. However it will be
>even more difficult for domain owners if they make assumptions about how
>receivers will act based on recommendations that we put in the spec but
>will actually be ignored by receivers, because receivers will always just
>do what's best for _them_. I know that I, as a receiver, would. (For
>example, I treat "Neutral" the same as "None" not because the spec tells
>me to, but only because I happen to agree with the spec.)

No argument there.


>Furthermore, why do you care whether the receiver rejects "Fail" messages
>from your domain, or marks them, or drops them on the floor, or feeds
>them into their /dev/random? What difference does it make to you?

Given the choices above, it makes no difference. I was thinking of
bounce back messages to my servers, which does make a
difference. Perhaps I've forgotten yet another thing about SPF, but
does the spec already provide for recommending the stopping of bounce
back messages from occurring when a domain name is spoofed and SPF "Fail"s?

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=83449632-7334ab
Powered by Listbox: http://www.listbox.com

On Wed, 9 Jan 2008, Julian Mehnle wrote:

> I'd really like to avoid telling receivers what to do with "Fail".

No, but we need to tell receivers what senders *want* them
to do with "Fail". I've talked to big company receivers that were
afraid to reject on "Fail" because they might get sued for rejecting
important mail. They need a clear "No, really, it is ok to reject SPF FAIL,
in fact, we really wish you would. We wouldn't publish it if we didn't
want you to." That is not "telling the receiver what to do", but communicating
the senders wishes clearly. That is, after all, what *Sender* Policy Framework
purports to do. The receiver can still choose to follow the senders
wishes. Or not. But at least they know what they are.

--
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=83474869-22c650
Powered by Listbox: http://www.listbox.com

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

WebMaster@commerco.net wrote:
> > Furthermore, why do you care whether the receiver rejects "Fail"
> > messages from your domain, or marks them, or drops them on the floor,
> > or feeds them into their /dev/random? What difference does it make
> > to you?
>
> Given the choices above, it makes no difference. I was thinking of
> bounce back messages to my servers, which does make a difference.
> Perhaps I've forgotten yet another thing about SPF, but does the spec
> already provide for recommending the stopping of bounce back messages
> from occurring when a domain name is spoofed and SPF "Fail"s?

Not really. This should be made clearer in a revised spec, although I'd
hope that common sense would stop receivers from bouncing at least on
"Fail" or "SoftFail" even without an explicit hint.

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

iD8DBQFHhDlRwL7PKlBZWjsRAjWxAJ9b04Ho9EiG2pq6JZ1e8EH3hnkgygCdHnf3
DNpc0timdOdZxLOCAxV1Rk4=
=gdyr
-----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=83485375-5945ce
Powered by Listbox: http://www.listbox.com

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

Stuart D. Gathman wrote:
> On Wed, 9 Jan 2008, Julian Mehnle wrote:
> > I'd really like to avoid telling receivers what to do with "Fail".
>
> No, but we need to tell receivers what senders *want* them
> to do with "Fail". I've talked to big company receivers that were
> afraid to reject on "Fail" because they might get sued for rejecting
> important mail. They need a clear "No, really, it is ok to reject SPF
> FAIL, in fact, we really wish you would. We wouldn't publish it if we
> didn't want you to." That is not "telling the receiver what to do",
> but communicating the senders wishes clearly. That is, after all, what
> *Sender* Policy Framework purports to do. The receiver can still
> choose to follow the senders wishes. Or not. But at least they know
> what they are.

I'm familiar with that debate. However, given the existence of
"SoftFail", making "Fail" anything OTHER than "yes, we really mean it"
would be pointless. Thus it's just a matter of making it clear that
"Fail" bears the possibility of messages getting rejected. On the other
hand, isn't that what the current definition of "Fail" already says?

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

iD8DBQFHhDo1wL7PKlBZWjsRAhzDAKDfYu934coPk2TDu6OddyVrZTsmewCgoF//
VlO2vc5Nz/Y5aeEJizA+Ns0=
=9DKj
-----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=83485219-95c5c4
Powered by Listbox: http://www.listbox.com

On Tue, 8 Jan 2008, Frank Ellermann wrote:
> As long as spammers must fear that SPF FAIL never makes it they
> can't abuse FAIL protected addresses anywhere. With your proposal
> they could abuse SPF FAIL protected addresses at all receivers not
> rejecting FAIL outright.

That's a silly reason not to reject on fail. Since post-transactionally
bouncing mail because of SPF Fail is daft, such mail would have to be
blackholed. Some mail in that stream might just be unknown traditional
forwards.

Also, I don't think it would work as you intend.

A dumb spammer-customer would pay for each message that gets through the
initial transaction -- that gets a 250 after CR LF '.' CR LF.
Accepting-then-blackholing would make the spam run more profitable for the
spammer.

A smarter spammer-customer would place web bugs in his messages, or put ids
in the "click here to buy" URLs, and then pay the spammer per *read* message.
(Yeah, smart people are immune to webbugs, but they don't buy spammed
merchandise either, so the spammer-customer won't pay to reach them.)
Accepting-then-blackholing is no different than rejecting upfront, to them.


That said, I believe making reject-on-SPF-fail a MUST is a bad idea, since
that would mean no sender would be entitled to use "-all" unless he is
CERTAIN that he never sends mail to a traditionally forwarded mailbox. If
senders eschewed "-all" for that reason, the distinction between a domain
where all users use trusted smarthosts, and one where trusted smarthosts are
available but not everyone reliably uses them, would be lost in SPF.

And recipients who have whitelisted all forwarders are very interested to
make that distinction.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
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=83592232-4051fb
Powered by Listbox: http://www.listbox.com

--On 8 January 2008 17:53:27 -0700 WebMaster@Commerco.Net wrote:

>
>> Furthermore, why do you care whether the receiver rejects "Fail" messages
>> from your domain, or marks them, or drops them on the floor, or feeds
>> them into their /dev/random? What difference does it make to you?
>
> Given the choices above, it makes no difference. I was thinking of
> bounce back messages to my servers, which does make a difference.
> Perhaps I've forgotten yet another thing about SPF, but does the spec
> already provide for recommending the stopping of bounce back messages
> from occurring when a domain name is spoofed and SPF "Fail"s?

It does make a difference.

You don't want the receiver bouncing messages. That way, you'll just get
hammered by spam blowback. What sense does it make for a recipient to
configure their system to return messages to addresses that they've just
decided are probably forged?

What you want is for the receiver to reject messages, so that a legitimate
forwarder (who's presumably seen an SPF pass) can bounce them back to the
sender. That way, the sender can choose to use another contact method -
perhaps phone the recipient to alert them that their forwarding is broken.

Remember, rejecting a message is simply saying "I won't accept this for
delivery". It's then up to the sender to decide whether to bounce it.
Legitimate senders should do that, spammers of course don't.

--
Ian Eiloart
IT Services, University of Sussex
x3148

-------------------------------------------
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=83594349-6caa4b
Powered by Listbox: http://www.listbox.com

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?

Perhaps, you mean that telling receivers what to do after various
checks should be the subject of a separate rfc?

I apologize if that has been answered already, I'm new to this list :-)

-------------------------------------------
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=83918704-85fb14
Powered by Listbox: http://www.listbox.com

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.

-------------------------------------------
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=83918213-cb11e8
Powered by Listbox: http://www.listbox.com

-----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/?member_id=1311532&id_secret=83929396-486938
Powered by Listbox: http://www.listbox.com