Subject: [Asrg] Remote mailing

From: [email-masked]
Date: Wed, 02 Jul 2003 09:58:47 -0500

>> That's interesting when you think about it.  Please offer some evidence
>other than your personal assurances that Cisco would restrict employees
>from sending mail with cisco.com sender addresses from random locations
>including their homes, customer sites, hotels, and even airplanes in
>order to stop that abuse of their trademark.

> Chill.  Any Cisco employee who is going to be connecting to the 'net for 
work will connect to cisco over a VPN from said random locations and 
would have full access to cisco SMTP servers.  Ok, so it's unlikely, but 
perhaps they can't send from cisco.com from their cellphones without 
some work (some cellphones support SMTP already, and probably some 
support smtp-auth as well).  It's unlikely, but perhaps a VPN or 
smtp-auth connection won't be practical from 30,000 feet.  If so, so 
their mail in these very rare cases comes from airline.dom or 
cellphonecompany.dom.  Big deal?

Good examples of places where you just don't have much choice is when you're in 
a sidewalk Internet cafe, or a public library, an airport waiting lounge kiosk, 
or a cruise ship Internet cafe.  Or you could be at a customer site and need to 
mail, but need to do it (frequently the case) through one of their systems.

Big deal?  Well, it IS a "big deal" if those mails simply can't be sent, or get 
trashed and are never delivered.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

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

---

From: Richard Rognlie <[email-masked]>
Date: Wed, 2 Jul 2003 11:17:02 -0400

I am recovering from recently spending the last ~4 years on the road 
as a Sendmail, Inc. consultant.

One of the ongoing issues was "how do I send mail as [email-masked]
from XXXX"?

One way I worked around it was to setup SMTP AUTH on my home email server.
so... as long as I could get to port 587 on that box (or port 25, but
I *forced* AUTH on port 587) I could send mail.

This worked most of the time.  Even when earthlink (and then others) started
restricting outbound port 25.  They'd often keep 587 open (thankfully).

The times it didn't work were when I was on a client site and they were 
blocking outbound 25/587 (if not from their MTAs).

In these cases, I'd fall back to an ssh-tunnel.  And if the client blocked
outbound 22... well... I was on my own for a bit.

This was "good enough".  And reasonably secure (SMTP AUTH + STARTTLS +/- SSH).

-- 
 /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/    <[email-masked]>
 /  \__/ | The past is the future
 \__/    |                  Nobody expects the spammish inquisition

---

From: "David Koblas" <[email-masked]>
Date: Wed, 2 Jul 2003 09:25:57 -0700

Spam at one level is a security problem, it's the allowance of non-validated
sender to send messages impersonating other users.

Your example is "should a Cisco employee be allow to send a message from
anywhere without authenticating against Cisco" implies that Cisco doesn't
care who sends messages claiming to be from a Cisco.  Easy example, is today
sitting at my desk I can originate a message from "John Chambers" letting
you know the quarterly earning are great!  That's a security problem, the
message didn't originate from Cisco nor is this user authenticated...

If you're sitting on an airplane, customer site, etc., you should
authenticate in to your corporate network or send email via another channel.
Hotmail, Yahoo, AOL, etc. all have authentication before you can send email,
they can easily stamp, sign or otherwise endorse the message before it's
delivered on the network.

There is no reason that a MTA or MUA should in the long term allow
non-verifiable messages to arrive.  It's the responsibly of the sending MTA
to stamp/sign a message on outgoing delivery.  It's impossible to belive
that we can remove spam from the network, but what I want to see is good
senders not having to worry about their ability to send email and have it be
received (see recent FTC problems).

--koblas

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 02 Jul 2003 12:33:04 -0400

At 09:25 AM 7/2/2003 -0700, David Koblas wrote:

>[..]

Which arises from the design of SMTP and the general openness of the 
Internet as it was developed originally.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 02 Jul 2003 12:36:38 -0400

... That's a security problem ...

Milage varies, for two of the four words in the phrase above. 

Some enet nic vendors allow the mac address to be user defined.
Most inet i/f vendors allow the ipv{4|6} address to be user defined.
...

The user defined character of these properties of network attachments
do not carry with them sensible guarantees about the uniquenss of the
user-defined MAC, anywhere, or the routability of the ip{4|6} address,
or ...

---

From: [email-masked]
Date: Wed, 02 Jul 2003 12:42:24 -0500

>Internet as it was developed originally. 

Guys, we're losing sight of the problem here.  While preventing counterfeit 
headers is nice, it's entirely possible for the customers of ANY single 
spammer-friendly ISP literally *anywhere* in the world to flood the Net with 
spam.  

And spam doesn't HAVE to come from a non-validated sender.  Spam is spam even if 
Microsoft or Dell or HP or General Motors decides to send it.  Nothing says it 
can't be a "validated" sender doing it.

---

From: [email-masked]
Date: Wed, 02 Jul 2003 13:43:48 -0500

>sender to send messages impersonating other users.

Eliminating that (even if we could) still doesn't solve the spam problem.

A person can sent a Hotmail message saying IN THE BODY that they're so-and-so... 
how are you going to prevent false statements being made in ANY E-mail?  I don't 
think you can.

>care who sends messages claiming to be from a Cisco.  

So someone sends a message saying (in the body!) that they're from Cisco.  
Caveat lector!  Cisco CANNOT prevent that.

>Easy example, is today

>authenticate in to your corporate network or send email via another channel.

Easier said than done.  You may simply NOT HAVE CONTROL over how the E-mail is 
being sent, ONLY able to enter your return address.

>delivered on the network.

You're presuming that you're necessarily using Web-based E-mail, which is NOT 
always the case.  (E.g. Internet cafes on cruise ships, where you're 'favored' 
to send the mail using their native mail system rather than using the Web 
browser... due to the satellite connection at $7+/minute!)

>non-verifiable messages to arrive.  

That depends ENTIRELY on the situation.  It's dangerous to make categoric 
statements like that.

>It's the responsibly of the sending MTA

"Good senders" could STILL decide to send spam.  The recipient STILL needs the 
right to block stuff (even from people that they know and trust) that's outside 
the boundaries of what they're used to accepting (and willing to accept) from 
individual senders.  And there PROBABLY needs to be a mechanism for them to AT 
LEAST BE AWARE that they've received something from someone "new", and to decide 
if they want to take it or not.

This is NOT a lot different than long-established policy of when you call the 
President of XYZ Corporation, and the secretary takes the call and finds out:

  1)  who you are
  2)  what company you're with
  3)  what the call is regarding

And then, based on that (and their knowing the Boss) they'll either deflect your 
call to another department, or present the Boss with the information to see if 
he wants to take the call.  And like in my proposal, he'll clarify his policy:

  1)  no, I'm not interested in calls like these; send 'em to Customer Service
  2)  Yes, put him through right away
  3)  I'll take it this time, but not if he calls back
  4)  tell him to get lost
or whatever.

Screening your calls with an answering machine is much the same... you'll let 
the answering machine take it, and listen while the caller (rapidly) makes their 
case for calling them back.  If you want, you can pick up the phone and take the 
call;  or you can maybe call them back at your leisure.

---

From: Barry Shein <[email-masked]>
Date: Wed, 2 Jul 2003 16:35:22 -0400

From: "David Koblas" <[email-masked]>
>sender to send messages impersonating other users.

Certainly a lot of spam does this, but it's not clear this is critical
to spam.

A fair number of spammers send from domains they probably own,
cheapmortgages.com and that kind of thing, so who's to say that's an
impersonation of any sort?

Others send from domains with fraudulent intent, but which likely
would slip by most proposed systems, such as [email-masked] (those are
two zeros) or [email-masked] (not real examples but similar to
real examples, a common real example I see is [email-masked]).

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: "David Koblas" <[email-masked]>
Date: Wed, 2 Jul 2003 16:49:27 -0700

> how are you going to prevent false statements being made in ANY E-mail?  I
don't

That's part of the basis of putting verifiable information in a message, as
long as people are allowed to spoof any identity in any system you cannot
every solve this problem.  You need to migrate to a system in which basic
identity is verifiable.  I don't care if you say your [email-masked] and
you're reply-to address is [email-masked] , that's fine... You no longer
are forging your sending identity.

> Caveat lector!  Cisco CANNOT prevent that.

I don't think any system can prevent false statements (even newspapers make
them), what would be nice to see is a system which prevents false
identities.

> being sent, ONLY able to enter your return address.

Very true, but as a "normal" user all I care about is that the message that
I send is delivered and that the person/machine that I sent it to can reply.
There are tricks for mailinglist and other machine based system to better
handle auto-responses, but they should be secondary to human communications.

> browser... due to the satellite connection at $7+/minute!)

No I'm presuming that there is some level of authentication between me and
my email sending point.  I should have no expectation that on a cuise ship
that I can send mail from a MTA located in the boiler room and retain my
work identity.  After all it's a boiler room sending the message...

> That depends ENTIRELY on the situation.  It's dangerous to make categoric

Start with a bold point and find a strong compromise, start with a weak
point and have a weaker compromise.

> call;  or you can maybe call them back at your leisure.

I fully agree with the above...  The unfortunate truth is that spam is
partly in the eye of the reader, there are messages I get on a daily basis
that other people might view a spam.  One of the difficulties in content
filtering games is that it's hard to know what's good if all you can work on
is the content.

Systems which provide identity verification provide addtional information by
which decissions can be made.

--koblas

---

From: "David Koblas" <[email-masked]>
Date: Wed, 2 Jul 2003 16:52:27 -0700

I fully agree that you cannot stop people from using disposable domains or
email addresses.  But, if you can provide a migration path from an untrusted
network to a trusted network you can segregate the messages.

You can easily build system which leverage history on senders (and their
domains) to start making better decisions, but most systems are force into
the weak world of content analysis to make their decissions.  In addtion you
can thwart many problems with web-proxy, sock-proxy style spam attacks
because they cannot generate validation information that matches the
transaction.

--koblas