ietf-asrg
[Top] [All Lists]

Re: [Asrg] SMTP AUTH

2004-12-08 16:07:56
Yes, although at least when we're dealing with (let's agree that we're
talking
mostly about POP3 here) E-mail, we can easily enough filter the message
before
the MUA gets it to block certain forms of potentially malicious (or at
least
"very dubious") HTML content, and we can do that with the knowledge of who
(at
least we believe that) the E-mail in question is coming from.  That makes
the
problem easier than handling the same things when they are coming into a
Web
browser, which probably doesn't give us a good intercept point and in any
case
doesn't provide any standardized way for us to determine who sent the
E-mail (or
whatever) that's on the Web page being viewed.

As I've said, Web-based stuff is a different (and harder) problem that
we'll
have to deal with eventually, but at the moment that's mostly just a
diversion
and distraction from what we need to deal with HERE.

Filters can also be used prior to sending mail to web user.

Sure, they could, but then they must (presumably) be deployed at some other 
point than at the recipient end, perhaps at the Web server end, where it's far 
more difficult to adapt their rules to the choices of the recipient.  It also 
is 
harder as a rule to get ISP concurrence to install stuff like this, as opposed 
to something that the end user/recipient can install by themself and without 
getting hassled for it.

The idea is to send mail with
authentication and if a secured webmail does that one should prefer that
rather than banging their head against the wall just because we need
SMTP/POP to do the job which is done better by some other thing.

Authentication proves NOTHING regarding legitimacy because a zombie
spambot can
trivially send what it sends using the authentication belonging to the
hijacked
system.

A zombie can send mail through SMTP not through HTTPS as of now

  1)  Web protection is a separate issue.  Let's address that issue later.

  2)  How long do you think it would take a capable hacker to create a worm 
that 
sent mail using HTTPS?  Two weeks?  A month?  Anyhow, it's likely to be a lot 
less time than it takes us to convert the world to "authenticated" mail.

I'm talking about sending mail through secured webaccess after authentication

And I presume that means that you're simply going to tell everyone using (and 
preferring) SMTP-based E-mail that they can't use it anymore?

And what about SMTP mail senders that are built into backend applications 
worldwide?  You're just going to wave some kind of magic wand and make all that 
stuff disappear, too?

Authentication is also at least VERY problematical in cases like airport
or
cruise ship Internet access terminals/kiosks, where people need to use
their OWN
E-mail addresses but have absolutely **NO** control over which SMTP E-mail
server will be used by the kiosk software.

What is the %age of ppl using internet on cruise as compared to ppl using
internet on land at the same time. I dont know why you keep pushing the
idea of ppl on cruises.

Because it's a good example of the type of LEGIMATE, IMPORTANT use that people 
who ought to know better seem to be willing to IGNORE.  You can't push an 
agenda 
that works for 80% or even 95% of the users, if it leaves the remaining 20% or 
5% (whose systems PRESENTLY WORK WELL) totally high and dry.

We should remember that our goal is to stop spam by whatever means
possible,
protocol is just a medium.

Authentication does **NOTHING** to "stopping spam".  It only adds a few,
relatively minor, restrictions on the technologies that spammers (and
worms and
viruses) use.

Again I was not only talking about Authentication. Atleast it stops forgery.
which still helps fighting spam in a way.

No, it really doesn't.  

Not only does it NOT prevent zombie spambots from forging their infected 
machine's E-mail address onto their outgoing worms and spams, but stuff like 
SPF 
also doesn't even prevent forging SOME OTHER machine's authenticated E-mail 
address... If you send using (say) johnuser(_at_)comcast(_dot_)net, that mail 
will 
SPF-authenticate to (presumably) ANY Comcast mail server, anywhere in the 
world, 
where comcast.net mail is presumed to legitimately originate.  So a compromised 
comcast.net (authenticated) user machine can presumably send mail claiming to 
be 
from A DIFFERENT Comcast.net user halfway across the country, as long as they 
have the necessary passwords maybe (which can be transmitted by a compromised 
machine) since there are probably hundreds and maybe THOUSANDS of mail servers 
which are "authorized" to send mail from users using the comcast.net domain 
name 
for a return address.

Let's quit being dishonest about this.  SPF and the like does NOT help 
significantly in fighting spam.  That's merely being used as a pretext to sell 
it, much as "terrorism" is being used as a widely-understood pretext for 
selling 
the waging of a war that is otherwise unjustified.  Both are shameful and 
dishonest.  Those of us WHO KNOW BETTER should not allow ourselves to be duped, 
or to be misled into blindly supporting a halfassed, stupid bandwagon just 
because it's headed off somewhere and the band is playing loudly.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections!  http://stickers.defend-democracy.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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg


<Prev in Thread] Current Thread [Next in Thread>