Subject: [Asrg] RE: Asrg digest, Vol 1 #32 - 9 msgs

From: "Tom Thomson" <[email-masked]>
Date: Thu, 6 Mar 2003 15:04:13 -0000

> Date: Wed, 5 Mar 2003 11:24:06 -0500
> To: Hadmut Danisch <[email-masked]>
> From: Kee Hinckley <[email-masked]>
> Subject: Re: [Asrg] Deprecating plain POP accounts
> Cc: [email-masked]
>
> At 11:43 AM +0100 3/5/03, Hadmut Danisch wrote:
>>Surprise: That already exists. Many POP providers also offer the
>>service of delivering the mail. Authentication is possible through
>>either a so called "SMTP after POP" or a simple Password
>>authentication in the SMTP protocol, typically the same password as for
>>the POP account.
>
> If this were a solution, then ISP's wouldn't be blocking outbound
> SMTP connections.

Sure they would.  That would be an essential part of this solution - only
the ISP's own servers are allowed to make outgoing SMTP connections.

>
> Since there is no way to tell the difference between an outbound SMTP
> session from a client, and one from a server, your solution provides
> a mechanism for authorized delivery, but does not require it.
> Therefore the user sets up mail broadcaster at some safe location (or
> uses open relays) and sits happily at home using his ISP to send out
> email.  From the ISP's standpoint this looks just like legitimate
> use.  But he's spamming like crazy, and it's the ISP that gets the
> complaints.
> --
> Kee Hinckley
> http://www.puremessaging.com/        Junk-Free Email Filtering

No way to tell the difference?  As a general rule I can tell the difeence
between one of my servers and some client somewhere in my net - it's pretty
trivial.  Use the IP address for example (the server addresses are fixed;
the client addresses may be fixed or may come out of a pool - but they are
visibly different).

If the ISP's server keeps track of who sent what (no need for it to validate
the "From:" header or anything like that, so there's no difficulty in
sending using a source domain different from the domain I'm using right now)
for long enough to match up any spamming complaints to the originator, the
ISP can take action against the originator.  Or the ISP can be supoenad
("ripped" maybe in the UK? ) to provide the information for a prosecution if
the spam is illegal in his juridiction. Not a lot of data to keep (a msg id
and originator) and it doesn't need to be kept for very long (a couple of
days) - certainly it's data that is kept to maintain the ISP service by
assisting in enforcement of conditions of use, so even European privacy laws
(conforming to ECHR) won't be offended by retaining the data for long enough
to achieve that - and no data identifying the originator has been added to
the message by the ISP, so full sender anonymity can be preserved if
required in cases where the mail is not spam.

Doing that we can end up with a clear view of which ISPs will deal with spam
complaints effectively and which won't.  Probably the next stage is
blacklists - if an ISP is unwilling to deal with spam it's prohably because
he sees it as to his commercial advantage to allow it, and blacklisting will
make him useless to all his customers (whether spammers or not) so he'll
pretty quickly change his ways.

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

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 6 Mar 2003 11:04:00 -0500

>pretty quickly change his ways.

What you are describing is exactly the situation now.  The message 
headers indicate the originator of the email by IP address.  When you 
report the email, the ISP terminates the account if they are 
responsible and doesn't if they are not.  The ISP doesn't need to log 
message-ids, the received headers contain all the necessary 
information for them to map back to the sender.

At one point WorldCom reportedly had over 100 people doing nothing 
but dealing with spam complaints.  And on the other side of the 
fence, I haven't noticed the ISP 163.net in China going out of 
business just because they are a major source of spam.

PS. Could someone tell me why there are these Chinese ISPs that use 
numbers like 163 an 263 as their names?  Is there some significance 
to the numbers?
-- 
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: "Tom Thomson" <[email-masked]>
Date: Thu, 6 Mar 2003 18:00:04 -0000

>
 > From: Kee Hinckley [mailto:[email-masked]]
 > Sent: 06 March 2003 16:04
 > To: Tom Thomson
 > Cc: [email-masked]
 > Subject: [Asrg] RE: Asrg digest, Vol 1 #32 - 9 msgs
 >

No, it isn't the situation we have now.  It's closer to the situation we had
a while back, but the spammers have got a lot cleverer since.  Injecting a
few "Received-From:" headers at source, complete with IP addresses and
domain name that corresponded to that IP at the time the message was
delivered to that MTA, means that when the message is delivered there is no
authenticated point of origin.  Having MTA's sign the "Received-From:" lines
they insert would distinguish the fake ones from the real ones, and give us
a real point of origin - then we could complain to the right place (allowing
for the possibility that the point of origin signs a Received-From: header
properly, so the point of origin may be either the last signer or the
machine pointed at by the last signer). Similarly a signed "From:" header
would work, but of course we can't expect the spammer's MUA to provide that
for us and it takes longer to get MUSa updated than MTAs.
Now the anti-spammers have moved on too, and we have some MTAs which will
add a "probably forged" comment into the string of "Received-From" lines,
which is an improvement, but that unfortunately isn't bullet-proof and we
can expect the spammers to get ahead of that one next (why shouldn't the
point of origin inject such a comment some way down the chain to point a
misleading finger, and avoid using talking to MTAs known to provide this
comment when appropriate?).

I agree that some ISPs are going out of business depite appearing to be
major spam sources; but do we know they actually are major spam sources
though, without any authentication of the point of origin or of the
Received-From trail? That's what makes me favour blacklists once we have
reliable authentication of point of origin, but only when we have that
reliable authentication (and have a pile of complaints not dealt with).

And I haven't a clue why Chinese ISPs use these numeric names.

Tom Thomson

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 6 Mar 2003 15:30:51 -0500

>delivered to that MTA, means that when the message is delivered there is no

I agree that signed Received headers would make life easier, but I 
think there are other signed things we could better focus on. 
However I have yet to see a set of injected Received: headers that 
could not be programmatically determined to be fake.  If you have any 
such messages (seriously), I'd like to see them.

>reliable authentication (and have a pile of complaints not dealt with).

As I think has been said on this list, and certainly elsewhere. 
Blacklists are worth what you pay for them.  And those that charge, 
get sued.

I also seriously worry about what would happen if some country 
decides not to uphold the standards we are proposing and gets 
blacklisted.  Does it become a diplomatic affair?
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society