Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP

From: [email-masked]
Date: Fri, 17 Jun 2005 02:50:49 +0000

I'm sure many will think this a stupid comment, but in the hopes that some don't I'll point out that the largest and arguably most efficient messaging system in the world is built upon open relay.  Anyone can anonymously drop a letter in any mailbox in the US and while there's junk mail it's proportions are certainly nothing like spam.  Why the difference?  Well first I split spam into 2 categories:
1.  legitimate advertisements for legitimate products (whether solicited or unsolicited).
2.  Fraudulent mail, scams, cons, etc.
I think the email abusers almost entirely fall into the second category and that nobody would be complaining if spam primarily consisted of Bloomingdale's catalogues and coupon val-paks.
So I think we are attacking things the wrong way.  The methods we are using - whether blacklists or 'authorized email' is going to either prove fruitless or end up ruining the big picture, which for me is electronic communication for everyone, to everyone.  Using electronic means, I don't see how we can ever prevent spam and still have open global communication among disparate systems.  It would be a different story if one organization ran all email servers worldwide but that horrible thought aside there will always be holes and breaks in an authentication/authorization scheme unless people limit who they can communicate with, and even then there will be spam.
There's also the returns we see on our efforts to consider.  Think of the millions of man/woman hours spent trying to stop spam - so many hours it probably would have taken less to inspect every email by hand.  And then when you think (if you believe as I do) that everything can be gotten around and that security holes are as infinite as the imagination, well then you know there will always be some kid with a script (which also includes any real spammer) who will be able to get around your defenses within a week of them being implemented.
My last unconstructive comment is that simple systems scale lossless and complex systems grow in a complexity proportionate to their size.
Funny enough, I think the postal inspector's department came about because of the amount of scams being sent via mail shortly after the civil war (such a glut that it was bringing the postal service to their knees).  Yet the postal service remained open-relay - why?  Maybe because they realized that they didn't need to 'trace' scam-mail because scams are trace-inclusive as the scammer must include a point of contact.  Sure there's the occasional anonymous letter bomb but since their resources aren't spent blocking coupon mailers they are much more likely to catch the big stuff.
I know there are 8 trillion problems with this idea but I think in general, email fraud needs to become like mail fraud and there needs to be a team of inspectors who follow up on such reports and arrest violators (I know the Internet is bigger than the US, so of course it's up to each country how to handle it).  I'm sorry for the non-technical post but I think blacklists are disgusting (I don't care if they help or not) and I just think so much brilliance could be directed elsewhere.
Thanks and best regards,
Nick Staff
[email-masked]
-------------- Original message -------------- 
> >  it's possible to have open relays that don't contribute to spam.  but
> >  those relays need to employ some other means, e.g. rate limiting, to
> 
> Rate limiting is a relatively recent technique.  Though very useful it has... 
> ummm, limited applicability.  

mostly because of blacklists.  it was working fine for its intended purpose.

> One needs to be careful not to dismiss established techniques in favor of the 
> latest fashionable one that is not as well fully understood.

I don't know what you mean by "relatively recent", but I was doing it at least
as early as April 1999 - that's the last mod date on my source files.  RFC 2554
only dates from March 1999.

> For example, rate limiting is used to control a single source. It's quite 
useful 
> when used at the destination. At a sufficiently well-run source network, it 
also 
> can be pretty useful.

It's also pretty useful for preventing a relay from being exploited by spammers.
 
> The problem is with zombies.  They make mush of old-time models of spam, since 
> they demonstrate that a very small data stream from a single source can be 
> leveraged into a very, very large data stream, given enough sources. 

Rate limiting of this type (based on source IP address), if done properly, 
doesn't 
help or hurt zombies.  The rates need to be set such that zombies can send 
directly
to the recipients' MXes as easily, and more reliably, as they can send the same 
mail via the rate limiting SMTP servers.

> One can start imagining more complex rate-limiting models, but then we would 
be 
> talking about research efforts.  A BCP is not supposed to rely on research, 
> especially when it hasn't been done.  

Maybe you should stick to talking about things that you know something about.

> >  block spam.  the goal of such relays is to make it at least as easy for
> >  the spammer to simply contact the appropriate MXes for the destination
> >  addresses as to use the relays.  of course it is necessary for such
> >  relays to record source IP addresses, etc., so that they are as
> >  traceable to their origin as messages sent directly to MXes.
> 
> I don't know how much experience you have trying to do such tracing, but the 
> spamops folks have made quite clear that it is both vastly more effort and 
> considerably less productive, than one might expect. 

That's a problem with mail relaying in general, not just with open relays.
Now if you want to discourage multi-hop mail relaying, that might actually be
useful for lots of reasons besides just traceability.

> >  unfortunately, the vigilante character of various open-relay blacklists
> 
> blacklists are not the subject of this BCP.

This thread has pretty much diverged from the subject of your draft
document anyway.

> >  killed any attempt at this kind of innovation.  just as we're now in
> >  danger of various kinds of brain-dead "authentication" methods and
> >  meaningless requirements killing useful email functionality.
> 
> new authentication methods are not the subject of this BCP.

You mean "your draft document".  It's certainly not a BCP as it's 
currently written.

Keith

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

--
Best regards, 

Nick Staff

-------------- Original message -------------- 

> > > it's possible to have open relays that don't contribute to spam. but 
> > > those relays need to employ some other means, e.g. rate limiting, to 
> > 
> > Rate limiting is a relatively recent technique. Though very useful it has... 
> > ummm, limited applicability. 
> 
> mostly because of blacklists. it was working fine for its intended purpose. 
> 
> > One needs to be careful not to dismiss established techniques in favor of the 
> > latest fashionable one that is not as well fully understood. 
> 
> I don't know what you mean by "relatively recent", but I was doing it at least 
> as early as April 1999 - that's the last mod date on my source files. RFC 2554 
> only dates from March 1999. 
> 
> > For example, rate limiting is used to control a single source. It's quite 
> useful 
> > when used at the destination. At a sufficiently well-run source network, it 
> also 
> > can be pretty useful. 
> 
> It's also pretty useful for preventing a relay from being exploited by spammers. 
> 
> > The problem is with zombies. They make mush of old-time models of spam, since 
> > they demonstrate that a very small data stream from a single source can be 
> > leveraged into a very, very large data stream, given enough sources. 
> 
> Rate limiting of this type (based on source IP address), if done properly, 
> doesn't 
> help or hurt zombies. The rates need to be set such that zombies can send 
> directly 
> to the recipients' MXes as easily, and more reliably, as they can send the same 
> mail via the rate limiting SMTP servers. 
> 
> > One can start imagining more complex rate-limiting models, but then we would 
> be 
> > talking about research efforts. A BCP is not supposed to rely on research, 
> > especially when it hasn't been done. 
> 
> Maybe you should stick to talking about things that you know something about. 
> 
> > > block spam. the goal of such relays is to make it at least as easy for 
> > > the spammer to simply contact the appropriate MXes for the destination 
> > > addresses as to use the relays. of course it is necessary for such 
> > > relays to record source IP addresses, etc., so that they are as 
> > > traceable to their origin as messages sent directly to MXes. 
> > 
> > I don't know how much experience you have trying to do such tracing, but the 
> > spamops folks have made quite clear that it is both vastly more effort and 
> > considerably less productive, than one might expect. 
> 
> That's a problem with mail relaying in general, not just with open relays. 
> Now if you want to discourage multi-hop mail relaying, that might actually be 
> useful for lots of reasons besides just traceability. 
> 
> > > unfortunately, the vigilante character of various open-relay blacklists 
> > 
> > blacklists are not the subject of this BCP. 
> 
> This thread has pretty much diverged from the subject of your draft 
> document anyway. 
> 
> > > killed any attempt at this kind of innovation. just as we're now in 
> > > danger of various kinds of brain-dead "authentication" methods and 
> > > meaningless requirements killing useful email functionality. 
> > 
> > new authentication methods are not the subject of this BCP. 
> 
> You mean "your draft document". It's certainly not a BCP as it's 
> currently written. 
> 
> Keith 
> 
> _______________________________________________ 
> Ietf mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/ietf 

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

---

From: Larry Smith <[email-masked]>
Date: Thu, 16 Jun 2005 22:14:45 -0500

Since you top posted, I will, against nature, respond in kind.

The one "item" you missed from your analogy is that postal mail is "paid" for 
up front, by the person "posting" (anon or not) - eg the post-office gets 
paid _before_ your letter gets delivered.  The problem with spam is that the 
receipient is "paying" the cost (cod with no chance to refuse delivery)...

-- 
Larry Smith
SysAd ECSIS.NET
[email-masked]

On Thursday 16 June 2005 21:50, [email-masked] wrote:
> I'm sure many will think this a stupid comment, but in the hopes that some
> don't I'll point out that the largest and arguably most efficient messaging
> system in the world is built upon open relay.  Anyone can anonymously drop
> a letter in any mailbox in the US and while there's junk mail it's
> proportions are certainly nothing like spam.  Why the difference?  Well
> first I split spam into 2 categories: 1.  legitimate advertisements for
> legitimate products (whether solicited or unsolicited). 2.  Fraudulent
> mail, scams, cons, etc.
> I think the email abusers almost entirely fall into the second category and
> that nobody would be complaining if spam primarily consisted of
> Bloomingdale's catalogues and coupon val-paks. So I think we are attacking
> things the wrong way.  The methods we are using - whether blacklists or
> 'authorized email' is going to either prove fruitless or end up ruining the
> big picture, which for me is electronic communication for everyone, to
> everyone.  Using electronic means, I don't see how we can ever prevent spam
> and still have open global communication among disparate systems.  It would
> be a different story if one organization ran all email servers worldwide
> but that horrible thought aside there will always be holes and breaks in an
> authentication/authorization scheme unless people limit who they can
> communicate with, and even then there will be spam. There's also the
> returns we see on our efforts to consider.  Think of the millions of
> man/woman hours spent trying to stop spam - so many hours it probably would
> have taken less to inspect every email by hand.  And then when you think
> (if you believe as I do) that everything can be gotten around and that
> security holes are as infinite as the imagination, well then you know there
> will always be some kid with a script (which also includes any real
> spammer) who will be able to get around your defenses within a week of them
> being implemented. My last unconstructive comment is that simple systems
> scale lossless and complex systems grow in a complexity proportionate to
> their size. Funny enough, I think the postal inspector's department came
> about because of the amount of scams being sent via mail shortly after the
> civil war (such a glut that it was bringing the postal service to their
> knees).  Yet the postal service remained open-relay - why?  Maybe because
> they realized that they didn't need to 'trace' scam-mail because scams are
> trace-inclusive as the scammer must include a point of contact.  Sure
> there's the occasional anonymous letter bomb but since their resources
> aren't spent blocking coupon mailers they are much more likely to catch the
> big stuff. I know there are 8 trillion problems with this idea but I think
> in general, email fraud needs to become like mail fraud and there needs to
> be a team of inspectors who follow up on such reports and arrest violators
> (I know the Internet is bigger than the US, so of course it's up to each
> country how to handle it).  I'm sorry for the non-technical post but I
> think blacklists are disgusting (I don't care if they help or not) and I
> just think so much brilliance could be directed elsewhere. Thanks and best
> regards,
> Nick Staff
> [email-masked]
> > Rate limiting is a relatively recent technique.  Though very useful it
> > has... ummm, limited applicability.
>
> > One needs to be careful not to dismiss established techniques in favor of
> > the latest fashionable one that is not as well fully understood.
>
> I don't know what you mean by "relatively recent", but I was doing it at
> least as early as April 1999 - that's the last mod date on my source files.
>  RFC 2554 only dates from March 1999.
>
> > The problem is with zombies.  They make mush of old-time models of spam,
> > since they demonstrate that a very small data stream from a single source
> > can be leveraged into a very, very large data stream, given enough
> > sources.
>
> to the recipients' MXes as easily, and more reliably, as they can send the
> same mail via the rate limiting SMTP servers.
>
> > talking about research efforts.  A BCP is not supposed to rely on
> > research, especially when it hasn't been done.
>
> > >  block spam.  the goal of such relays is to make it at least as easy
> > > for the spammer to simply contact the appropriate MXes for the
> > > destination addresses as to use the relays.  of course it is necessary
> > > for such relays to record source IP addresses, etc., so that they are
> > > as traceable to their origin as messages sent directly to MXes.
> >
> > I don't know how much experience you have trying to do such tracing, but
> > the spamops folks have made quite clear that it is both vastly more
> > effort and considerably less productive, than one might expect.
>
> Now if you want to discourage multi-hop mail relaying, that might actually
> be useful for lots of reasons besides just traceability.
>
> > > Rate limiting is a relatively recent technique. Though very useful it
> > > has... ummm, limited applicability.
> >
> > > One needs to be careful not to dismiss established techniques in favor
> > > of the latest fashionable one that is not as well fully understood.
> >
> > I don't know what you mean by "relatively recent", but I was doing it at
> > least as early as April 1999 - that's the last mod date on my source
> > files. RFC 2554 only dates from March 1999.
> >
> > > The problem is with zombies. They make mush of old-time models of spam,
> > > since they demonstrate that a very small data stream from a single
> > > source can be leveraged into a very, very large data stream, given
> > > enough sources.
> >
> > Rate limiting of this type (based on source IP address), if done
> > properly, doesn't
> > to the recipients' MXes as easily, and more reliably, as they can send
> > the same mail via the rate limiting SMTP servers.
> >
> > > talking about research efforts. A BCP is not supposed to rely on
> > > research, especially when it hasn't been done.
> >
> > > > block spam. the goal of such relays is to make it at least as easy
> > > > for the spammer to simply contact the appropriate MXes for the
> > > > destination addresses as to use the relays. of course it is necessary
> > > > for such relays to record source IP addresses, etc., so that they are
> > > > as traceable to their origin as messages sent directly to MXes.
> > >
> > > I don't know how much experience you have trying to do such tracing,
> > > but the spamops folks have made quite clear that it is both vastly more
> > > effort and considerably less productive, than one might expect.
> >
> > That's a problem with mail relaying in general, not just with open
> > relays. Now if you want to discourage multi-hop mail relaying, that might
> > actually be useful for lots of reasons besides just traceability.
> >

---

From: Dean Anderson <[email-masked]>
Date: Fri, 17 Jun 2005 16:01:10 -0400 (EDT)

I have no religion about top or bottom posting. Bottom posting is a
variation of posting inline.

> receipient is "paying" the cost (cod with no chance to refuse delivery)...

This "spammers don't pay" claim isn't true, except for viruses.  This myth
was first leveled against Cyberpromo and others in the 1990s. But
Cyberpromo (and the others)  frequently had T1 connections that they paid
for.  We occasionally hear of "pink contracts" that spammers presumably
pay more for.  Commercial bulk emailers have always paid at least as much
as everyone else. Sometimes more.

Second, junk postal mail costs the recipient much, much more in time and
trash handling, landfills, and garbage pickup than spam does.  Both sender
and receiver incur expenses with postal junk mail. An the case of postal
mail, bulk mailers pay substantially _less_ than everyone else. Regular
people pay 37 cents. I think bulk mail is still at 15 cents (it could be
higher now).  But even if the bulk mail rates are higher now, they are
less than 37 cents.  Imagine if we were to charge commercial bulk emailers
less for their internet service.

Third, for the case where viruses are used, the spam problem exists but
pales in comparison to the problems of distributed DOS attacks, extortion
of various sorts, and other criminal activity and mischief available to
the virus operator.  That they are "spamming on someone else's dime" is
the least of the worries with a virus/botnet.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000