Subject: [Asrg] Sender pays vs Forgeries

From: Matt Sergeant <[email-masked]>
Date: Thu, 20 Mar 2003 17:11:00 +0000

I've not seen any of the "Sender pays" (camram, money or otherwise) or 
"Whitelist"  people address this issue...

Assumptions:

1. The vast majority of spam is sent with invalid return addresses (be 
they forged or since-closed freemail accounts).
2. A large proportion (approaching or in excess of 50%) of all email is 
spam.

Conclusions:

1. First time contact "bounces", whether to ask for payment, or to ask 
for a computation, or to ask for "proof of human", get sent to an 
invalid address.
2. Someone (most likely your ISP or email provider) has to deal with 
the resulting bounce from the receiving domain.
3. A sender pays system doubles the number of junk emails traveling 
through the internet.
4. This can only be solved by somehow solving the problem of falsified 
return addresses.
5. Solve (4) and you're half way there (perhaps all the way there?) to 
solving the spam problem, and you don't need sender pays.

Anyone in the sender pays camp want to address these points?

Matt.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Adam Back <[email-masked]>
Date: Thu, 20 Mar 2003 19:20:51 +0000

I think the primary cost is the recipients cost in classifying a
ddeleting mail, and ISPs costs in handling complaints.

Bandwidth is a smaller aspect of the problem, so I think that would be
a good tradeoff - bandwidth for less received spam.

The problems with sender pays are with deployment; could work well if
95% deployed but how to get there.

My favorite at this point is hashcash as a way to avoid false
positives, which gives incentives to users to use as it helps email
reliability short-term, rather than hindering reliability which most
other solutins impose, plus the status quo with filtering is already
leading to reliability problems.

Adam

---

From: Matt Sergeant <[email-masked]>
Date: Thu, 20 Mar 2003 19:49:40 +0000 (GMT)

> a good tradeoff - bandwidth for less received spam.

See my previous email on why bandwidth isn't the only issue in doubling 
the number of emails travelling around.

Matt.

---

From: Steve Schear <[email-masked]>
Date: Thu, 20 Mar 2003 11:46:32 -0800

At 05:11 PM 3/20/2003 +0000, Matt Sergeant wrote:
>2. A large proportion (approaching or in excess of 50%) of all email is spam.
>
>Conclusions:
>
>1. First time contact "bounces", whether to ask for payment, or to ask for 
>a computation, or to ask for "proof of human", get sent to an invalid address.
>2. Someone (most likely your ISP or email provider) has to deal with the 
>resulting bounce from the receiving domain.

I agree with 1 & 2.  3 is technically true but the data volume of the 
'challenges' will likely be significantly smaller than the spam.  (If white 
lists are combined with sender-pays and the white lists are implemented in 
the ISP then clients need not be exposed to the spam flood nor its 
bandwidth impact.)

If you can solve 4 without impacting anonymous emails I'd like to hear 
about it. I consider anonymous communication an extremely important social 
good (e.g., whistle blowers, etc.) that should not be harmed.

steve

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Mar 2003 20:02:12 +0000

>2. A large proportion (approaching or in excess of 50%) of all email is 

I expect to see a lot more junk email from <> and therefore a lot more
systems rejecting all bounces. I haven't seen much talk about maintaining
the reliablility of Internet email in the face of this kind of attack.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTH OR SOUTHEAST 5 OR 6, VEERING WEST 4
FOR A TIME IN WEST VIKING. OCCASIONAL RAIN. MODERATE.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Thu, 20 Mar 2003 15:16:31 -0500

> the reliablility of Internet email in the face of this kind of attack.

It's bad enough that www.rfc-ignorant.org keeps a list of DSN-borked sites.

For some odd reason, the majority of sites that I encounter that reject
mail from <> are spamhauses that don't want to deal with bounces. Fancy that. ;)

---

From: David Walker <[email-masked]>
Date: Thu, 20 Mar 2003 15:08:11 -0600

I don't understand why mail servers treat bounces as regular messages.
I believe that your mail server should encapsulate a bounce message in a 
generic "here is a mail error" report.

Certainly a spammer would be less enthusiastic if the end users were going to  
receive "here is a mail error: underage cheerleaders sell you cheap viagra"

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 20 Mar 2003 16:15:34 -0500

> generic "here is a mail error" report.

They do exactly that.  Problem being that the "generic here is a mail 
error" technique also happens to have a desirable feature for spammers - 
no bounce back, aka the <> envelope sender.

Bouncing email simply because it has an envelope sender of <> is truly a 
bad idea over and above the fact that the RFC states you shouldn't.  Eg: 
double bounces to postmaster.  Your users not seeing NDRs when they 
should.  Missing vacation messages etc.

However, you can finesse this somewhat.  We inline reject <> envelope 
from in the following two circumstances:

	1) The From: has no "@", or doesn't contain "mailer-daemon"
	   or "postmaster", or,
	2) There's multiple RCPT TOs (recipients).

No FPs ever on (1).  Only two FPs on (2) - broken mailing lists, which 
we assisted the listowner in fixing.  Quite happy with both rules.

---

From: [email-masked] (Claus Färber)
Date: 20 Mar 2003 00:00:00 +0000

> the reliablility of Internet email in the face of this kind of attack.

One could use special addresses as the envelope recipient which become
invalid after a month.
Mail to these addresses is only accepted if it has a return path of <>
and mail to other addresses only if it has a return path that is not <>.
The addresses would have to contain a timestamp and a digital signature,  
which is checked by the MTA that receives mail for the user who uses  
such a scheme.

Claus
-- 
http://www.faerber.muc.de/
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Mar 2003 01:37:41 +0000

> generic "here is a mail error" report.

It's for historical reasons, the main reason being that the protocols
assume that email failures are always complicated or unusual or at a
high enough layer that they warrant the attention of a human. There
is no accommodation in the standards for a denial-of-service attack on
this back-channel.

There *are* better bounce standards, but they are not widely-enough
implemented and still leave something to be desired. For example, RFC
3461 really MUST be implemented everywhere to maintain the viability
of bounces, but it does not allow you to sensibly verify a legitimate
bounce at SMTP time because the ENVID parameter is copied into the 2822
headers of the bounce and isn't exposed to the 2821 level -- you can't
reject a forged bounce until after CRLF.CRLF. It also only records the
original and final recipients of a message, not the intermediate aliases,
which reduces its effectiveness at improving email's debuggability.

Note that verifying legitimate bounces implies that the MXs for a
domain know the ENVID of all MAIL FROM that domain, which implies the
death of asymmetrical email routing (but I think we all agree that
that needs to die anyway).

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST SHANNON: SOUTHERLY 4 OR 5. FAIR. GOOD.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Mar 2003 04:15:40 +0000

>we assisted the listowner in fixing.  Quite happy with both rules.

(2) prevents you from having more than one manager for a list that
doesn't have automated bounce handling.

Neither of these checks prevents spammers.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LOUGH FOYLE TO CARLINGFORD LOUGH: SOUTH OR SOUTHEAST 3 OR 4. MOSTLY FAIR.
GOOD. SLIGHT.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Mar 2003 04:18:05 +0000

>which is checked by the MTA that receives mail for the user who uses  

There's already an equivalent solution in RFC 3461.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SELSEY BILL TO LYME REGIS: VARIABLE MAINLY NORTH OR NORTHEAST 3 OR 4, LOCALLY
2. MOST OF THE MIST THINNING. MODERATE OR POOR WITH FOG PATCHES BECOMING
MODERATE LOCALLY GOOD. SLIGHT.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked] (Claus Färber)
Date: 21 Mar 2003 00:00:00 +0000

> There's already an equivalent solution in RFC 3461.

Detecting bounces by looking for a RFC 3461 messages only works when all
sites implement it. And then you can still have your commercial message  
in the first part of a multipart/report structure (and fake bounce data  
in the following parts).

Special bounce addresses can be deployed on a per-domain (or per-
address) basis without support from hosts that send bounces (_and_ they
can detect forged bounces after MAIL FROM and RCPT TO, i.e. without
DATA).

Claus

---

From: David Walker <[email-masked]>
Date: Fri, 21 Mar 2003 11:36:25 -0600

My point is that if my mail server receives a message with a <> envelope 
sender it should not deliver the message intact to the user.  It should wrap 
that message to make it obvious that is an error report.  If it is a spam but 
is delivered looking like an error report it loses it's effectiveness as a 
spam.

---

From: [email-masked]
Date: Fri, 21 Mar 2003 12:41:00 -0500

> is delivered looking like an error report it loses it's effectiveness as a 

You *DID* know that there's some legitimate mail that isn't an error report
that goes with a MAIL FROM:<>, right?

In particular, LSoft's Listserv product sends the "confirmation cookie" messages
for opt-in lists with MAIL FROM:<> specifically *BECAUSE* if it's mailing to
[email-masked]' to confirm that it's a valid address and an intended request,
the bounce will be dropped on the floor if in fact it's a bogus address.

---

From: <[email-masked]>
Date: Fri, 21 Mar 2003 13:11:51 -0500

Such protection is the job of your mail program, not the mindless
transports. You can do instream processing at your end like popfile but
the mail server cannot and must not meddle.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Walker
Sent: Friday, March 21, 2003 12:36
To: Chris Lewis; [email-masked]
Subject: Re: Bounces, was Re: [Asrg] Sender pays vs Forgeries

sender it should not deliver the message intact to the user.  It should
wrap 
that message to make it obvious that is an error report.  If it is a
spam but 
is delivered looking like an error report it loses it's effectiveness as
a 
spam.

---

From: David Walker <[email-masked]>
Date: Fri, 21 Mar 2003 13:12:38 -0600

You may consider that a legitimate use.  I do not.
Everyone is so keen on not losing any existing functionality.  The existing 
functionality is what got us into this problem.

You would have to make a case that a Listserv requires that scheme to function 
properly.  There is no reason Listserv cannot give a MAIL FROM address and 
process or ignore the error message.  From all appearances it is just a cheap 
shortcut.

Can you point to something in the RFC that indicates there is a valid use for 
null senders other than bounce/error messages?

On Friday 21 March 2003 11:41 am, [email-masked] wrote:
> > wrap that message to make it obvious that is an error report.  If it is a
> > spam but
> >
> > a spam.
> In particular, LSoft's Listserv product sends the "confirmation cookie"
> messages for opt-in lists with MAIL FROM:<> specifically *BECAUSE* if it's
> mailing to [email-masked]' to confirm that it's a valid address and an
> intended request, the bounce will be dropped on the floor if in fact it's a
> bogus address.

---

From: [email-masked]
Date: Fri, 21 Mar 2003 14:36:02 -0500

> null senders other than bounce/error messages?

RFC2821, section 6.1 says:

   If there is a delivery failure after acceptance of a message, the
   receiver-SMTP MUST formulate and mail a notification message.  This
   notification MUST be sent using a null ("<>") reverse path in the
   envelope.  The recipient of this notification MUST be the address
   from the envelope return path (or the Return-Path: line).  However,
   if this address is null ("<>"), the receiver-SMTP MUST NOT send a
   notification.  Obviously, nothing in this section can or should
   prohibit local decisions (i.e., as part of the same system
   environment as the receiver-SMTP) to log or otherwise transmit
   information about null address events locally if that is desired.  If
   the address is an explicit source route, it MUST be stripped down to
   its final hop.

So it specifically codifies that <> is to be used if you don't want a
notification.

Nowhere does 2821 actually *RESERVE* <> for bounces.

RFC1891, section 10.4:

10.4 Relay to Bombs.AF.MIL

   The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which
   does not support the SMTP extension.  Because the sender specified
   NOTIFY=NEVER for recipient [email-masked], the SMTP at Pure-
   Heart.ORG chooses to send the message for that recipient in a
   separate transaction with a reverse-path of <>.

So here we have an example where <> is specifically used to get the
behavior of 1891 'notify=never' with a remote MTA that doesn't support it,
even when sending a non-bounce mail.

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 21 Mar 2003 15:45:25 -0500

>null senders other than bounce/error messages?

Null senders are to be used for delivery errors.  You are assuming 
that it is possible to encode all possible delivery problems in such 
a way that a spammer cannot put their own message in there.  I don't 
believe that's true.

However, it would certainly help if MUAs handled such messages 
specially.  My experience with the more clueless spectrum of 
end-users is that the current bounce system does not work.  They get 
mail from this scary address (mailer-daemon) and it contains a bunch 
of garbage they don't understand (if they open it).  In general they 
delete it without opening it (might be a virus).  They certainly 
don't use it to fix their address book.

And anything that makes it harder for spammers to get their message 
across is certainly going to help limit the class of people who use a 
spammer.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: David Walker <[email-masked]>
Date: Fri, 21 Mar 2003 14:57:42 -0600

I'm not actually assuming that we could prevent the spam from appearing.  My 
assumption is that a spam that is encapsulated in a system mail will lose its 
effectiveness.

On Friday 21 March 2003 02:45 pm, Kee Hinckley wrote:
> >Can you point to something in the RFC that indicates there is a valid use
> > for null senders other than bounce/error messages?
>

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 21 Mar 2003 16:23:18 -0500 (EST)

> process or ignore the error message.  From all appearances it is just a cheap 

You can prevent nearly all bounces by placing a "Precedence: Bulk" header
in the mail. This is NOT endorsed by and RFC, but it does work.

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 21 Mar 2003 22:38:07 -0700 (MST)

> From: Tony Finch <[email-masked]>

> ...

Why, other than the fact that the conclusion requires that assumption?

4 or 5 years ago, there was more spam from <> than there is now.
Any prediction of more spam from <> in the future needs to account
for the reduction since then.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Scott A Crosby <[email-masked]>
Date: 22 Mar 2003 18:57:25 -0600

> 2. A large proportion (approaching or in excess of 50%) of all email

3. Internet bandwidth is a valuable resource that needs to be conserved.

> 3. A sender pays system doubles the number of junk emails traveling

This would seem to be unimportant unless it uses assumptions A#3 above,
which could be argued to be not exactly accurate.

> 4. This can only be solved by somehow solving the problem of falsified

I do not see how this follows from C#3, even assuming A#3 above.

> Anyone in the sender pays camp want to address these points?

Scott

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 22 Mar 2003 20:32:57 -0500

> doesn't have automated bounce handling.

I think you mean more than one recipient for a list which has no bounce 
handling whatsoever.  We don't want those either.

> Neither of these checks prevents spammers.

No "check prevents spammers".

But they do block a heck of a lot of spam.

---

From: mathew <[email-masked]>
Date: Sun, 23 Mar 2003 09:19:46 -0500

The way to solve the bounce problem, pre-emptively if possible, is to 
standardize the format of bounce messages so that they can only contain 
an error code and the e-mail address of the bounce. They'd then be 
turned into a description by the client.

Frankly, that's how they should have worked originally, for 
internationalization reasons...

mathew

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 23 Mar 2003 13:09:41 -0500

At 9:19 AM -0500 3/23/03, mathew wrote:
>The way to solve the bounce problem, pre-emptively if possible, is 
>to standardize the format of bounce messages so that they can only 
>contain an error code and the e-mail address of the bounce. They'd 
>then be turned into a description by the client.

Unfortunately we seem to be making up new reasons for bounces on a daily basis.
- insufficient funds in stamp
- go to this url and prove you are human
- blocked by spam filter
...

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 23 Mar 2003 15:18:53 -0500

> - go to this url and prove you are human

We really don't need to get that complicated.  Just punt to a URL 
without trying to tell the client what it means.

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 23 Mar 2003 17:45:04 -0500

>without trying to tell the client what it means.

If that's a URL that goes to something readable by a machine--then 
perhaps.  Otherwise you've given spammers a wonderful tool for 
getting their message across. I think you'd be better off just 
limiting the size of a plain-text message.

I also think there are serious problems with systems that require 
that you be on the internet when you are reading your email.  And 
more-so with ones that require web access while you are reading your 
email.  People without always-on internet connections very frequently 
read mail off-line.  Ditto for anyone who reads mail on their laptop. 
Additionally, I have worked with very large companies who do not 
allow their users to have outside web access.

I just scanned RFC1894, and it seems to be fairly reasonable.  We 
could make recommendations on how a MUA should deal with such a 
message.  I know that some already do handle them specially.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society