We are offering wholesale dialup ports. When a user connects he is authenticated and can do whatever
it is he/she wants to do on the net. Unfortuantely some have decided that they will relay spam off of other servers.
To address this i have proposed installing filters that will only allow these folks to connect to
port 25 of the ISP that has bought the ports. This way they are not able to relay off of anyone elses machine
that is using port 25 and the buyer of the ports should have the correct measures set up to prevent bulk mail from
going out.
Will this be sufficient, providing that the server they are allowed to connect to has set up his mail server to prevent massmailing..?
We do this already. AT&T Canada has already committed to doing this.
It will not totally stop spam, but it will impact the way it is done
now, and will force the spammers to pound the mail server of their
own ISP to get the bulk mail out, instead of spreading the load over
the net. That may successfully break many bulk mail programs.
I would suggest doing it.
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.
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".
[ 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!
[ 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.
I disagree, but the mechanism for implementing this involves making the
customer buy an SSH client. They connect with a VPN tunnel and the problem
goes away, as long as port 22 is available. The problem is that many
firewall admins think port 22 is a security hole (back-door). After all,
when the port is named "security" that means you're supposed to block it,
right? The point is that often ports 25, 80, and 110 are the only
legitimate means of access. We've even had to run SSL on port 80 for some
customers because their local firewall only allowed port 80.
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!
You whole scheme fails because of over-loaded middle-man charges. Too many
pint-sized bills from too many sources. The accounting alone would be a
nightmare.
[ On Wed, October 28, 1998 at 23:40:34 (-0800), Roeland M.J. Meyer wrote: ]
Subject: Re: Despamming wholesale dialup
I disagree, but the mechanism for implementing this involves making the
customer buy an SSH client. They connect with a VPN tunnel and the problem
goes away, as long as port 22 is available. The problem is that many
firewall admins think port 22 is a security hole (back-door). After all,
when the port is named "security" that means you're supposed to block it,
right? The point is that often ports 25, 80, and 110 are the only
legitimate means of access. We've even had to run SSL on port 80 for some
customers because their local firewall only allowed port 80.
That's an even better way virtual ISPs can provide access to "virtual"
services. (It's better for both the client and the vISP because it
means no data in the raw across joe-who's dial-up networks and the rest
of the internet.)
The issues surrounding this scheme that come from brain-dead firewall
administrators who don't really understand what's going on, or from
brain-dead users who are ignoring their company security policy and
trying to access virtual ISPs from within their company network, are of
course very real, but they're not show-stoppers as you've proven.
You whole scheme fails because of over-loaded middle-man charges. Too many
pint-sized bills from too many sources. The accounting alone would be a
nightmare.
Actually, no, it doesn't, at least in the case of the one such dial-up
brokerage service I mentioned. They do all the accounting for you. It
even integrates directly into your own dial-up accounting if you happen
to have dial-up ports too. I don't think they currently return the SMTP
server's IP to the dial-up providor, but the dial-up provider can
probably be reasonably sure that such a user isn't likely to spam. Of
course if this method of doing business for bulk dial-up becomes
predominant and bulk ISPs begin to block port 25 as described above then
it will be necessary for the broker to facilitate transmittal of
information necessary for more secure dial-up port filters.
