mobileSender(_at_)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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg