Subject: Re: [Asrg] SMTP AUTH

From: [email-masked]
Date: Mon, 6 Dec 2004 03:58:34 +0000 (GMT)

>> mobileSender@myDomain--AUTH--> myDomain SMTP--SPF,MTAMark etc---target SMTP
>  |__________________________________________|
> 
> 
> I truly don't understand why the types that keep hawking SMTP AUTH as the 
> solution JUST DON'T GET IT... how many times do we have to say this?
> 
> THE FACT IS THAT IF YOU ARE ON A CRUISE SHIP AT THEIR INTERNET CAFE, OR AT AN 
> AIRPORT WAITING LOUNGE INTERNET ACCESS KIOSK, (and many other public-access 
> situations) YOU MOST LIKELY HAVE *NO* CONTROL ABOUT WHAT SMTP MAIL SERVER IS 
> GOING TO BE SENDING YOUR OUTGOING E-MAIL MESSAGE.  That notwithstanding, 
> OBVIOUSLY you would STILL want to use "your" own E-mail address as the sender!

> Ouch. CAPS!

And STILL the message doesn't seem to get through...!!!

> Let me see, you have an IP conection, 

No, you do NOT.  You are talking as if you have a (your!) computer in front of 
you.

You have a MONITOR and a KEYBOARD, usually a mouse, including (perhaps) a 
PROPRIETARY E-mail composition program of some kind.  You can enter the To: 
address and a From: address, and you can type in your message.  That's just 
about IT!!!!

[Usually you also have a Web browser of some kind (although generally it's been 
heavily neutered) and (for our discussions here) we're talking about SMTP-type 
mail, not Web-based mail.]

> ...presumably connected to the Internet. 

For Web access, yes, obviously.  For E-mail access, that's much less guaranteed. 
(Usually outgoing E-mail is first handled by a local mail server on the ship, 
which itself might or might not have a full-time Internet connection.)

In any case, as a rule, you have NO control whatsoever of what SMTP server will 
be used, or indeed even what path your mail takes to (eventually) get off the 
ship.

> ...You should be able to access the submission port to send your
mail via your mail server. You just might not be able to use port 25/tcp
there.

Again, no.  You have (as a general rule) **NO** way whatsoever to specify which 
SMTP server will be used to process your mail.  You have a TO: address field, a 
FROM: address field, (maybe) CC: and BCC: fields, and a message compose window.

And a SEND button for when you're done.

That's basically ALL you have.

> SMTP AUTH solves the problem of being able to uniquely identify the
spamming user and allowing the ISP to terminate those accounts without
having to try and fiugre out which user had that IP at that time from
the DHCP logs.

That's fine, for cases where it's suitable.  Unfortunately, that does NOT 
include a LARGE number of cases.

And, of course, having Internet connectivity these days does NOT necessarily 
imply also getting "ISP services".

Another point you are ignoring is that (again) it DOES NOT ELIMINATE THE SPAM 
PROBLEM.  Okay, so (dear, elderly) Aunt Gertrude clicked where she shouldn't 
have, and now her machine is infected by a zombie spambot, and that spambot is 
cranking out (authenticated!) worms and spams.  So now what is her ISP going to 
do?  "Terminate her account"?  If we terminate the accounts of every clueless 
user who ever got a virus or worm onto their system, pretty soon there won't be 
ANYBODY left to send E-mails TO!  Do we electronically destroy Aunt Gertrude's 
"reputation" so nobody will accept her mails anymore?  And how do you eventually 
CORRECT that damage so her (now-cleaned, at least for the time being) system can 
send mails again?  Will she simply abandon the Net entirely, in frustration and 
anger?  

One of the neat things about my approach is that Aunt Gertrude's legitimate 
mail, EVEN WHILE SHE'S INFECTED, is still getting delivered just fine, because 
it LOOKS LIKE HER MAIL IS EXPECTED TO LOOK.  The stuff her parasite spambot is 
generating is getting T-canned, however, because it DOES NOT LOOK RIGHT, based 
on what I expect (and want!) to get from her.

Now, admittedly, my approach is primarily intended to protect-and-benefit THE 
RECIPIENT (and that makes a lot of sense, since the person who benefits the MOST 
from it is the person to install and adjust it) but nothing would preclude a 
corresponding filter from being put in place on ISP systems too (for cases where 
there ARE ISP systems involved!) which could establish comparable 
restrictions... for example, I don't send HTML-burdened E-mail, NEVER would send 
ActiveX HTML tags, and wouldn't ever send .CPL files or 180K-byte '.PIF' 
attachments.  And although I am a programmer and consultant, there are only a 
limited number of folks to which I would want to send an executable attachment 
(and I wouldn't PARTICULARLY mind needing to whitelist those folks before 
sending something like that).

And if Aunt Gertrude's ISP put into effect default limitations preventing her 
machine from sending (for example) executable attachments, or E-mails containing 
JavaScript, or other such suspicious stuff, I very much doubt that she would 
EVER be inconvenienced by those.  (But if her machine were to get worm-infected, 
it would surely block it from sending out such stuff, at least if using the 
ISP's mail server to do so!)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Mon, 6 Dec 2004 16:21:53 +0530 (IST)

>>> mobileSender@myDomain--AUTH--> myDomain SMTP--SPF,MTAMark etc---target
Most organizations today have https webmail access so I don't see any
reason for using other applications.

@

---

From: "Peter Bowyer" <[email-masked]>
Date: Tue, 7 Dec 2004 07:39:15 -0000

> reason for using other applications.

That's a very sweeping observation - what's your source for this data? 

Peter