Subject: Re: [Asrg] VPNs vs consent

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 01 Jul 2009 16:46:32 +0200

Claudio Telmon wrote:
> Jose-Marcio Martins da Cruz wrote:

> 
> I need some more clarification on this, maybe it's just me not knowing
> enough about MTAs internals. As the border MTA receives a RCPT TO for
> either of these addresses, it should be able to know if it is a valid
> address. In my (very limited) experience, this means that each of these
> addresses mut be defined as a valid address, the MTA doesn't have rules
> to decide that since jose-marcio.martins_da_cruz is a valid address,
> jose-marcio.martins must be valid too. So, if each of these addresses is
> individually defined in some list/database accessed by the MTA, then
> with the same rules, the related token database should be accessed too.
> Should an "automatic aliasing" rule exist, then the same rule could
> exist for the token database. Also, if "somewhere" an alias is defined
> for an address, then the correspondent database could just be a pointer
> to the database of the "main" address. This could even implement "chains
> of aliases" as "chains of pointers to token databases".

The border MTA surely knows a list of valid addresses, but it may not know, all the time, 
that all this addresses resolve to the same login - sometimes some addresses are resolved 
in the final internal servers.

But well, you can find some organisations with this kind of thing nowadays. Don't know if 
this shall be taken into account to design future systems.

> I think this is feasible with an appropriate address book manager.
> Anyway, the load is for the MUA, not for the MTA, so the number of users
> shouldn't matter.

Hmmm. If the border MTA accept and the MUA reject by lack of consent, a bounce is generated.

-- 
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           http://j-chkmail.ensmp.fr
  Ecole des Mines de Paris
  60, bd Saint Michel                      75272 - PARIS CEDEX 06
  mailto:[email-masked]

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 01 Jul 2009 18:32:41 +0200

> 
> Surely, but that's not what I mean. Once the address book manager knows
> that it must handle a list of (receiver) addresses aliases that will
> share the same tokens, it will push those tokens to the MTA, so that the
> MTA will have a valid list of tokens for the various aliases and reject
> messages as required.

This means defining some new protocol between the MTA and MUAs to push these tokens ???

Don't know exactly what/how you're intending with this, but the more complicated you 
imagine things, the less probable is it to be widely accepted.

---

From: Claudio Telmon <[email-masked]>
Date: Wed, 01 Jul 2009 18:48:05 +0200

> This means defining some new protocol between the MTA and MUAs to push

Yes, this is a critical part of the framework since the beginning :)

> Don't know exactly what/how you're intending with this, but the more
> complicated you imagine things, the less probable is it to be widely
> accepted.
> 

I know. However, this is the part of the framework that I see as least
critical in terms of acceptance. Both the MUA and the MTA will need some
add-on/patch/whatever in order to implement the protocol, so this part
of the framework will come "with the patch".
While I have a couple of ideas on how this could be accomplished, the
MTA token database management issue is one of the two I'm still looking
for comments, the other being whether it is true that spam in "small
text messages" would be easier/lighter to deal with by antispam tools.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Claudio Telmon <[email-masked]>
Date: Wed, 01 Jul 2009 18:23:59 +0200

Jose-Marcio Martins da Cruz wrote:
> The border MTA surely knows a list of valid addresses, but it may not
> know, all the time, that all this addresses resolve to the same login -
> sometimes some addresses are resolved in the final internal servers.
> 
> But well, you can find some organisations with this kind of thing
> nowadays. Don't know if this shall be taken into account to design
> future systems.
> 

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Thu, 02 Jul 2009 12:46:53 +0200

> text messages" would be easier/lighter to deal with by antispam tools.

I'll take a deeper look into this (but I don't have enough time now).

I have the feeling that this is part of a larger problem which is how to inform a border 
SMTP gateway about caracteristics of final addresses in internal mail servers.

One example we were talking about is just what are the valid internal addresses which, 
with your needs for the consent framework, is a sub problem of the larger one.

For the problem of checking the validity of internal addresses (e.g.), there are many 
solutions, but none of them is perfect.

Maybe this problem could be taken out of your proposal and handled as a global one.

---

From: Claudio Telmon <[email-masked]>
Date: Thu, 02 Jul 2009 12:57:14 +0200

Jose-Marcio Martins da Cruz wrote:

> I have the feeling that this is part of a larger problem which is how to
> inform a border SMTP gateway about caracteristics of final addresses in
> internal mail servers.
> 
> One example we were talking about is just what are the valid internal
> addresses which, with your needs for the consent framework, is a sub
> problem of the larger one.
> 
> For the problem of checking the validity of internal addresses (e.g.),
> there are many solutions, but none of them is perfect.
> 

I think you're right, and I actually highlighted this as a "plus" of the
proposal. The ability (in my case for the user) to push some simple
information to the border MTA (in my case, acceptable tokens) so that
messages can be dropped/rejected/accepted earlier, can be very useful
IMHO. In this specific case, messages can be rejected, that otherwise
the final receiver could otherwise only delete from its mailbox.
This should be also what Danny Angus meant in his first message in the
thread.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Claudio Telmon <[email-masked]>
Date: Thu, 02 Jul 2009 14:45:21 +0200

Jose-Marcio Martins da Cruz wrote:
>>>> official contact addresses of companies.
>>> In fact, at our domain, few of these kind of adresses aren't protected.
>>> Most of them are adresses of the kind "everybody in the engineering
>>> department" (addresses which are of internal use only) "butterfly
>>> research workgroup" (a closed group working on some particular subject)
>>> and so. These are adresses which *are* protected and the concept of
>>> consent-enable is materialized by checking if the SMTP client sending
>>> messages to is in some known network or if the connection was
>>> authenticated. But nothing prevents that this kind of consent should be
>>> expanded. Either way, in an organisation like the ours, users couldn't
>>> understand that the same consent system used for individual addresses
>>> couldn't be used for collective addresses.
>>
>> This is a very interesting case. I'll have to think at the implications
>> of it.
> 
> You got the message ! 8-)

So, I think I can give some answers now. There are many many different
cases, so I will only deal with the most (IMHO) representative ones, the
others should be very similar.

The main issues are:
- how people are added to the list of correspondents for shared address;
- how to send messages to the shared address
- how to send answers from the shared address

I can see two kinds of "shared addresses": addresses that are
forwarded/expanded to a group of actual recipients, and "shared
mailboxes" where many people can read messages. In many cases, this
second case means that the shared mailbox is accessed through a web
interface, and this solves many problems (e.g. tokens stay with the
interface/mailbox, whoever uses it). This is the case of many CRM tools.
Problems may arise with people accessing a shared mailbox through
personal MUAs.

With respect to "adding people to the list of correspondents", while the
decision about adding people can be complex (unanimity, majority, etc),
from a technical perspective, what matters is who is entitled to push
tokens to the MTA for that address: whoever can push tokens can add
correspondents.

There are two main cases which may cause some problems, while some
others are very similar. Most cases shouldn't be a problem.

1. "Forwarding style" shared address. Sender A, with a consent-enabled
address and not being part of the group, writes to the shared address.
The message will carry a valid token to be used in answers. In "mailing
list style" addresses, this token wouldn't be forwarded to the group,
but this would mean that nobody could send answers, so in this case the
token must be forwarded with the message. This is just a matter of
configuration of the forwarding agent. B, member of the group, could
send answers either from a personal address (providing to A a token for
this personal address) or from the shared address. In this last case, B
must be able to push a token for the shared address on the MTA. This is
consistent: B can use a consent-enabled address as sender only if he can
push tokens for that address. All this means that the choice to forward
or not to forward tokens must be configurable in forwarding agents.

Note that B may already own a personal token for A, due to a personal
contact. In this case, B may be required to hold different tokens for
the same correspondent. Privacy and anonymity issues are not different
from those already discussed in the paper.

Note also that all members of the shared address group would share the
same tokens for the shared address correspondents, which is consistent
with the concept of shared address, but nonetheless reduces the ability
to point out how these tokens could have been compromised/exposed by one
of these persons.

2. "Shared mailbox style" shared address, accessed through personal MUA.
 Again, A sends a message to the shared address. Problems may arise if B
downloads the message to its MUA and then deletes it from the mailbox,
since the other members of the group wouldn't receive the token required
to send messages to A. In this case, B should respond with its own
personal address as sender, since otherwise other members of the group
could be required to deal with subsequent messages, which are from a
sender they can not send messages to. This is usually consistent, since
other members of the group would miss some of the answers anyway, unless
these are sent in Cc: to the shared address. Should B be required to
answer from the shared address, then in this very specific case a way to
share A's token would be required. Note that since the problem is with
A's token, not enabling consent for the shared address won't solve the
problem. Note also that the whole problem depends on B deleting the
message from the mailbox, so that other members can't access it and
collect the token.

The same problem may arise with new members of the group accessing the
shared address, be it "forwarding" or "shared mailbox" style: they will
miss the tokens provided to the address by correspondents before then,
so once added to the group they will need to receive a full set of
tokens, e.g. within a message confirming their inclusion in the group.

As usual, it's up to A to decide if messages conforming the "consent
request" constraints, but not carrying tokens, can be delivered, in
order to deal with correspondents not implementing the consent
framework, including shared addresses.

So, all in all, I think that the shared address case can be dealt with
in the framework, only some specific cases may require a way to share
tokens.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Bill Cole <[email-masked]>
Date: Thu, 02 Jul 2009 13:37:14 -0400

Alessandro Vesely wrote, On 6/30/09 4:41 AM:
[...]
> Thanks for confirming that. My feeling is that we are overloading IP
> numbers with an accountability functionality that doesn't belong there.

There's a strong reason for this: the immediate client IP is the one fact 
about *every* MX-driven attempt at message transport that the receiving MTA 
can know with very high certainty, even when the message is originated by 
someone who intentionally and maliciously tries to hide his identity.

Whether accountability *should* be tied to that one knowable fact is a 
philosophical question. As a practical matter, there has proven to be little 
choice. For some years early in the growth of spam, filtering techniques 
were applied and over time largely discarded or relegated to scoring systems 
which assumed that spammers would not falsify other elements of mail and its 
transport that should lead back to the ultimate originator or to someone who 
can identify and police the originator. Having run out of headers and 
transport features to check, we've developed new things like SPF and DKIM 
that are  harder to spoof but suffer from inadequate adoption to really fix 
a large part of the problem, much as the previous transport and content 
encryption and signing mechanisms have.

---

From: Bill Cole <[email-masked]>
Date: Thu, 02 Jul 2009 13:37:16 -0400

---

From: Bill Cole <[email-masked]>
Date: Sat, 04 Jul 2009 12:05:36 -0400

Alessandro Vesely wrote, On 6/25/09 7:37 AM:
> For example, assume someone trusts Gmail's egress filtering

I'll play along. It is certainly possible that for some recipients, the 
stream of mail from Google's sewer is cleaner than what I see...

> and wants to
> skip content filtering for mail coming from there. What work is required
> to accomplish (and maintain) that task, on typical MTA software?

I'm going to assume you don't mind an answer based on a common add-on to 
common MTA software: SpamAssassin hooked into Sendmail or Postfix via one of 
the multiple 'milter' packages that will do that. SA can be hooked into 
other MTA's as well and is a component in some commercially packaged 
spam-filtering appliances, so I think it is reasonable to consider it 
"typical" even it is technically is not an integral part of any MTA.

This is a situation where SPF is a useful tool. If I want to make sure that 
SpamAssassin never deems mail from a [email-masked] address to be spam as long 
as it gets an affirmative SPF match (i.e. is coming from what Google says 
are its normal gmail.com outbounds) I would just add this to my local 
SpamAssassin config:

whitelist_from_spf [email-masked]

SPF can handle well the problem of whitelisting the normal outbound paths 
for a complex mail system that isn't persistently congruent with a set of 
hosts whose FQDN's share a domain tail or a small number of networks with 
clean octet boundaries (e.g. a small number of /24 ranges). Most major MTA's 
can directly define trusted networks based on octet or CIDR notation and 
trusted domains based on verified client hostnames patterns, so in many 
cases of simpler sending systems whitelisting does not require SpamAssassin 
or other SPF-based mechanisms. For complex senders who have complex and 
dynamic outbound environments, refuse to publish SPF records, but do use 
DKIM (e.g. Yahoo) there is probably some way to use DKIM as the 
authentication that a message is coming from a system that you trust. I 
can't say how easy or hard that would be, since I've never seen enough 
marginal value in DKIM to bother with it.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 06 Jul 2009 12:35:10 +0200

> stream of mail from Google's sewer is cleaner than what I see...

Upthread, you also wrote that they "have shunned the entire notion of 
accountability". What do you see?

Of course, one cannot compare one of those freemail providers with a 
private mail domain, operated by skilled staff, where new accounts are 
added wittingly, used by an elite of cautious people who rarely catch 
viruses, if ever. In the latter case, you don't have to resort to 
statistics to measure the quality of messages.

The big four, much like connection providers' default mailers, have to 
operate some kind of surveillance on what their users send. I wonder 
if they have specific conventions or settings to relay mail from one 
to another, since that probably accounts for a large chunk of their 
traffic.

> This is a situation where SPF is a useful tool. If I want to make sure 
> that SpamAssassin never deems mail from a [email-masked] address to be spam 
> as long as it gets an affirmative SPF match (i.e. is coming from what 
> Google says are its normal gmail.com outbounds) I would just add this to 
> my local SpamAssassin config:
> 

That kinds of setting cleverly enable whitelisting by domain. However, 
compared to the VPN paradigm, that setting is unilateral. At Gmail, 
they don't now they're whitelisted.

> For complex senders who have complex and dynamic outbound 
> environments, refuse to publish SPF records, but do use DKIM (e.g. 
> Yahoo) there is probably some way to use DKIM as the authentication that 
> a message is coming from a system that you trust. I can't say how easy 
> or hard that would be, since I've never seen enough marginal value in 
> DKIM to bother with it.

Browsing docs[1], it seems that

   whitelist_from_dkim [email-masked]

should work similarly. Domain Keys (whitelist_from_dk) is the 3rd one 
of the three types of whitelist from authentication (whitelist_auth) 
that SA does. So, if a sender knows that you filter with SA, they may 
try all of them in turn, blindly.

[1 
http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Plugin_DKIM.html]

---

From: Bill Cole <[email-masked]>
Date: Mon, 06 Jul 2009 23:39:25 -0400

Alessandro Vesely wrote, On 7/6/09 6:35 AM:
>> I'll play along. It is certainly possible that for some recipients,
>> the stream of mail from Google's sewer is cleaner than what I see...
>

The overwhelming majority of mail I am offered by the Gmail outbounds is 
spam. Google has played games with how they will accept abuse reports, 
giving the appearance of not really wanting them.

> operate some kind of surveillance on what their users send. I wonder if
> they have specific conventions or settings to relay mail from one to
> another, since that probably accounts for a large chunk of their traffic.

Large cheap and free mail providers understand the advantage they get from 
their scale in not needing to do as well with egress filtering as smaller 
mixed sources of mail. There is very little risk to them of missing 95% of 
their outbound spam, as long as they never drop legitimate outbound mail and 
keep their outbound legitimate mail volume large enough that it is hard for 
many sites to treat their mail as presumptive spam.

>> that SpamAssassin never deems mail from a [email-masked] address to be
>> spam as long as it gets an affirmative SPF match (i.e. is coming from
>> what Google says are its normal gmail.com outbounds) I would just add
>> this to my local SpamAssassin config:
>>
> compared to the VPN paradigm, that setting is unilateral. At Gmail, they
> don't now they're whitelisted.

For the vast majority of receiving sites, they have no significant reason to 
care. The number of receiving systems whose mail filtering policies matter 
to large freemail providers is small enough to be managed as a collection of 
bilateral relationships rather than through public open standards.

In my direct experience working on middling corporate mail systems and 
dealing with people handling much larger cheap/free "consumer" mail systems, 
I had some tests of whether they cared about how we treated their mail, and 
saw no sign that they did. At least some don't even seem to care when fairly 
prominent corporations urge their smaller business partners to avoid their 
non-free mail service. What they care about in getting their users' mail 
delivered is the dozen peers to whom they send 80% of their messages and 
maybe the next score down in size that handle another 15%. It's not rational 
for them to care about systems with 10k users or less.

>> Yahoo) there is probably some way to use DKIM as the authentication
>> that a message is coming from a system that you trust. I can't say how
>> easy or hard that would be, since I've never seen enough marginal
>> value in DKIM to bother with it.
>
> should work similarly. Domain Keys (whitelist_from_dk) is the 3rd one of
> the three types of whitelist from authentication (whitelist_auth) that
> SA does. So, if a sender knows that you filter with SA, they may try all
> of them in turn, blindly.

DK is obsolete, FWIW.

Using SPF to vouch for a SMTP client IP and/or DKIM signatures to make some 
headers believable is valuable between the big providers because it is 
useful for them to have some easy basis for trusting each other that is hard 
to fake. Others who use those tools for domain-wide trusting of the large 
providers may or may not be acting rationally, depending on the sort of mail 
they actually see from the large providers. No mail system I've worked on in 
the past decade has had a mail stream from any major freemail provider that 
has been less than 50% spam, and that makes any means of domain-wide 
whitelisting for them hard to rationalize.

That said, the general idea of domain-wide whitelisting is widely useful for 
better-run domains and while many domains for which it makes sense are 
simple enough to whitelist without SPF or DKIM, it does not hurt to have 
those tools available. Perversely, they have significantly reduced the 
marginal value available for any new tools that do slightly different sorts 
of domain-wide authentication. Put more directly: the practical value of 
VHLO is reduced by the fact that SPF and DKIM are widely available.

---

From: der Mouse <[email-masked]>
Date: Tue, 7 Jul 2009 03:05:56 -0400 (EDT)

> The overwhelming majority of mail I am offered by the Gmail outbounds
> is spam.  Google has played games with how they will accept abuse
> reports, giving the appearance of not really wanting them.

Why should they care?

> There is very little risk to them of missing 95% of their outbound
> spam, as long as they never drop legitimate outbound mail and keep
> their outbound legitimate mail volume large enough that it is hard
> for many sites to treat their mail as presumptive spam.

As long as their big recipients give them a free pass on their spam
spewage because of the large number of human shields, I see no reason
why it makes any sense for them to care about the spam they emit.

Oh, and, as long as no responsibility comes with the resources they are
granted authority over, of course, but that's given in today's net.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 07 Jul 2009 12:28:20 +0200

Vouch By Feedback could be a useful modification of the Vouch By 
Reference standard, if it didn't break its installed base.

VBF adds a DNS record pointing from the vouched domain to the 
vouching server email address. It could be an RP RR type, where the 
address is meant to receive the message/feedback-report (AFR) 
complaints. Web is-spam buttons direct reports to the ESP, who 
should forward them to any sender's vouching service. Clients who 
implement FBLs might send them to the relevant voucher directly. 
Vouchers, in turn, shall forward reports to the accountable 
originating ESP. The latter shall ban guilty users from sending for 
an amount of time proportional to the number of complaints. If the 
voucher sees complaints against users who should have been banned 
from sending, it shall suspend its vouching service for the relevant 
sender.

The second difference, the one that breaks compatibility, is that it 
would be more meaningful if the content of the _vouch TXT RR were a 
timestamp, rather than the type of message. Rehabilitated ESPs will 
get a new timestamp. That way, a recipient can quickly discern a 
long and honorable service from may-be-spammer newbies, and 
whitelist the former.

> giving the appearance of not really wanting them.

I keep hearing differing opinions on that. At least, it should be 
"benign spam", in the sense that the sender is identifiable, unlike 
botnets' "malign spam".

Benign spam is indeed that kind of social phenomenon that some say 
about spam in general. It is too easy to give way to the temptation 
of advertising something that one believes in. Decent or better ESPs 
can control such phenomenon by educating or mildly punishing their 
users. Users who sent to honeypots after they bought an illegal 
Maddress CD should be punished more severely.

> dealing with people handling much larger cheap/free "consumer" mail 
> systems, I had some tests of whether they cared about how we treated 
> their mail, and saw no sign that they did. At least some don't even seem 
> to care when fairly prominent corporations urge their smaller business 
> partners to avoid their non-free mail service. What they care about in 
> getting their users' mail delivered is the dozen peers to whom they send 
> 80% of their messages and maybe the next score down in size that handle 
> another 15%. It's not rational for them to care about systems with 10k 
> users or less.

By the same argument, middling mail system don't expect that anyone 
would subscribe to their FBL, even if they offered it prominently on 
their web sites. As I have such a tiny mail system, nobody would 
care to spend their time on whitelisting it, even if I could offer 
any required guarantees (let alone the time to look at them.) 
Doesn't that affect network neutrality, or even democracy, some way? 
We can take care of minor mail domains by automating whitelisting 
and FBL subscriptions.

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 7 Jul 2009 08:14:53 -0400 (EDT)

> Alessandro Vesely wrote, On 7/6/09 6:35 AM:
...
> spam. Google has played games with how they will accept abuse reports, giving 
> the appearance of not really wanting them.
>

Are these messages disguised in any way? Just looking at my last week's 
mail, there are 120 messages with "gmail.com" in the envelope-from. Two of 
these are spam, or about .2% of my incoming spam. Am I measuring the wrong 
thing? Or do different users have a different experience of spam? My 
account has been fairly public for over 15 years, so if an MTA were 
spewing a significant proportion of the worlds spam, wouldn't I be getting 
some?

Daniel Feenberg

---

From: David Wilson <[email-masked]>
Date: Tue, 07 Jul 2009 14:06:10 +0100

> reports, giving the appearance of not really wanting them.

This is not our experience, so I was surprised, and had a look over the
last few days. We get a lot of main allegedly from 'gmail.com', but the
vast majority of that is not from gmail.com hosts. As the SPF info
has ?all, these get a NEUTRAL SPF status (and the sources mostly don't
get past Spamhaus). Not many of the messages which get an SPF PASS from
gmail.com are actual spam. And the great majority of the spam are 419
type scams, or other advance fee/financial scams.

[There was one rather nice "you've won a lottery" message sent to a
honeypot address which informed the recipient that they had won 

  "£2,500,000 (2 million, 5 hundred Great British Pound Starlings)"

That's a lot of rather heavy birds!]

I guess that 419 scammers, unlike most spammers, want a reply to their
message, so send it from an actual account used by an actual person.

A couple of weeks ago, the gmail.com account of someone we deal with was
hacked, and used to send spam. We saw a couple of messages, and one had
several recipients, which were clearly from that user's address book.
So, it was not being used for general spamming, but only to send
messages to those likely to have the sender in their address book, and
so avoid anti-spam measures, I presume.

It is perhaps not surprising that different sites see different
patterns. But we do not see the actual google outbound MTAs (as
indicated by the SPF info for _spf.google.com) as a significant source
of spam.

best regards

David

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 07 Jul 2009 14:13:09 -0600

> Reference standard, if it didn't break its installed base.

What installed base?

> VBF adds a DNS record pointing from the vouched domain to the vouching
> server email address. It could be an RP RR type, where the address is
> meant to receive the message/feedback-report (AFR) complaints. Web
> is-spam buttons direct reports to the ESP, who should forward them to
> any sender's vouching service. Clients who implement FBLs might send
> them to the relevant voucher directly.

Variations of this theme have been discussed dozens of times, always trying 
to piggyback on some other technology: SPF (which doesn't make sense), DKIM 
(which almost makes sense), et cetera.

The problem, unfortunately, is that the use cases are unclear.  I'd 
recommend starting by defining those cases -- not merely "I want to send 
complaints about spam" or "I want to receive complaints so my mail doesn't 
get blocked," but every possible permutation, end-to-end.

It could make for an interesting research project.

 > Vouchers, in turn, shall forward
> reports to the accountable originating ESP. The latter shall ban guilty
> users from sending for an amount of time proportional to the number of
> complaints. If the voucher sees complaints against users who should have
> been banned from sending, it shall suspend its vouching service for the
> relevant sender.

Here you're getting out of the technology, and into dictating behavior.  I 
wouldn't be surprised if the agreements between message sender, voucher, and 
message receiver end up looking something like what you describe, but the 
technology should be agnostic and let those three parties make any agreement 
they feel is appropriate for their individual situations.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 08 Jul 2009 09:54:33 +0200

>> Reference standard, if it didn't break its installed base.

For one,

  MDaemon mail server software uses the advanced email authentication
  techniques of Vouch By Reference (VBR) and validates and signs
  messages using DKIM, DK, Sender-ID, and SPF.
  http://www.mdaemon.co.nz/Products/MDaemon

> Variations of this theme have been discussed dozens of times, always 
> trying to piggyback on some other technology: SPF (which doesn't make 
> sense), DKIM (which almost makes sense), et cetera.

Basically, it should leverage SUBMIT. While DKIM may sign the From 
or Sender headers, it doesn't assure that the content of that field 
has been authenticated, IIRC. Actully, we need a weaker statement: 
that some of the signed headers has enough information for the 
originating server(s) to recover the authenticated identity of the 
submitter. That allows for anonymous sending.

> complaints about spam" or "I want to receive complaints so my mail 
> doesn't get blocked," but every possible permutation, end-to-end.

Improper use of TIS buttons was discussed some months ago. "I want 
to ban from sending whoever mailed me this" is the new case for them.

> Here you're getting out of the technology, and into dictating behavior. 
> I wouldn't be surprised if the agreements between message sender, 
> voucher, and message receiver end up looking something like what you 
> describe, but the technology should be agnostic and let those three 
> parties make any agreement they feel is appropriate for their individual 
> situations.

Agreed. In that respect, a voucher can mandate that behavior even 
using the existing VBR standard. Only the destination of complaints 
deserves further standardization. Standard AFR is on its way, isn't it?

Dictating behavior should be done by lawmakers, of course. However, 
they cannot write the standards, and may encounter difficulties even 
in identifying the items that populate cyberspace. It seems a 
somewhat tighter cooperation is required in order to sort out an 
effective anti-spam regulation.

---

From: Claudio Telmon <[email-masked]>
Date: Wed, 08 Jul 2009 10:47:37 +0200

...
>> Here you're getting out of the technology, and into dictating
>> behavior. I wouldn't be surprised if the agreements between message
>> sender, voucher, and message receiver end up looking something like
>> what you describe, but the technology should be agnostic and let those
>> three parties make any agreement they feel is appropriate for their
>> individual situations.
> 
> Agreed. In that respect, a voucher can mandate that behavior even using
> the existing VBR standard. Only the destination of complaints deserves
> further standardization. Standard AFR is on its way, isn't it?
> 
> Dictating behavior should be done by lawmakers, of course. However, they
> cannot write the standards, and may encounter difficulties even in
> identifying the items that populate cyberspace. It seems a somewhat
> tighter cooperation is required in order to sort out an effective
> anti-spam regulation.

I think this is a point that needs clarification, but maybe this has
already been discussed in some previous thread. Many of the protocols
proposed here seem to provide accountability. Accountability is not, per
se, an antispam solution. Accountability + some e.g. banning enforcement
mechanism can be. Unless enforcement is an automatic and trivial
consequence of the protocol, I think that it is appropriate to discuss
how it can be achieved and realistic. Otherwise, we could end up with
completely useless protocols. I would dare to say that if enforcement
were trivial, we wouldn't have botnets, which are already illegal.
So I think it was appropriate for Alessandro to describe at least one
way the accountability can be used for enforcement, and thus as
antispam, since it makes a lot of difference if enforcement is expected
to be between ESP and ESP, between an ESP and its customers, between law
enforcement agencies and ESPs, or between law enforcement agencies and
the citizens.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: der Mouse <[email-masked]>
Date: Wed, 8 Jul 2009 10:21:44 -0400 (EDT)

> Accountability is not, per se, an antispam solution.  Accountability
> + some e.g. banning enforcement mechanism can be.

It's not really accountability unless there's an enforcement mechanism,
some kind of calling to account.  (Calling identifiability
"accountability" does not make it that.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 8 Jul 2009 10:17:47 -0400

> giving the appearance of not really wanting them.

Fully agreed.

> Large cheap and free mail providers understand the advantage they get 
> from their scale in not needing to do as well with egress filtering as 
> smaller mixed sources of mail. There is very little risk to them of 
> missing 95% of their outbound spam, as long as they never drop legitimate 
> outbound mail and keep their outbound legitimate mail volume large enough 
> that it is hard for many sites to treat their mail as presumptive spam.

And this in a nutshell is why so many "accountability" proposals,
while curious/interesting academic exercises, are dead-on-arrival in
the real world: these providers are TBTB (too big to block), they know
it, and so no matter how many different technologies are deployed which
repeatedly tell us what we've already known for years (e.g. "Hotmail sends
enormous quantities of spam") nothing useful will happen as a result --
until/unless widespread refusal of traffic comes into play.

---Rsk

---

From: Bill Cole <[email-masked]>
Date: Wed, 08 Jul 2009 11:20:33 -0400

Daniel Feenberg wrote, On 7/7/09 8:14 AM:
> Are these messages disguised in any way?

What do you mean by "any way?"

I do not retain most of them beyond the end of the SMTP session in which 
they are rejected, so I cannot speak to most of their headers. Most have 
gmail.com in the envelope-from, but some do not.

> Just looking at my last week's
> mail, there are 120 messages with "gmail.com" in the envelope-from. Two
> of these are spam, or about .2% of my incoming spam. Am I measuring the
> wrong thing?

Yes and no.

Note that I didn't say that I get much *volume* from the GMail outbounds, 
nor that they are the source of a large fraction of the spam that my server 
is offered, nor that all of the mail I was referring to was aimed at me 
personally or even to any address that has ever been valid.

However, a quick look at the spam that has made it to the point of delivery 
to my main account on that server tells me that about 20% of it is coming in 
via the 209.85.128/17 and 74.125/16 machines that match the SPF record for 
gmail.com. That's only a message or two per week: about half of what is 
offered by those clients for all valid addresses on that system and about a 
third of what they offer in total. In the past 40 days, the legitimate mail 
count for that system from Gmail is exactly 1, but that's artificially high 
because that one was a test message I sent to myself today to make sure that 
I was not missing valid messages in my log searches.

> Or do different users have a different experience of spam?

Is that a serious question? Assuming that it is: yes.

The spam experience of different users is not only non-uniform, it is not 
normally distributed across operationally useful populations like domains or 
receiving systems. Different users get very different volumes and different 
distinct types. The addresses that are targeted by huge volumes of 
completely fraudulent spam from easily-shunned botnets often get little or 
no spam from the 'snowshoe' spammers who like to claim CAN-SPAM compliance 
and may be advertising a product that some people willingly buy, and the 
419'ers who like to use freemail accounts may hit a completely different set 
of users.

> My account has been fairly public for over 15 years, so if an MTA were
> spewing a significant proportion of the worlds spam, wouldn't I be
> getting some?

I don't believe I said that Google's MTA's were spewing a significant 
proportion of the world's spam. Unless you consider the various spamming 
botnets as single entities across all of their nodes, no single entity is 
the source of a significant proportion of the world's spam.

What I did say (based on my own mailbox, my own small mail system with less 
than a dozen users, and some non-ISP, non-academic mail systems with a few 
score to a few thousand accounts) is that most of what Google's outbounds 
offer *to the sorts of systems I work with* is spam. That does not make them 
special among freemail providers, but freemail providers are an unusual 
species of SMTP client: continuously mixed ham/spam, majority spam, high 
total volume, and mixed spam and ham types (many of which are also seen from 
other types of clients.) This makes them part of the heavy lifting of spam 
control for receivers.

---

From: John Leslie <[email-masked]>
Date: Wed, 8 Jul 2009 11:57:04 -0400

>> that it is hard for many sites to treat their mail as presumptive spam.

   This is true, but still there is in practice a _large_ variation in
percentage of spam spewed by the "large" email providers.

> the real world: these providers are TBTB (too big to block),

   "Blocking" the whole "domain" is not the only trick in our bag...

> they know it, and so no matter how many different technologies are
> deployed which repeatedly tell us what we've already known for years
> (e.g. "Hotmail sends enormous quantities of spam") nothing useful will
> happen as a result -- until/unless widespread refusal of traffic comes
> into play.

   "Hotmail sends enormous quantities of spam" isn't a very useful
factlet. Nonetheless, it does allow some email receivers to at least
graylist some Hotmail servers if the envelope-from isn't on a whitelist.

   More useful is something like, "Hotmail MTA #49 is sending more spam
than usual right now: more severe graylisting might be called for."

   Or, your reputation service might say, "We're concentrating our
pressure on Hotmail MTA #49 right now: please give it a hard time."

   The introduction of reputation services creates options for getting
the attention of the folks who maintain the MTAs of the large email
services.

   If we insist on a world without reputation services (or ePostage),
Rich is correct that only "large" email receivers will be able to make a
dent in the practices of "large" email senders.

   :^(

--
John Leslie <[email-masked]>

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 8 Jul 2009 14:25:36 -0400

> than usual right now: more severe graylisting might be called for."

What good does graylisting do to a real MTA?  Unless MTA #49 is sending 
you enough email that forcing it to requeue causes it problems, it won't 
do anything useful.

We've tended to let our automated defenses "fire where they may".  If 
MTA #49 is sending us so much spam that the defenses fire, they fire, 
and we don't whitelist.

If the problem gets bad enough, we block /24s worth.  With MSN and 
Yahoo, that turns out to work particularly well, because at least with 
Nigerian floods and their provisioning methods, specific /24s tend to be 
substantially worse than others.

Then we make a big public & private noise.  And sometimes things get better.

---

From: Dotzero <[email-masked]>
Date: Wed, 8 Jul 2009 15:21:02 -0400

On Wed, Jul 8, 2009 at 2:25 PM, Chris Lewis<[email-masked]> wrote:
> What good does graylisting do to a real MTA?  Unless MTA #49 is sending you
> enough email that forcing it to requeue causes it problems, it won't do
> anything useful.
>
> We've tended to let our automated defenses "fire where they may".  If MTA
> #49 is sending us so much spam that the defenses fire, they fire, and we
> don't whitelist.
>

+1

I think whitelisting has value in forcing senders that want to reach
certain receivers to engage in certain practices. I don't know that
whitelisting buys (or should buy) a sender protection from their own
bad practices. I will add a caveat to what Chris says. Some receivers
do a really good job of tuning their automatic defenses. Others are
not so careful.

> If the problem gets bad enough, we block /24s worth.  With MSN and Yahoo,
> that turns out to work particularly well, because at least with Nigerian
> floods and their provisioning methods, specific /24s tend to be

Sometimes they do. I believe der mouse commented about the big ISPs
not caring. I think they do but are having to deal with aggressive
attacks abusing their systems. On the other hand, life isn't fair <G>.

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 8 Jul 2009 17:26:46 -0400

> attacks abusing their systems. On the other hand, life isn't fair <G>.

 From experience, the people working with the technology care, but they 
sometimes can't get management (especially upper) to take it seriously 
and invest/authorize effort to deal with it.

This is particularly apparent with some ISPs where there are several 
"abusable" services under different management/business units.  Some 
doing fine, others (especially "new" ones) being large-scale abused with 
_no_ effort to deal with any of it.

Nortel's a good size, but yeah, we're still not big enough on our own 
that "just blocking them" will get noticed [+].

The trick is amplifying your apparent size.  PR work.  Make public noise 
where you'll be heard, and getting others (especially moderate voices of 
infrastructures as large or larger) to at least indicate that they see a 
significant problem too and/or have implemented/contemplated 
implementing similar measures.  Blog postings.  Media reports (got a VP 
to contact me once).  Whatever you can pull off.

I'm not so egotistical to think that it was "just me", nor that I was 
even the first in the campaigns where I've applied this, but most of the 
times I've made a serious effort along those lines, the problem _has_ 
gotten better.

It can be a longish term effort.  Sometimes months, not days.  Be 
patient.  It does work often enough to be worth persevering at.  Without 
acting like a loon.  In which case it's just a waste.

[+] Well, once we were contacted by Yahoo about a /24 blocking - they do 
listen to their user's complaints.  Then I explained why.  Got a 
reluctant/embarrassed "I guess that's best".

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 09 Jul 2009 10:08:35 +0100

> "accountability" does not make it that.)

True, but we have a variety of sanctions that we can take against spammers, 
if only we could identify them. Different sanctions require different types 
of identification, and different levels of confidence in the identification.

Knowing the real email address responsible lets us:

1. Contact the owner of a compromised account, and advise them to take 
action.
2. Contact the account service provider.
3. Blacklist the address.
4. Bounce unwanted email back to the sender.

These are all things that we currently can't do for the majority of email.

Knowing for sure the owner of the email address responsible gives us access 
to legal sanctions from small claims courts to imprisonment. Such sanctions 
are available, and have been used in a variety of jurisdictions. Widespread 
spoofing probably means its harder to access these sanctions.

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

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 09 Jul 2009 10:30:11 +0100

> you enough email that forcing it to requeue causes it problems, it won't

It represents a cost to the provider for being sloppy about their account 
management. And, a cost to their users for sticking with an irresponsible 
provider. It's hard to tell your own users, "we don't accept mail from 
Hotmail because some of it's spam", but you might get away with "email from 
Hotmail often takes an hour or two because we need to check that its not 
spam".

And you could, in principle, quarantine a copy of the message during the 
greylist interval (eg, using Exim's "fakedefer" facility). That message 
could be compared with others, to give more accurate content based spam 
scores. You might want to lower your spam threshold if you see several 
copies to distinct recipients, or even from distinct senders.

Or, it could be manually inspected and then rejected next time it is seen. 
I'd like to have some kind of GUI tool that allowed me to see copies of 
greylisted messages in quarantine, so I could flag them up for rejection 
later.

In fact, you could even give such a tool to a user - perhaps putting it 
behind a "this is spam" button!

Finally, if the provider is using SPF or DKIM, and you have a match, then 
you can safely blacklist the sender if you're certain they're spamming. 
That's the beauty of reliable identification mechanisms - it lets me 
blacklist sender addresses in the knowledge that I've got the right address.

> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 9 Jul 2009 07:48:51 -0400

> 1. Contact the owner of a compromised account, and advise them to take  

If the account's compromised, then the new owner may not permit
the former owner to see those communications.

Or

The former owner is unlikely to believe such reports or take any
meaningful action.  For example, they may just abandon the compromised
account, and open a new one...which will shortly be compromised in
the same way.

Or

The former owner will classify these reports as spam/phishes.

Relying on the same end-users who have created the problem to solve
it is a 100% pre-failed strategy.

> 2. Contact the account service provider.

If you can manage to jump through the hoops they've put in place, sure.
But automated reporting will misfire, manual reporting doesn't scale,
and many account service providers simply don't care.  They don't
have to: there are few, if any, meaningful consequences to apathy,
and as long as they're profitable, few of them care about their
responsibilities to the 'net.

> 3. Blacklist the address.

(I'm presuming you mean email address, not IP address.)

Yes, but given that there is an inexhaustible supply of those, this will
block the spam that's not coming any more from yesterday's compromised
account and do nothing to block the spam that's coming tomorrow from
the next compromised account.  This is also a 100% pre-failed strategy.

(Now, if you're talking about IP address, sure: we have very effective
blacklist mechanisms for doing that.)

> 4. Bounce unwanted email back to the sender.

Unwanted mail should always be rejected, never bounced. Doing the
latter not only generates useless traffic but is pretty likely
to generate outscatter/backscatter, which is spam.  And even if
it's correctly delivered, it will do absolutely no good -- see above.

---Rsk
Do NOT send me off-list copies of on-list replies: it's rude and wasteful.

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 9 Jul 2009 08:03:05 -0400

On Wed, Jul 08, 2009 at 11:57:04AM -0400, John Leslie wrote:
> factlet.

It wasn't intended to be: it's just common knowledge, not a quantitative
assessment, and I needed a handy example.

> the attention of the folks who maintain the MTAs of the large email

We already have blacklists, which when appropriately used, do that
without the need for more elaborate mechanisms.  The trick is in the
word "appropriate", which has little to do with the criteria used for
listing and a lot to do with who uses them and how.

> dent in the practices of "large" email senders.

Epostage is dead-on-arrival for a number of reasons, including "a
hundred million zombies".  And any "reputation services", no matter how
elaborately constructed, will not make any difference unless they're used
"appropriately", in the same way that blacklists are/could be.

In other words: we do not need any new mechanisms.  We do not need
reputation services, or vouching services, or any of the other interesting
ideas that have been put forth.  We need to use the mechanisms we already
have, and have had for some time.  The days when we could expect network
and system administrators to care about the abuse emanating from their
operations because it was clearly their highest responsibility and ethical
obligation have been gone for a long time.  (Some still do, of course --
and good for them.)  The priority now is profit, profit, profit, and
thus it is necessary to speak to them in a language they understand.
(That is: we need to revoke some of their privileges and thus provide
them motivation to do what they're not doing.)  We've spent the last 15
years sidestepping that, and we're still doing so.

What it comes down to, no matter what the mechanism, is "are you willing
to refuse privileges to X even though there may be consequences from
your own user community?".  If "yes", and if there are a sufficient
number of others who feel the same, then it may be possible to affect
X's behavior.  If "no", then there's no reason for X to expend the
time and money required to address the issue.   And in the case of some
egregious spam sources (e.g. Hotmail), the answer given by many of us is
"no" because they're TBTB: the outcry from local users would be too great.

I'm certain Hotmail is well aware of this.  They know full well they're
spewing, and they know equally well that they can get away with it.
I'm equally certain they're not the only ones who've made this calculation.

Yes, every now and then there's a happy exception: the work that Carl
et.al. did at AOL comes to mind immediately.  But they *are* exceptions,
and they're nearly lost in the deluge.

---Rsk

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 09 Jul 2009 15:37:12 +0100

>> 1. Contact the owner of a compromised account, and advise them to take

Granted, all the following may be true, but we're still better off than the 
current situation where we have no clue who has sent most emails.

> the former owner to see those communications.

Well, that's a sure way of getting the attention of the account owner.

> account, and open a new one...which will shortly be compromised in

Well, if people don't value their accounts, that may be true. In that 
event, you have to do something else.

> The former owner will classify these reports as spam/phishes.

So, blacklist them, or contact their provider.

> it is a 100% pre-failed strategy.

Who said we're relying on that. If I'd given you a list of ONE item, then 
you could level that accusation.

> the next compromised account.  This is also a 100% pre-failed strategy.

No, it's not. It makes life harder for the spammer. With reputation 
services, you can limit the amount of inbound email from addresses that 
haven't yet acquired good reputation.

> blacklist mechanisms for doing that.)

No, we don't. Witness the fact that 90% of email is still spam.

> it's correctly delivered, it will do absolutely no good -- see above.

Bounces only cause backscatter when you can't rely on the sender address 
being accurate. When the address is accurate - a compromised account, for 
example, there are no good arguments left against it. In fact, it'll 
encourage security of the account.

---

From: John Leslie <[email-masked]>
Date: Thu, 9 Jul 2009 11:27:17 -0400

Rich Kulawiec <[email-masked]> wrote:
> We already have blacklists,

   Blacklists are, at most, one-bit reputiation services (which nobody
would pay "two-bits" for).

   When I say "reputation service," I mean something with customers
that pay for or otherwise subsidize the service.

> which when appropriately used, do that without the need for more
> elaborate mechanisms.

   Services naturally evolve, or to use your word, become more elaborate.

> The trick is in the word "appropriate", which has little to do with the
> criteria used for listing and a lot to do with who uses them and how.

   Which is why I ask for a "customer" relationship between service and
users.

>> Rich is correct that only "large" email receivers will be able to
>> make a dent in the practices of "large" email senders.
> 
> hundred million zombies".

   The reports of its death are highly exaggerated.

   A hundred million zombies aren't enough to guess strong password
encryption (least of all one-time-pad encryption). And the mere fact of
trying puts it into a different criminal classification than spamming.

   Presenting fraudulent ePostage tokens is, well, fraud. Blacklisting
an MTA (zombied or otherwise) "during the investigation of fraud" is
an unassailable practice. ("It's not _my_ fault that investigation is
taking six months!")

   Making ePostage work is clearly possible in an environment of short
token lifetime, encryption of paths it travels, and sufficient logging
of failure-to-redeem to support (automated) investigations of fraud.

> And any "reputation services", no matter how elaborately constructed,
> will not make any difference unless they're used "appropriately", in
> the same way that blacklists are/could be.

   "Appropriate" is in the eye of the beholder -- in this case the
persons running the service, who will have customer agreements to limit
"inappropriate" use.

> In other words: we do not need any new mechanisms.

   Maybe you don't, but many of us do.

> We do not need reputation services, or vouching services,

   Vouching services are needed to solve scaling problems. They also
provide a "reporting" mechanism that can work -- where recipients report
abuse to their reputation service, which accumulates enough to justify
restrictive actions, and offers to summarize abuse reports to vouching
services under contract terms.

> or any of the other interesting ideas that have been put forth. We
> need to use the mechanisms we already have, and have had for some time.

   We do use them (or at least the subset individual MTA operators trust,
which amounts to pretty much all of them being used for some traffic).

> The days when we could expect network and system administrators to
> care about the abuse emanating from their operations because it was
> clearly their highest responsibility and ethical obligation have been
> gone for a long time.

   Expecting large corporations to "care about" such things is irrational.

> (Some still do, of course -- and good for them.)

   _Many_ individuals running smaller ISPs do care!

> The priority now is profit, profit, profit, and thus it is necessary
> to speak to them in a language they understand.

   Aha! You do see the beauty of ePostage...

> them motivation to do what they're not doing.)

   This has been tried. The result nearly always is that they assign
"help-desk-personnel" to explain to their customers that the small ISP
is failing to follow the "clearly-explained procedures" laid out on
their web page; and that the problem needs to be solved by the small ISP.

   (Granted, they do "care" about the cost of those help-desk-personnal,
but that cost can be controlled by ensuring that customers _never_ get
anything more useful than that spiel and increasing the time-on-hold
to even get that.)

> We've spent the last 15 years sidestepping that, and we're still doing so.

   We've spent the last 15 years posturing why ePostage can't work and
why none of the reputation services are worth the money their customers
are (already) paying them.

> your own user community?".

   That's a balancing act. Small ISPs are willing do deal with "some"
amount of consequences.

> If "yes", and if there are a sufficient number of others who feel the
> same, then it may be possible to affect X's behavior.

   Unfortunately, in the US at least, it's nearly impossible to reach a
"sufficent" percentage without enlisting the cable/telco providers, all
of which suffer the "care-less" characteristics of corporations.

> If "no", then there's no reason for X to expend the time and money
> required to address the issue.

   Alas, there _is_ one reason -- we'll go out of business if we don't.

> And in the case of some egregious spam sources (e.g. Hotmail), the
> answer given by many of us is "no" because they're TBTB: the outcry
> from local users would be too great.

   Consider Hotmail: they have _many_ users who direct-marketers would
love to reach, and would be happy to pay some ePostage amount to reach --
perhaps as much as ten cents per missive.

   Now suppose there were a critical-mass of ePostage banks: would
Hotmail refuse to take the money?

   Now suppose that a few of us started asking Hotmail for one-cent
ePostage to accept their email during a heavy-Hotmail-spamming period:
is it worth it for them to refuse? (They're already running all the
software needed to do it; they already have the ePostage account set
up; the account is accumulating payments far greater that the "nuisance"
amount we're asking; and they have no help-desk-personnel trained to
explain why paying out 1% of the ePostage they receive would bankrupt
them.

> I'm equally certain they're not the only ones who've made this

   They're certainly not. Are we willing to consider how to tilt the
"almighty-dollar" balance to encourage a better behavior?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 09 Jul 2009 17:40:17 +0200

Rich Kulawiec wrote:
> have, and have had for some time.

I agree that mechanisms cannot do any good if they are not used. 
However, to forbid any new mechanism until existing ones won't have 
taken root may be exceedingly harsh.

>  The days when we could expect network

If we were able to highlight differences so as to improve competition, 
that would be understandable in those terms. But that requires a user 
base that is sensible to those arguments. IMHO, it is not much the gap 
between profit and ethics --different scale of planning horizon-- as 
the average user's ability to appreciate the quality of mail services, 
that has degraded them.

Perhaps, we should think of ways to make mechanisms visible to end users?

---

From: der Mouse <[email-masked]>
Date: Thu, 9 Jul 2009 11:45:06 -0400 (EDT)

>>> The introduction of reputation services [...]

At work (an ISP) we're paying substantially more than two bits for
access to a blacklist.  We find it worth it.

> encryption

The point is not the zombies attacking the crypto.  The point is
zombies (ab)using their machines' legitimate owners' epostage.

> Making ePostage work is clearly possible in an environment of [...]

Quite possibly.  Are such environments common enough to matter?

I don't think anyone's claiming epostage doesn't have even a niche
place.  But so far it doesn't seem to have more than that.  People keep
claiming it does, but the proof (ie, the example) is, so far, lacking.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: John Leslie <[email-masked]>
Date: Thu, 9 Jul 2009 13:36:28 -0400

> zombies (ab)using their machines' legitimate owners' epostage.

   This is a problem why?

> Quite possibly.  Are such environments common enough to matter?

   I can imagine them... Why couldn't they be common?

> claiming it does, but the proof (ie, the example) is, so far, lacking.

   Hmm... sounds like a good "research" project...

---

From: der Mouse <[email-masked]>
Date: Thu, 9 Jul 2009 13:59:30 -0400 (EDT)

>> zombies (ab)using their machines' legitimate owners' epostage.

Because it means epostage won't help: it'll just mean that abused
machines' owners pay in yet another way.  (If epostage is expensive
enough, it may help a little in that it may slightly reduce the
compromise rate, but I think more likely it will result in pressure
against epostage.)

> I can imagine them... Why couldn't they be common?

I don't know.  But deployed epostage seems to be remarkably rare, so
_something_ is preventing its uptake; either your idea of how common
such environments are is way high or there's something else preventing
deployment despite what appears to be an open-and-shut case in favour.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: John Leslie <[email-masked]>
Date: Thu, 9 Jul 2009 15:20:38 -0400

der Mouse <[email-masked]> wrote:
> machines' owners pay in yet another way.

   In the ePostage draft I'm looking for a round-tuit to update, tokens
are issued only to "bank" customers, and only on request. If some home
user actually sets up such an account, he shouldn't be surprised when
that account gets used. (If he chose to put it at risk for more than, say
$10, then the bank deserves any hassle they get for not explaining the
risk more thoroghly.)

   In practice, I expect home-user accounts to be rare, and most users
to send through an ISP or corporate MTA. Those folks won't be surprised
more than once!

> (If epostage is expensive enough, it may help a little in that it may
> slightly reduce the compromise rate,

   Although I don't expect that whole path to be much used, _any_ cash
penalty will tend to get someone's attention!

> but I think more likely it will result in pressure against epostage.)

   What means "pressure against ePostage"? If you mean simply refusing
to pay any under any circumstances, so what?

> _something_ is preventing its uptake;

   Uptake must _follow_ actual deployment. My belief is that every
deployment which could be classified as ePostage so far has been too
expensive, and has created some incentives which are plain _wrong_.

   (It would help _me_ if folks pointed out where draft-irtf-asrg-postage
creates "wrong" incentives.)

> either your idea of how common such environments are is way high or
> there's something else preventing deployment despite what appears to be
> an open-and-shut case in favour.

   I didn't claim "such environments" are common. Remember, I specified
- short token lifetime,
- encryption of paths it travels, and
- sufficient logging of failure-to-redeem to support (automated)
  investigations of fraud.

   Have I missed other ePostage proposals that included all of these?

---

From: John Levine <[email-masked]>
Date: 10 Jul 2009 00:44:23 -0000

Please remember the rule about labelling EPOSTAGE messages.

>> zombies (ab)using their machines' legitimate owners' epostage.

It destroys epostage's credibility to potential users.  Please see my
white paper.

>   I can imagine them... Why couldn't they be common?

Ahem.  I can imagine flying hippopotami, too.

>   Hmm... sounds like a good "research" project...

Right.  Have at it.

R's,
John

---

From: John Leslie <[email-masked]>
Date: Fri, 10 Jul 2009 13:26:49 -0400

John Levine <[email-masked]> wrote:
> It destroys epostage's credibility to potential users.

   Remember, the "users" are sending and receiving MTAs. I see little
benefit in defining a class of "potential users" that goes beyond the
class of current MTA operators.

   While I grant that FUD can always "destroy credibility", I don't see
it as hard to convince current MTA operators that if they give malware
access to a "bank" account they shouldn't be surprised when a particular
malware empties that account. "Credibility" of a cash-transfer system
running on compromised machines isn't a concept I wish to promote...

> Please see my white paper.

   Presumably John means

http://www.taugh.com/epostage.pdf

which makes a number of excellent points, most of which I quite agree
with. For example:
] 
] Since a sender can send the same valid stamp to many recipients, a
] recipient who gets a stamp from an unknown sender needs to check to
] see if it has already been used, by asking the issuing bank.
]...
] Most likely the majority of banks will be competently run, but some
] won't, deliberately or inadvertently issuing stamps that they can't
] later cash.
]...
] Usable international e-postage will need a system that lets recipients
] rapidly decide whether they're willing to accept stamps from unknown
] far-away banks.
]...
] If a stamp costs a penny... and 10% of the total stamps presented are
] real (the other 90% being spam), and that the bank's cut on each stamp
] is 10%, the bank has only 1/10 cent to spend to cancel each real stamp
] and 1/100 cent to reject a fake stamp.

   I believe draft-irtf-asrg-postage sets out to live within those
constraints.

   John continues and elaborates some threats
] 
] To send mail without paying postage, one might send spam with fake 
] stamps hoping recipients won't check them, send mail with forged
] return addresses that are on recipients' whitelists, send a little
] innocent mail to get recipients to whitelist them followed by a lot
] of spam, set up a fake bank that deliberately issues uncashable
] stamps, or trick a legitimate bank into issuing postage without
] paying for it.
] 
] To charge e-postage to third parties. one might sneak spam into other 
] people's mailing lists, or use a virus or Trojan horse software that 
] sends spam from the third party's computer.

   These are valid threats, but not in scope of draft-irtf-asrg-postage,
IMHO. They seem most appropriate for documents issued by "banks" to
their customers. I could go over any of them on request, but I see no
reason to try to address all of them in a single email.

   I expect to reissue draft-irtf-asrg-postage, and I am open to
suggestions for improvement, but issues such as those, IMHO, are better
treated in a draft on a possible implementaton of an ePostage bank (in
progress) or a draft on "best practices" for using an ePostage system
(which I'm willing to act as Editor for).

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 20 Jul 2009 18:30:25 +0200

Post cutover, the asrg archives seem to be inaccessible.

You requested:
http://www.ietf.org/mail-archive/working-groups/asrg/current/maillist.html
and did not find it.

Anyone know where they went?

Tom Petch

---

From: Bill Cole <[email-masked]>
Date: Mon, 20 Jul 2009 14:22:53 -0400

> http://www.ietf.org/mail-archive/working-groups/asrg/current/maillist.html

Every message to the list includes the answer in this header:

List-Archive: <http://www.irtf.org/mail-archive/web/asrg>

 > Anyone know where they went?

Every message also has that URL in its footer, from which the archives are 
just a link away.

---

From: Claudio Telmon <[email-masked]>
Date: Mon, 20 Jul 2009 20:26:00 +0200

> Anyone know where they went?

http://www.irtf.org/mail-archive/web/asrg/current/maillist.html

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 22 Jul 2009 18:29:45 +0200

Thanks Bill, Claudio, SM.

Yes, the archives are just where you say; I was accessing them from the asrg
charter page and failing.  I have flagged this to AMS.

Tom Petch

----- Original Message -----
From: "Bill Cole" <[email-masked]>
To: "Tom Petch" <[email-masked]>; "Anti-Spam Research Group - IRTF"
<[email-masked]>
Sent: Monday, July 20, 2009 8:22 PM
Subject: Re: [Asrg] archives