Despamming wholesale dialup

Greg A. Woods woods at most.weird.com
Thu Oct 29 04:27:54 UTC 1998


[ On Wed, October 28, 1998 at 19:47:01 (-0600), Phil Howard wrote: ]
> Subject: Re: Despamming wholesale dialup
>
> Keep in mind one point.  Many people who have domains hosted at various
> web providers, where they pick up their mail there, too, use dialup
> providers like you and/or your resellers for actual connectivity of
> their PCs since they don't get that through the web provider that hosts
> their domain.  What that means is that many legitimate dialup customers
> will be sending their mail _FROM_ a domain name that is NOT one that
> the dialup provider or reseller is necessarily configured to recognize.
> Often such outgoing mail is blocked as "source forgery" and these people
> just use the SMTP server at their web provider.  The above breaks this.
> So some kind of alternative needs to be provided.

I don not think any alternative is required, at least not for the
general dial-up access account (see below).  People cannot have their
cake and eat it too.  I think some of these situations have taken the
"virtual" business just a bit further than is practical and now the rest
of us are suffering under enormous spam loads as a result.

Even worse, of course, are those virtual ISPs which attempt to offer
SMTP servers too.  I would suggest that the only viable way these types
of businesses should operate is by using some kind of third-party
roaming service (eg. iPass) whereby the user is authenticated at the
virtual ISP and at least in theory then the roaming service could pass
back authorized SMTP server IP numbers, etc. which could be installed in
the dial-up filters once the user has been authorized.  These sorts of
arrangements do require agreements between the virtual ISP and the
dial-up provider though -- either through an access broker like iPass,
with direct relationships.

> We do this only for dynamically addressed dialups.  This is done through
> RADIUS so I can turn it off individually per account, and do so on a case
> by case basis with explanation of need.  This might mean adding a new
> field to your customer account database.  I call mine "allow_smtp".

Specifically authorized exceptions to filter policies are OK, especially
when they help further cement the relationship between a customer and
his/her ISP.  Hopefully you charge a service fee for making such
exceptions though!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>      <robohack!woods>
Planix, Inc. <woods at planix.com>; Secrets of the Weird <woods at weird.com>



More information about the NANOG mailing list