On Mon, Oct 13, 2003 at 06:51:01PM -0500, John Hasler wrote: > Joel Baker writes: > > I'm going to gloss over the utter mistake of your first statement > > I am on a dialup with a "dynamic" IP number: I am allowed to borrow a > number from my ISP at need. There is no IP number over which I have any > administrative control. Thus I have no IP in that I would be unable to > implement any system that required control of "my" IP number.
This is not a problem with Dynamic DNS updates. Many places do hosting of
DNS domains (only; no web or mail, etc) for absurdly cheap rates ($5/mo in
some cases), and allow either DDNS or an automateable webpage to do updates
with.
> > 4) Normal end-users relaying through their home ISP, organization, or
> > business (The Road Warrior)
>
> My ISP does not permit this. It is the only one available to me.
Your ISP probably doesn't permit outbound connections from dialups to port
25 (gee, can't imagine why that might be the case...); it is amazingly rare
to find an ISP that actively blocks VPN, IPSEC, *and* SSH traffic, and is
still in business, however.
Both for bypassing ISP filters, and for security reasons, relaying this way
is fairly standard for the Road Warrior sorts (in no small part because it
also protects the bare passwords that are still mostly used in POP3/IMAP
servers in most situations; yes, I know about IMAP over SSL, but that
doesn't do well when you need to coordinate remote salesdroids with local
management, and they all use Outlook's calendar stuff to handle it).
> > Classes 3 appears to be your situation; both this, and class 4, are
> > removed entirely from the question of SPF/RMX/etc, because they relay
> > through their ISP's smarthost (and thus, that smarthost is what will be
> > checked for being allowed to send to a remote site).
>
> I cannot relay through my ISP's smarthost from outside his system.
Not at all uncommon, though it might be worth trying to convince them
to allow you to do *authenticated* relay from outside. Oddly enough,
preventing random IPs from relaying is because... spam comes through.
> > You smarthost your email to a server configured to handle turkey.com
> > email, which is presumably listed in the policy, and *it* sends the email
> > on to the remote site (which then sees it coming from that server, not
> > you, and will accept it as coming from an approved server).
>
> That is how I thought SPF worked. This would be fine with me. However,
> statements made earlier in this thread seemed to me to imply that the
> cooperation of the administrators of domains from which mail would be
> originating would be required. This would be useless to me: I doubt I
> could get the cooperation of even my ISP, let alone some hospital or
> library.
*Mail* has an return path that includes domain names (normally). SMTP
*sessions* have a source IP. All of the protocols I saw obviously listed on
the ASRG page (including at least RMX, SPF, and Vixie's proposal) use the
*claimed* domain (which can be anything), and the *actual* source IP (which
cannot be forged without having access to the routing hardware in between
the machines, at which point you can do damned near anything you want), to
decide whether it's kosher. The library's domain is irrelevant, in this
case, since you're not claiming a return address in the library's domain.
As a real world counterpart: if I sign up for a thousand 'free catalogs',
using the address of my next door neighbor and arch nemesis Fred, he will,
in fact, probably be deluged under a mountain of advertisements for lawn
aeration shoes and crystal healing methods. I can do this from thousands of
miles away, in fact; maybe Fred moved to Texas, and this is my long delayed
revenge. Now, Fred can ask the post office to stop sending them through
(and in fact, they'll probably notice it in the first place) - ISPs do
similar things in a lot of cases, today, for their customers.
The problem is that rather than being a rare incident of juvenile humor or
mild spite, it's a business with a fairly serious amount of money involved.
Now, imagine if the folks giving out catalogs had access to a "no mail"
database in which Fred could (if he wanted to register at all), say that
any attempt to request catalogs that didn't come postmarked by his local
post office should be ignored.
I can still mailbomb George, who hasn't signed up on the list; there may be
ways to send my mail from Fred's local post office (note that the analogy
stretches a bit thin on this point), but I can no longer send email from
Nome, Alaska claiming to be Fred in Texas wanting catalogs.
There are established ways of dealing with folks who are on the road all
the time and legitimately might be anywhere in the world, but still want
to get catalogs sent to their house; before I started mailbombing Fred,
maybe he was fine with just sending them in with no limitations. Now he's
tired of it, and it's less time and effort to deal with the hassle of
updating that list, rather than A) get mailbombed, or B) not be able to
send catalogs home.
> > If it's a choice between being nice to the people in class 5, and having
> > a thousand fewer emails a week to sift through in *my* mailbox, they can
> > take a flying leap. None of them are important enough (right now) that I
> > want to get their emails *more* than I want to *not* get that many
> > spams/broken autoresponders/viruses/etc.
>
> I get several hundred per day, many indicating that some SOB is sending
> libelous and obscene spams in my name. If SPF works as it seems I want it
> ASAP.
Look up "joe job". All of the proposals on the table for ASRG would resolve
this; the question is just the details in exactly what you say, and how you
say it to the world, when you say "Here are the post office postmarks that
are OK when checking whether I sent a request for a catalog".
--
Joel Baker <[EMAIL PROTECTED]> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
pgpyOdyyehyUp.pgp
Description: PGP signature
