Mailing List Archive: SPF: Discuss

Tracking userids --was: SPF, DKIM, and NIH

Index | Next | Previous | View Threaded

vesely at tana

Oct 17, 2009, 6:06 AM

Post #1 of 7 (103 views)
Permalink

Tracking userids --was: SPF, DKIM, and NIH

Ian Eiloart wrote:
>> Without having some kind of worldwide individual identity system, it just
>> can't be done.
>
> No, we can.

At the university of Sussex, you mean?

> What I mean by "spoofed" is that the email was sent from the
> account that it claims to be sent from. For gmail, for example, a valid
> DKIM signature is enough that I can assign reputation to the purported
> author. I don't need a worldwide ID system, I just need to know that the
> account that I'm judging is the correct one.
>
> As an admin, I can't just reject all gmail email. I have no choice but
> to try to distinguish between good and bad senders. However, I can
> assign a default reputation to ESPs like gmail, for previously unseen
> users in their domain.

That seems a very clever work to me. I have two very basic questions
about it:

1) How large does your database grow?

2) Do you [think to] publish that data?

Assuming that you reckon senders' reputation based on your users'
complaints, if you forward them (or an anonymized version thereof) to
google, you may be able to track their reactions, if any. Did you ever
[try to] get in touch with google about such results? What percentage
of gmail's users do you think you are tracking?

I'm also curious about possible generalizations. For different
identities of the same user, gmail adds --and signs-- a Sender header.
That's not a universal practice. Some other mail sites may mention the
authenticated id in their Received header. How do you handle those cases?

TIA for expanding this subject

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

iane at sussex

Oct 19, 2009, 2:35 AM

Post #2 of 7 (97 views)
Permalink

Re: Tracking userids --was: SPF, DKIM, and NIH [In reply to]

--On 17 October 2009 15:06:11 +0200 Alessandro Vesely <vesely[at]tana.it>
wrote:

> Ian Eiloart wrote:
>>> Without having some kind of worldwide individual identity system, it
>>> just can't be done.
>>
>> No, we can.
>
> At the university of Sussex, you mean?

I'm not talking about what we do at Sussex, I'm talking about what I'd like
to see in future. It's possible that it could provide some benefit now, but
the benefit would increase as SPF and DKIM become more widely deployed.

I mean that you don't need a comprehensive worldwide individual identity
system in order to assign reputation to email sender addresses. What you
need to do is (a) verify the sender address domain with DKIM or SPF, and
(b) make reasonable assumptions about the operation of the domain.

I think it's reasonable to assume that a domain operator won't permit one
user to spoof another user's sender address. If that's untrue, then the
domain's users and managers will need to sort out any negative
consequences.

>> What I mean by "spoofed" is that the email was sent from the
>> account that it claims to be sent from. For gmail, for example, a valid
>> DKIM signature is enough that I can assign reputation to the purported
>> author. I don't need a worldwide ID system, I just need to know that the
>> account that I'm judging is the correct one.
>>
>> As an admin, I can't just reject all gmail email. I have no choice but
>> to try to distinguish between good and bad senders. However, I can
>> assign a default reputation to ESPs like gmail, for previously unseen
>> users in their domain.
>
> That seems a very clever work to me. I have two very basic questions
> about it:
>
> 1) How large does your database grow?

Probably not as large as the IPv6 address space. Probably not as large as
the indexes on my mailstore.

> 2) Do you [think to] publish that data?

Yep. I imagine that sender reputation services will become as widespread as
IP reputation services. Maybe that's what you mean by a "worldwide
individual identity system"? In which case, the answer is yes. However, it
may only be necessary to publish individual addresses with scores that
differ greatly from the domain default; known spammers or well behaved bulk
senders.

> Assuming that you reckon senders' reputation based on your users'
> complaints, if you forward them (or an anonymized version thereof) to
> google, you may be able to track their reactions, if any. Did you ever
> [try to] get in touch with google about such results? What percentage of
> gmail's users do you think you are tracking?

> I'm also curious about possible generalizations. For different identities
> of the same user, gmail adds --and signs-- a Sender header. That's not a
> universal practice. Some other mail sites may mention the authenticated
> id in their Received header. How do you handle those cases?
>
> TIA for expanding this subject
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/
> Powered by Listbox: http://www.listbox.com

--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

vesely at tana

Oct 19, 2009, 5:06 AM

Post #3 of 7 (98 views)
Permalink

Re: Tracking userids --was: SPF, DKIM, and NIH [In reply to]

Ian Eiloart wrote:
> I'm not talking about what we do at Sussex[...]

Ooops, I misunderstood your words :-(

> I mean that you don't need a comprehensive worldwide individual identity
> system in order to assign reputation to email sender addresses. What you
> need to do is (a) verify the sender address domain with DKIM or SPF, and
> (b) make reasonable assumptions about the operation of the domain.

Agreed.

> I think it's reasonable to assume that a domain operator won't permit
> one user to spoof another user's sender address. If that's untrue, then
> the domain's users and managers will need to sort out any negative
> consequences.

The point is how well it's possible to either corroborate or dispute
such an assumption based on statistical evidence. That assumption is
not reasonable in general, a policy statement and some other knowledge
about the domain are needed.

>> 2) Do you [think to] publish that data?
>
> Yep. I imagine that sender reputation services will become as widespread
> as IP reputation services. Maybe that's what you mean by a "worldwide
> individual identity system"? In which case, the answer is yes. However,
> it may only be necessary to publish individual addresses with scores
> that differ greatly from the domain default; known spammers or well
> behaved bulk senders.

If the domain cooperates, they would take steps so as to stop those
[ab]users. In such case, while publishing all the data may still be
useful for checking the veracity of your activity, only your word
about the domain's cooperation is strictly necessary. I'd call such
activity vouching for that domain, in rfc5518's sense.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

iane at sussex

Oct 19, 2009, 6:43 AM

Post #4 of 7 (97 views)
Permalink

Re: Tracking userids --was: SPF, DKIM, and NIH [In reply to]

--On 19 October 2009 14:06:37 +0200 Alessandro Vesely <vesely[at]tana.it>
wrote:

> Ian Eiloart wrote:
>> I'm not talking about what we do at Sussex[...]
>
> Ooops, I misunderstood your words :-(

My careless phrase, I think :-)

>> I mean that you don't need a comprehensive worldwide individual identity
>> system in order to assign reputation to email sender addresses. What you
>> need to do is (a) verify the sender address domain with DKIM or SPF, and
>> (b) make reasonable assumptions about the operation of the domain.
>
> Agreed.
>
>> I think it's reasonable to assume that a domain operator won't permit
>> one user to spoof another user's sender address. If that's untrue, then
>> the domain's users and managers will need to sort out any negative
>> consequences.
>
> The point is how well it's possible to either corroborate or dispute such
> an assumption based on statistical evidence. That assumption is not
> reasonable in general, a policy statement and some other knowledge about
> the domain are needed.

The assumption may not be true in general, but it would be better if it
were. Domains should be encouraged to prevent such spoofing, and I think
that the assumption is reasonable in the following sense:

a) Where businesses, like ours, permit intra-domain spoofing, they should
take care that it's not used to send unwanted mail; in order that one user
cannot harm the reputation of another. For example, we know that our
webmail service gets abused, so we apply rate limits, and don't permit
spoofing by our webmail users. The rate limits reduce the harm done when an
account is compromised, and the anti-spoofing policy ensures that any email
address based reports or sanctions are applied to the correct account.

b) Where email service providers like gmail can't establish a relationship
between two domain users, they simply should not permit the spoofing. They
may wish to establish an infrastructure whereby users can express trust
relationships - their domain hosting service might be regarded as having
that property.

c) Generally: where intra-domain spoofing is permitted, it must be regarded
as entirely at the risk of the domain and its users. If one user harms the
reputation of another, that should be regarded as an internal affair, to be
sorted out between the users and the domain owner. It's not the business of
any third party to try to guess how the domain handles intra-domain
spoofing.

--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

macquigg at ece

Oct 19, 2009, 7:00 AM

Post #5 of 7 (97 views)
Permalink

Re: Tracking userids --was: SPF, DKIM, and NIH [In reply to]

Alessandro Vesely wrote:

>>> 2) Do you [think to] publish that data?
>>
>> Yep. I imagine that sender reputation services will become as
>> widespread as IP reputation services. Maybe that's what you mean by a
>> "worldwide individual identity system"? In which case, the answer is
>> yes. However, it may only be necessary to publish individual
>> addresses with scores that differ greatly from the domain default;
>> known spammers or well behaved bulk senders.
>
> If the domain cooperates, they would take steps so as to stop those
> [ab]users. In such case, while publishing all the data may still be
> useful for checking the veracity of your activity, only your word
> about the domain's cooperation is strictly necessary. I'd call such
> activity vouching for that domain, in rfc5518's sense.

Domain reputation data is rarely published, because it is the key
ingredient in a commercially successful spam-blocking service. Most
services that rely on reputation, try to not even let customers know
what they are doing. It's a "competitive advantage" buried deep in a
complex product advertising lots of other bells and whistles.
Accumulating such data is not difficult, however. Even small domains,
like mine and Stuart's are quite successful at it. My data is publicly
available, and if anyone is interested, I will help set up a similar
system for their domain.

-- Dave

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

vesely at tana

Oct 23, 2009, 6:27 AM

Post #6 of 7 (91 views)
Permalink

Re: Tracking userids --was: SPF, DKIM, and NIH [In reply to]

David MacQuigg wrote:
>>> I imagine that sender reputation services will become as
>>> widespread as IP reputation services.
>>
>> If the domain cooperates, they would take steps so as to stop those
>> [ab]users. In such case, while publishing all the data may still be
>> useful for checking the veracity of your activity, only your word
>> about the domain's cooperation is strictly necessary. I'd call such
>> activity vouching for that domain, in rfc5518's sense.
>
> Domain reputation data is rarely published, because it is the key
> ingredient in a commercially successful spam-blocking service. Most
> services that rely on reputation, try to not even let customers know
> what they are doing.

Then that's snake oil, IMHO. A similar argument should hold for X.509
server certificates: Those who don't say what checks they carry out,
presumably don't actually check anything.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

vesely at tana

Oct 23, 2009, 8:36 AM

Post #7 of 7 (90 views)
Permalink

Re: Tracking userids --was: SPF, DKIM, and NIH [In reply to]

Ian Eiloart wrote:
>>> I think it's reasonable to assume that a domain operator won't permit
>>> one user to spoof another user's sender address. If that's untrue, then
>>> the domain's users and managers will need to sort out any negative
>>> consequences.
>>
>> The point is how well it's possible to either corroborate or dispute such
>> an assumption based on statistical evidence. That assumption is not
>> reasonable in general, a policy statement and some other knowledge about
>> the domain are needed.
>
> The assumption may not be true in general, but it would be better if it
> were. Domains should be encouraged to prevent such spoofing, and I think
> that the assumption is reasonable in the following sense:

Of course you have to take into account that spammers can (and do)
create their own domains.

> a) Where businesses, like ours, permit intra-domain spoofing, they
> should take care that it's not used to send unwanted mail; in order that
> one user cannot harm the reputation of another. For example, we know
> that our webmail service gets abused, so we apply rate limits, and don't
> permit spoofing by our webmail users. The rate limits reduce the harm
> done when an account is compromised, and the anti-spoofing policy
> ensures that any email address based reports or sanctions are applied to
> the correct account.

I think you also don't allow a user to have multiple email addresses,
what wikipedia calls "sock puppetry". Aliases and role addresses may
be allowed by a domain's policy. The right to send messages
anonymously --pseudonymously, really-- must be respected, and
advertising a user's login name in the header brings its own tranche
of risks. Explicitly knowing a domain's policy eases the task of
checking whether it is actually enforced.

> b) Where email service providers like gmail can't establish a
> relationship between two domain users, they simply should not permit the
> spoofing. They may wish to establish an infrastructure whereby users can
> express trust relationships - their domain hosting service might be
> regarded as having that property.

You mean sites.google.com? I don't quite agree: A puppet master may
accumulate several subscriptions, and register different sites with
different identities. Anonymous subscriptions don't allow much trust
to be established.

> c) Generally: where intra-domain spoofing is permitted, it must be
> regarded as entirely at the risk of the domain and its users. If one
> user harms the reputation of another, that should be regarded as an
> internal affair, to be sorted out between the users and the domain
> owner. It's not the business of any third party to try to guess how the
> domain handles intra-domain spoofing.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com