Mailing List Archive

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

Alessandro Vesely wrote:
> I've read some posts on this list about SOFTFAIL. I agree with
> most of them saying it is a debugging feature. As such, it
> leaves something to be desired, doesn't it? I'd propose the
> following addition:
>
> If example.com says "~ip4:1.2.3.4", then a receiving server
> should send a DSN to postmaster@example.com saying something
> like
>
> Hey,
> someone did actually manage to send a message from 1.2.3.4
> Here are the relevant headers...
>
> Nearly a breakpoint, isn't it?
>
> Possibly a mandatory string (e.g. "SPF: SOFTFAIL") either in the
> subject or in some other header may help postmasters to properly
> collect their debug messages.

Besides my dislike for mandating receiver policy, I think mandating
receivers to send DSNs (delivery status notifications AKA bounces, for
those who don't know the acronym) is a particularly touchy issue.

However I do like the idea of making it more clear that the ~ qualifier is
supposed to be a testing tool, not a permanent band-aid for SPF's alleged
"forwarding problem" as many domain owners seem to think.

I just can't see how to introduce new semantics into SPFv1 (e.g. by adding
a "testing=yes" modifier and _deprecating_ the ~ qualifier), given that
there are about half a dozen stable open implementations of the "classic"
SPFv1 and probably dozens of proprietary ones hidden in commercial
software. Most of the existing implementations will probably NEVER be
changed to adopt those new semantics.

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

iD8DBQFHf2x3wL7PKlBZWjsRAnkxAJ95ToE2QDGIxzHZ6dKXv40yqWRT9gCgtBBH
nY3NdGnPVneUb4Htibk+2mg=
=wRuO
-----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=82137283-e91ff2
Powered by Listbox: http://www.listbox.com

On Jan 5, 2008 4:39 AM, Julian Mehnle <julian@mehnle.net> wrote:

> Alessandro Vesely wrote:
> > I've read some posts on this list about SOFTFAIL. I agree with
> > most of them saying it is a debugging feature. As such, it
> > leaves something to be desired, doesn't it? I'd propose the
> > following addition:
> >
> > If example.com says "~ip4:1.2.3.4", then a receiving server
> > should send a DSN to postmaster@example.com saying something
> > like
> >
> > Hey,
> > someone did actually manage to send a message from 1.2.3.4
> > Here are the relevant headers...
> >
> > Nearly a breakpoint, isn't it?
> >
> > Possibly a mandatory string (e.g. "SPF: SOFTFAIL") either in the
> > subject or in some other header may help postmasters to properly
> > collect their debug messages.
>
> Besides my dislike for mandating receiver policy, I think mandating
> receivers to send DSNs (delivery status notifications AKA bounces, for
> those who don't know the acronym) is a particularly touchy issue.


I agree with Julian on this. Many receivers get so few legitimate DSNs that
they would rather deal with each as the situation requires. While it may
make sense to automatically send a DSN in the example above, where the
postmaster at example.com should be interested in what happens at IP 1.2.3.4,,
in the more common case of ~all, the DSN will go to a forged address.


> However I do like the idea of making it more clear that the ~ qualifier is
> supposed to be a testing tool, not a permanent band-aid for SPF's alleged
> "forwarding problem" as many domain owners seem to think.
>
> I just can't see how to introduce new semantics into SPFv1 (e.g. by adding
> a "testing=yes" modifier and _deprecating_ the ~ qualifier), given that
> there are about half a dozen stable open implementations of the "classic"
> SPFv1 and probably dozens of proprietary ones hidden in commercial
> software. Most of the existing implementations will probably NEVER be
> changed to adopt those new semantics.


What might make sense here is a more subtle "upgrade" in the meaning of
~all, one that is "backward compatible" with existing implementations. It
could mean the same as -all for messages sent direct to the final
destination, and continue to mean ~all for forwarded messages.

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

On Sat, 5 Jan 2008, Julian Mehnle wrote:
> However I do like the idea of making it more clear that the ~ qualifier is
> supposed to be a testing tool, not a permanent band-aid for SPF's alleged
> "forwarding problem" as many domain owners seem to think.

My understanding it is that it is neither a forwarding band-aid nor a
testing tool. It's a band-aid for a different problem -- that of users
who roam to other ISPs (perhaps using a laptop), and send their mail
either direct-to-MX or via a different ISP's smarthost. In theory, SMTP
AUTH obviates the need, but in practice it may take awhile before all
users get the word.

A sensible receiver policy is to not reject based on softfail alone, but
also to ignore any whitelist entry on that address unless the recipient
has other softfail messages from that address which he has not marked as
spam.

Using ?all or ~all as a forwarding band-aid is bad -- it destroys
relevant information.

---- 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=82142784-1ca48d
Powered by Listbox: http://www.listbox.com

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

Michael Deutschmann wrote:
> On Sat, 5 Jan 2008, Julian Mehnle wrote:
> > However I do like the idea of making it more clear that the ~
> > qualifier is supposed to be a testing tool, not a permanent band-aid
> > for SPF's alleged "forwarding problem" as many domain owners seem to
> > think.
>
> My understanding it is that it is neither a forwarding band-aid nor a
> testing tool. It's a band-aid for a different problem -- that of users
> who roam to other ISPs (perhaps using a laptop), and send their mail
> either direct-to-MX or via a different ISP's smarthost.

No, that's what the ? qualifier is for. ~ was meant as a tool for testing
during roll-out. Unfortunately RFC 4408 does not make this sufficiently
clear, but it can be seen from both older versions of the spec and all
versions of Mail::SPF::Query, which has long been "the" SPF reference
implementation:

draft-mengwong-spf-00 and -01:

| 9.3 Phased Rollout
|
| At an adopting domain, adoption of SPF could occur in phases. A domain
| might move through these phases by changing its default response type
| from "neutral" to "softfail" to "fail".
|
| The phases are characterized by different levels of awareness among the
| domain's userbase, and different levels of strictness on the part of
| SPF-conformant receivers.
|
| When a sufficient majority of its users are SPF-conformant, a domain
| SHOULD change its default to "fail". [...]

draft-mengwong-spf-00 and -01, and draft-schlitt-spf-classic-00:

| [6.3 / 7.2] The Received-SPF header
|
| [...]
| Example headers generated by mybox.example.org:
| [...]
| Received-SPF: softfail (mybox.example.org: domain of
| transitioning myname@example.com does not
| designate 192.0.2.1 as permitted sender)

draft-lentczner-spf-00:

| 2.4.4 SoftFail
|
| A SoftFail result should be treated as somewhere between a Fail and a
| Neutral. This value is used by domains as an intermediate state during
| roll-out of publishing records. The domain believes the host isn't
| authorized but isn't willing to make that strong of a statement. [...]

| 4.2 Results
|
| [...]
| Results from interpreting valid records:
|
| Neutral (?): published data is explicitly inconclusive
| Pass (+): the <ip> is in the permitted set
| Fail (-): the <ip> is in the not permitted set
| SoftFail (~): the <ip> may be in the not permitted set, its use is
| discouraged and the domain owner may move it to the not
| permitted set in the future
| [...]

And check out these -- search for "transitioning":

http://www.openspf.org/svn/mail-spf-query-perl/tags/1.006/Query.pm
http://www.openspf.org/svn/mail-spf-query-perl/tags/1.997/Query.pm
http://www.openspf.org/svn/mail-spf-query-perl/tags/1.999.1/lib/Mail/SPF/Query.pm

It seems the idea of ~ being a testing tool during roll-out got lost in
the draft-schlitt-spf-classic drafts. We could restore it in a 4408bis
document.

> Using ?all or ~all as a forwarding band-aid is bad -- it destroys
> relevant information.

Agreed.

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

iD8DBQFHf491wL7PKlBZWjsRAmy0AKDMnRbqXjWA5qH4aMDzhepyg128bQCZAdZj
BnO9AXvEOJwadb+a5Kx1Qtk=
=brQD
-----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=82147244-7a93c2
Powered by Listbox: http://www.listbox.com

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

Edmig wrote:
> On Jan 5, 2008 4:39 AM, Julian Mehnle <julian@mehnle.net> wrote:
> > Besides my dislike for mandating receiver policy, I think mandating
> > receivers to send DSNs (delivery status notifications AKA bounces,
> > for those who don't know the acronym) is a particularly touchy issue.
>
> I agree with Julian on this. Many receivers get so few legitimate DSNs
> that they would rather deal with each as the situation requires. While
> it may make sense to automatically send a DSN in the example above,
> where the postmaster at example.com should be interested in what
> happens at IP 1.2.3.4,, in the more common case of ~all, the DSN will
> go to a forged address.

That's not exactly what I meant. I was referring to the issue of sending
massive amounts of DSNs to domain owners. Sure, that might convince
domain owners to switch to -all to get rid of all the useless DSNs </sarcasm>,
but they might just as well decide to abandon SPF altogether then.

> What might make sense here is a more subtle "upgrade" in the meaning of
> ~all, one that is "backward compatible" with existing implementations.
> It could mean the same as -all for messages sent direct to the final
> destination, and continue to mean ~all for forwarded messages.

If there was a way to discern forwarded messages from non-forwarded ones,
then no one would be complaining about a "forwarding problem" in the first
place. However there's just no way to do this reliably.

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

iD8DBQFHf5GbwL7PKlBZWjsRAq4RAJ9Empx7LJ6XdoLQGjHAqpTs6bVvdQCgwGDj
RWXq0OuLsWNu8xM8QL3JNKM=
=2Qnj
-----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=82149251-72d3a8
Powered by Listbox: http://www.listbox.com

On Jan 5, 2008 7:18 AM, Julian Mehnle <julian@mehnle.net> wrote:

> Edmig wrote:
> > What might make sense here is a more subtle "upgrade" in the meaning of
> > ~all, one that is "backward compatible" with existing implementations.
> > It could mean the same as -all for messages sent direct to the final
> > destination, and continue to mean ~all for forwarded messages.
>
> If there was a way to discern forwarded messages from non-forwarded ones,
> then no one would be complaining about a "forwarding problem" in the first
> place. However there's just no way to do this reliably.


If the HELO name ends in the domain of the return address, assume no
forwarding, and reject on SPF fail. If not, assume forwarding, and don't
use SPF.

Why didn't SPF use the HELO name to start? Sorry if this has been answered
already.

-------------------------------------------
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=82160626-427d04
Powered by Listbox: http://www.listbox.com

On Sat, Jan 05, 2008 at 08:37:55AM -0700, Edmig wrote:

> If the HELO name ends in the domain of the return address, assume no
> forwarding, and reject on SPF fail. If not, assume forwarding, and don't
> use SPF.

Consider one provider "provider.example" and three clients
"client1.example", "client2.example" and "client3.example".

All clients send mail using their provider. Perhaps mail is even
generated at that provider's host, for example newsletters which
are composed using an HTML form.

Which name should the provider's host have? Most likely it will be
like "mailhost.provider.example", and not using one of its clients'
domain name. And if it did, which one? Why that one?

There is *no* simple rule which says that a sending host's name
has to match the sender's email address.

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=82170239-8b562f
Powered by Listbox: http://www.listbox.com

On Jan 5, 2008 9:01 AM, Alex van den Bogaerdt <alex@ergens.op.het.net>
wrote:

> On Sat, Jan 05, 2008 at 08:37:55AM -0700, Edmig wrote:
>
> > If the HELO name ends in the domain of the return address, assume no
> > forwarding, and reject on SPF fail. If not, assume forwarding, and
> don't
> > use SPF.
>
> Consider one provider "provider.example" and three clients
> "client1.example", "client2.example" and "client3.example".
>
> All clients send mail using their provider. Perhaps mail is even
> generated at that provider's host, for example newsletters which
> are composed using an HTML form.


I was talking about forwarders on the receiver's side. For the case you
suggest, where the forwarder has a contractual relationship with the
original sender, the forwarder should make sure he is explicitly authorized
by the sender.

>
> There is *no* simple rule which says that a sending host's name
> has to match the sender's email address.


But it does have to correlate with the IP address used by the sending host.
Which raises the question again - why not just use the HELO name to
authenticate an incoming IP address?

-------------------------------------------
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=82175394-9e8a50
Powered by Listbox: http://www.listbox.com

On Sat, Jan 05, 2008 at 09:47:37AM -0700, Edmig wrote:

> > > If the HELO name ends in the domain of the return address, assume no
> > > forwarding, and reject on SPF fail. If not, assume forwarding, and
> > > don't use SPF.

HELO name (e.g. "mailhost.provider.example")
return address (e.g. "info@client1.example")

This is *not* forwarding. I wrote an example where mail originates at
provider.example thus is initially sent by provider.example

The assumption you make does not work.

> I was talking about forwarders on the receiver's side. For the case you
> suggest, where the forwarder has a contractual relationship with the
> original sender, the forwarder should make sure he is explicitly authorized
> by the sender.

I was *not* talking about forwarders.

> > There is *no* simple rule which says that a sending host's name
> > has to match the sender's email address.
>
> But it does have to correlate with the IP address used by the sending host.
> Which raises the question again - why not just use the HELO name to
> authenticate an incoming IP address?

uplink-01-xyz.somecarrier.example. A 10.1.2.3
ge5-3-2.othercarrier.example. A 172.16.1.2
mailhost.provider.example. A 192.168.1.1
internal.provider.example. A 192.168.2.1
external.provider.example. A 192.168.3.1


Which of these names is *the* fully qualified principle hostname?
Which of these addresses is connecting to your mailhost?

Yes, "mailhost.provider.example" could have 5 A RR's, but what if
this leads to undesired results? Perhaps I don't want all addresses
to be tried when someone connects to mailhost?



-------------------------------------------
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=82179371-8f6f67
Powered by Listbox: http://www.listbox.com

On Sat, 2008-01-05 at 09:47 -0700, Edmig wrote:
> But it does have to correlate with the IP address used by the sending
> host. Which raises the question again - why not just use the HELO
> name to authenticate an incoming IP address?

No reason. See http://mipassoc.org/csv/

Works just as well as SPF, giving you an authenticated label which you
can use in your reputation database. And without the brokenness.

--
dwmw2

-------------------------------------------
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=82180918-802aaa
Powered by Listbox: http://www.listbox.com

From: Edmig [mailto:emgemgemg@gmail.com]
Sent: zaterdag 5 januari 2008 16:38
To: spf-discuss@v2.listbox.com
Subject: Re: [spf-discuss] Re: Revising SOFTFAIL



On Sat, Jan 05, 2008 at 08:37:55AM -0700, Edmig wrote:



> If the HELO name ends in the domain of the return address, assume no

> forwarding, and reject on SPF fail. If not, assume forwarding, and

> don't use SPF.



Let's don't and say we did; in fact, let's not even say we did. :)



For example, my mail server uses a single HELO name, but I relay mail for

a dozen or so MFROM domains, neither of which ought to be treated as

forwards. Treating those instances as forwarding would patently break SPF.



Alex wrote:



> There is *no* simple rule which says that a sending host's name

> has to match the sender's email address.



Nor is there a simple, reliable rule to determine whether a message is

being forwarded.



Edmig wrote:



> But it does have to correlate with the IP address used by the sending

> host. Which raises the question again - why not just use the HELO

> name to authenticate an incoming IP address?



Authenticate for what, exactly? That relay X is authorized to use HELO

name Y? That would just tell you relay X is not hopelessly broken (and

that HELO name Y could be used to check against reputation services). But

it doesn't help you one bit in determining whether relay X is authorized

to send domain Z in MFROM.



- Mark

-------------------------------------------
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=82185418-34f688
Powered by Listbox: http://www.listbox.com

From: Edmig [mailto:emgemgemg@gmail.com]
Sent: zaterdag 5 januari 2008 16:38
To: spf-discuss@v2.listbox.com
Subject: Re: [spf-discuss] Re: Revising SOFTFAIL



On Sat, Jan 05, 2008 at 08:37:55AM -0700, Edmig wrote:



> If the HELO name ends in the domain of the return address, assume no

> forwarding, and reject on SPF fail. If not, assume forwarding, and

> don't use SPF.



Let's don't and say we did; in fact, let's not even say we did. :)



For example, my mail server uses a single HELO name, but I relay mail for

a dozen or so MFROM domains, neither of which ought to be treated as

forwards. Treating those instances as forwarding would patently break SPF.



Alex wrote:



> There is *no* simple rule which says that a sending host's name

> has to match the sender's email address.



Nor is there a simple, reliable rule to determine whether a message is

being forwarded.



Edmig wrote:



> But it does have to correlate with the IP address used by the sending

> host. Which raises the question again - why not just use the HELO

> name to authenticate an incoming IP address?



Authenticate for what, exactly? That relay X is authorized to use HELO

name Y? That would just tell you relay X is not hopelessly broken (and

that HELO name Y could be used to check against reputation services). But

it doesn't help you one bit in determining whether relay X is authorized

to send domain Z in MFROM.



- Mark

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

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

David Woodhouse wrote:
> On Sat, 2008-01-05 at 09:47 -0700, Edmig wrote:
> > But it does have to correlate with the IP address used by the sending
> > host. Which raises the question again - why not just use the HELO
> > name to authenticate an incoming IP address?
>
> No reason. See http://mipassoc.org/csv/
>
> Works just as well as SPF, giving you an authenticated label which you
> can use in your reputation database. [...]

Except that it doesn't differentiate between multiple domains served by a
common mail server.

And of course it doesn't even try to stop the MAIL FROM forgery.

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

iD8DBQFHf8h8wL7PKlBZWjsRAi3zAJ9hPn6yKnASR6eECOatI3iUU2yQ3gCeOmdH
T/niVBWvLRgBrlI5h7WB/ag=
=Unpy
-----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=82187909-b98e9c
Powered by Listbox: http://www.listbox.com

On Jan 5, 2008 10:40 AM, Mark <admin@asarian-host.net> wrote:

> On Sat, Jan 05, 2008 at 08:37:55AM -0700, Edmig wrote:
>
> > If the HELO name ends in the domain of the return address, assume no
>
> > forwarding, and reject on SPF fail. If not, assume forwarding, and
>
> > don't use SPF.
>
> For example, my mail server uses a single HELO name, but I relay mail for
>
> a dozen or so MFROM domains, neither of which ought to be treated as
>
> forwards. Treating those instances as forwarding would patently break SPF.
>
I don't understand the difference between a relay and a forward pass, or why
it matters. Why would you relay or forward mail for a domain that doesn't
give you whatever authorization you ask for?

> > But it does have to correlate with the IP address used by the sending
>
> > host. Which raises the question again - why not just use the HELO
>
> > name to authenticate an incoming IP address?
>
> Authenticate for what, exactly? That relay X is authorized to use HELO
>
> name Y? That would just tell you relay X is not hopelessly broken (and
>
> that HELO name Y could be used to check against reputation services).
>
Isn't that what we really want - the reputation of Y?

> But it doesn't help you one bit in determining whether relay X is
> authorized
>
> to send domain Z in MFROM.
>
Why do we care? If Y is reputable, and it says X is OK, we have what we
need. If Z is forged, we tell Y, and they fire X.


Archives <http://v2.listbox.com/member/archive/735/=now>
<http://v2.listbox.com/member/archive/rss/735/> | Modify
<http://v2.listbox.com/member/?&>Your
Subscription
<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=82190287-6f1645
Powered by Listbox: http://www.listbox.com

On Sat, 2008-01-05 at 18:12 +0000, Julian Mehnle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Woodhouse wrote:
> > On Sat, 2008-01-05 at 09:47 -0700, Edmig wrote:
> > > But it does have to correlate with the IP address used by the sending
> > > host. Which raises the question again - why not just use the HELO
> > > name to authenticate an incoming IP address?
> >
> > No reason. See http://mipassoc.org/csv/
> >
> > Works just as well as SPF, giving you an authenticated label which you
> > can use in your reputation database. [...]
>
> Except that it doesn't differentiate between multiple domains served by a
> common mail server.

It doesn't need to. SPF just gives you a handle -- the domain name --
which you can look up in your reputation database to see if it's a
spammer or not. With CSV that handle is the HELO name; why would you
need multiple handles for the same sending host?

Although actually if the sender _really_ wants to, they _can_ give a
different HELO name according to the mail they're sending. It's a bit
pointless, but some people seem to do it anyway. And there's nothing in
CSV which prevents that from working.

> And of course it doesn't even try to stop the MAIL FROM forgery.

It doesn't need to. It stops HELO forgery, because it's HELO that it
uses.

MAIL FROM forgery is simple enough to fix anyway, with schemes such as
BATV and SES which can be implemented unilaterally, without requiring
the world to change.

--
dwmw2

-------------------------------------------
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=82191584-924dba
Powered by Listbox: http://www.listbox.com

-----Original Message-----
From: Julian Mehnle [mailto:julian@mehnle.net]
Sent: zaterdag 5 januari 2008 15:19
To: spf-discuss@v2.listbox.com
Subject: [spf-discuss] Re: Revising SOFTFAIL

> That's not exactly what I meant. I was referring to the issue of
> sending massive amounts of DSNs to domain owners. Sure, that might
> convince domain owners to switch to -all to get rid of all the useless
> DSNs </sarcasm>, but they might just as well decide to abandon SPF
> altogether then.

Perhaps it's prudent to point out again to receivers that, though SRS was
originally written with the idea of being used in conjunction with SPF, it
can also be used very effectively, as a stand-alone tool, to handle fake
DSNs. I once wrote a small document on that:

http://www.srs-socketmap.info/sendmailsrs.htm

So, worried receivers could use a strict fake-DSN detection mechanism,
based on SRS, to deal with the bogocity of fake DSNs, yet still use ~ for
SPF.

- Mark

-------------------------------------------
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=82192835-13833e
Powered by Listbox: http://www.listbox.com

-----Original Message-----
From: Julian Mehnle [mailto:julian@mehnle.net]
Sent: zaterdag 5 januari 2008 15:19
To: spf-discuss@v2.listbox.com
Subject: [spf-discuss] Re: Revising SOFTFAIL

> That's not exactly what I meant. I was referring to the issue of
> sending massive amounts of DSNs to domain owners. Sure, that might
> convince domain owners to switch to -all to get rid of all the useless
> DSNs </sarcasm>, but they might just as well decide to abandon SPF
> altogether then.

Perhaps it's prudent to point out again to receivers that, though SRS was
originally written with the idea of being used in conjunction with SPF, it
can also be used very effectively, as a stand-alone tool, to handle fake
DSNs. I once wrote a small document on that:

http://www.srs-socketmap.info/sendmailsrs.htm

So, worried receivers could use a strict fake-DSN detection mechanism,
based on SRS, to deal with the bogocity of fake DSNs, yet still use ~ for
SPF.

- Mark

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

On Saturday 05 January 2008 12:15, David Woodhouse wrote:
> On Sat, 2008-01-05 at 09:47 -0700, Edmig wrote:
> > But it does have to correlate with the IP address used by the sending
> > host. Which raises the question again - why not just use the HELO
> > name to authenticate an incoming IP address?
>
> No reason. See http://mipassoc.org/csv/
>
> Works just as well as SPF, giving you an authenticated label which you
> can use in your reputation database. And without the brokenness.

If you want an authenticated label based on HELO you can equally use SPF HELO
checks. Compared to CSV it has the overwhelming advantage of having records
deployed in more than a trivial number of domains.

The CSV drafts are, last I checked, expired, and it appears that their authors
have given up on the concept.

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=82196598-1bb386
Powered by Listbox: http://www.listbox.com

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

David Woodhouse wrote:
> On Sat, 2008-01-05 at 18:12 +0000, Julian Mehnle wrote:
> > David Woodhouse wrote:
> > > [...] See http://mipassoc.org/csv/
> > >
> > > Works just as well as SPF, giving you an authenticated label which
> > > you can use in your reputation database. [...]
> >
> > Except that it doesn't differentiate between multiple domains served
> > by a common mail server.
>
> It doesn't need to. SPF just gives you a handle -- the domain name --
> which you can look up in your reputation database to see if it's a
> spammer or not. With CSV that handle is the HELO name; [...]
>
> > And of course it doesn't even try to stop the MAIL FROM forgery.
>
> It doesn't need to. It stops HELO forgery, because it's HELO that it
> uses.

You are defining away the MAIL FROM forgery problem.

> MAIL FROM forgery is simple enough to fix anyway, with schemes such as
> BATV and SES which can be implemented unilaterally, without requiring
> the world to change.

BATV and SES don't prevent MAIL FROM forgery. They merely help _senders_
sort out invalid bounces. They don't do anything for the _receivers_.

> why would you need multiple handles for the same sending host?

Because of many domains sending through a common host, some domains may be
sending mostly spam whereas other may be sending mostly non-spam. Your
answer to that is probably: "Why accept mail from a spammy host, even if
some mail is good? The good users can always switch to a different
service provider that is less spammer-friendly." However this would be
just a cover-your-ass excuse for not using a more discriminatory authen-
tication method.

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

iD8DBQFHf9RDwL7PKlBZWjsRAl68AKC7v1N4bOeZVWdG/alpoe3Rk1WC8QCg7H/9
QEp4RmXhN5ONQAUO1bTb9s8=
=q7Vj
-----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=82200746-f83063
Powered by Listbox: http://www.listbox.com

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

Edmig wrote:
> On Jan 5, 2008 10:40 AM, Mark <admin@asarian-host.net> wrote:
> > For example, my mail server uses a single HELO name, but I relay mail
> > for a dozen or so MFROM domains, neither of which ought to be treated
> > as forwards. Treating those instances as forwarding would patently
> > break SPF.
>
> I don't understand the difference between a relay and a forward pass,
> or why it matters. Why would you relay or forward mail for a domain
> that doesn't give you whatever authorization you ask for?

"Relaying" in the sense used by Mark above refers to the _sender_'s setup.
"Forwarding", however, is almost always set up by the _receiver_. Senders
can always account for their sending infrastructure in their SPF records.
Receivers, on the other hand, don't publish SPF records, so they have to
be aware of their forwarding infrastructure when checking senders' SPF
records.

> > > why not just use the HELO name to authenticate an incoming IP
> > > address?

You don't authenticate IP addresses. Those are inherently authentic.
What needs to be authenticated are identities such as HELO or MAIL FROM
that are NOT inherently authentic. If you just want to use one of those
identities for a reputation system, then choosing which one to use is
just a matter of the desired granularity. If however you want to use the
MAIL FROM for sending bounces or similar purposes, then authenticating
HELO doesn't help you.

> > But it doesn't help you one bit in determining whether relay X is
> > authorized to send domain Z in MFROM.
>
> Why do we care? If Y is reputable, and it says X is OK, we have what
> we need. If Z is forged, we tell Y, and they fire X.

Except that the firing X part doesn't always happen (or it doesn't happen
quickly enough) in reality.

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

iD8DBQFHf9cEwL7PKlBZWjsRAollAKDTKJiAGDVSYXqFdhO6SKnZMcrOsACfdW9y
9mqX1bWRQhqkSUtvU5jrzHA=
=oiy2
-----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=82206073-16d65e
Powered by Listbox: http://www.listbox.com

Edmig wrote:

> I don't understand the difference between a relay and a forward
> pass, ...

That's because, to the receiver, there's no visible difference. :)

> Why would you relay or forward mail for a domain that doesn't give you
> whatever authorization you ask for?

I, the MTA, would naturally never relay anything without authentication
(making the relay authorized). But, to a receiver, there's no reliable way
to determine whether I, HELO domain X, sent you the message with MFROM
domain Y immediately or whether I'm the third-party in some forwarding
deal. So, to you, the receiver, there's no reliable way you can "assume
forwarding".

Again:

> Why would you relay or forward mail for a domain that doesn't give you
> whatever authorization you ask for?

It's called spoofing. :) If a spammer uses one of my domain names in
MFROM, using his own relay, then he does so on purpose, of course. SPF
would tell the receiver that I did NOT authorize his relay to use my
domain name. This is, in effect, the same as a 'rogue' forwarding
scenario: without SPF, you, as receiver, would not be able to tell whether
the connection client is spoofing or whether he's forwarding.

To avoid troubles, the forwarder either makes sure he's listed in
trusted-forwarder.org (though not every receiver may check for that), or,
better, he uses SRS to rewrite MFROM to match a domain his own relay is
authorized to send mail for.

> Why do we care? If Y is reputable, and it says X is OK, we have
> what we need. If Z is forged, we tell Y, and they fire X.

It'd be a simple matter of granularity. In your example you can either
trust relay X completely, or not at all. A bit crude, don't ya think?

Also, the reputation of relay X is primarily a 'gate' affair, really: if
relay X is bad, and blocklisted somewhere, we wouldn't exchange mail with
it to begin with. A good reputation of relay X may result in a positive SA
score, or some such; but what we're really interested in, is whether relay
X is authorized to use domain Y, used in MFROM. Because, barring relays
that are outright bad, most relays will simply come up 'neutral' (read:
not even listed in a reputation service). So, if we trust domain Y, what
we just want to know then is whether relay X can use it in MFROM.

Mind you, this is not an either-or thingy. Because once you've established
that relay X can use domain Y in MFROM, you can now also reliably run the
reputation service against domain Y!

- Mark

-------------------------------------------
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=82208236-13c096
Powered by Listbox: http://www.listbox.com

Edmig wrote:

> I don't understand the difference between a relay and a forward
> pass, ...

That's because, to the receiver, there's no visible difference. :)

> Why would you relay or forward mail for a domain that doesn't give you
> whatever authorization you ask for?

I, the MTA, would naturally never relay anything without authentication
(making the relay authorized). But, to a receiver, there's no reliable way
to determine whether I, HELO domain X, sent you the message with MFROM
domain Y immediately or whether I'm the third-party in some forwarding
deal. So, to you, the receiver, there's no reliable way you can "assume
forwarding".

Again:

> Why would you relay or forward mail for a domain that doesn't give you
> whatever authorization you ask for?

It's called spoofing. :) If a spammer uses one of my domain names in
MFROM, using his own relay, then he does so on purpose, of course. SPF
would tell the receiver that I did NOT authorize his relay to use my
domain name. This is, in effect, the same as a 'rogue' forwarding
scenario: without SPF, you, as receiver, would not be able to tell whether
the connection client is spoofing or whether he's forwarding.

To avoid troubles, the forwarder either makes sure he's listed in
trusted-forwarder.org (though not every receiver may check for that), or,
better, he uses SRS to rewrite MFROM to match a domain his own relay is
authorized to send mail for.

> Why do we care? If Y is reputable, and it says X is OK, we have
> what we need. If Z is forged, we tell Y, and they fire X.

It'd be a simple matter of granularity. In your example you can either
trust relay X completely, or not at all. A bit crude, don't ya think?

Also, the reputation of relay X is primarily a 'gate' affair, really: if
relay X is bad, and blocklisted somewhere, we wouldn't exchange mail with
it to begin with. A good reputation of relay X may result in a positive SA
score, or some such; but what we're really interested in, is whether relay
X is authorized to use domain Y, used in MFROM. Because, barring relays
that are outright bad, most relays will simply come up 'neutral' (read:
not even listed in a reputation service). So, if we trust domain Y, what
we just want to know then is whether relay X can use it in MFROM.

Mind you, this is not an either-or thingy. Because once you've established
that relay X can use domain Y in MFROM, you can now also reliably run the
reputation service against domain Y!

- Mark

-------------------------------------------
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=82378982-019bae
Powered by Listbox: http://www.listbox.com

On Jan 5, 2008 12:14 PM, Julian Mehnle <julian@mehnle.net> wrote:

> Edmig wrote:
> > On Jan 5, 2008 10:40 AM, Mark <admin@asarian-host.net> wrote:
> > > For example, my mail server uses a single HELO name, but I relay mail
> > > for a dozen or so MFROM domains, neither of which ought to be treated
> > > as forwards. Treating those instances as forwarding would patently
> > > break SPF.
> >
> > I don't understand the difference between a relay and a forward pass,
> > or why it matters. Why would you relay or forward mail for a domain
> > that doesn't give you whatever authorization you ask for?
>
> "Relaying" in the sense used by Mark above refers to the _sender_'s setup.
> "Forwarding", however, is almost always set up by the _receiver_. Senders
> can always account for their sending infrastructure in their SPF records.
> Receivers, on the other hand, don't publish SPF records, so they have to
> be aware of their forwarding infrastructure when checking senders' SPF
> records.


OK, so I will use the term "relaying",in this discussion, and assume at
least a contractual relationship between the original sender and the relay.
I will use "forwarding" as I originally intended, to mean what happens on
the receiver's side.


> > > > why not just use the HELO name to authenticate an incoming IP
> > > > address?
>
> You don't authenticate IP addresses. Those are inherently authentic.


I should have said "authenticate using the IP address".

>
> What needs to be authenticated are identities such as HELO or MAIL FROM
> that are NOT inherently authentic. If you just want to use one of those
> identities for a reputation system, then choosing which one to use is
> just a matter of the desired granularity. If however you want to use the
> MAIL FROM for sending bounces or similar purposes, then authenticating
> HELO doesn't help you.


Understood.

>
> > > But it doesn't help you one bit in determining whether relay X is
> > > authorized to send domain Z in MFROM.
> >
> > Why do we care? If Y is reputable, and it says X is OK, we have what
> > we need. If Z is forged, we tell Y, and they fire X.
>
> Except that the firing X part doesn't always happen (or it doesn't happen
> quickly enough) in reality.


Then Y is responsible, and their reputation will suffer accordingly. We
really don't care about Y's motivations, competence, or anything else. All
we want to know is how much spam do they allow from their authorized IP
addresses.

-------------------------------------------
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=82210203-4a958f
Powered by Listbox: http://www.listbox.com

On Jan 5, 2008 12:02 PM, Julian Mehnle <julian@mehnle.net> wrote:

> David Woodhouse wrote:
> > why would you need multiple handles for the same sending host?
>
> Because of many domains sending through a common host, some domains may be
>
> sending mostly spam whereas other may be sending mostly non-spam. Your
> answer to that is probably: "Why accept mail from a spammy host, even if
> some mail is good? The good users can always switch to a different
> service provider that is less spammer-friendly."


I wouldn't expect the users to switch, unless their service really was a
spammer network. A more realistic alternative for competent and honest
hosting services would be to segregate the spam-free ordinary mail from
whatever mailing-list service, etc. is causing the problem, and use a
different HELO name (handle) for the spam-free mail. An example would be
advertising.com, which handles huge mailing lists for charitable
organizations like redcross.org. There is no need to mix ordinary user mail
with this flow, even if the sending hosts are the same.

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