I wrote:
> > to use a dialup earthlink connection for the first time in several
> > months - apparently uunet's dialup routers are now configured to
> > block all attempts to connect to tcp/25 (smtp) *except* to
> > approved mail servers on the ISPs' networks.

Rob Quinn <rquinn@sprint.net> writes:
>  It's an EarthLink thing, not a UUNET thing.

Perhaps managed by EarthLink, but the filter seems to be installed on
the dialup server (a TNT operated by UUNet) (probably it's just a
simple packet filter included in each user's RADIUS record). Either
that, or the machine sending back the reject is lying about who it
is...

> We can only hope that other dialup providers and ISPs adopt this
> policy.

Better they should spend their limited NAS CPU time on dropping
packets with spoofed source addresses (maybe they do by now - I
haven't checked in a long time). I start getting nervous whenever an
ISP blocks _useful_ traffic of any kind. What will they block next?
IPSec? (Cox@Home reportedly does). My brother's cable ISP started
blocking all incoming tcp sessions awhile back. How badly would *that*
suck?


> > I can connect to mail.earthlink.net, but an attempt to connect to
> > another mail server (under my own administrative control, so I
> > know it isn't blocking the connection itself), gets blocked, with
> > the following return:
> 
>  If you control both ends, set up a VPN or some other tunnel. Then
> you won't open yourself up to relaying from the world.

This was for testing purposes only, to determine exactly who was
whacking my mail connections. The remote machine I used for this test
normally doesn't do any mail at all. In the one case where I do have
mail going across the Internet to another private network, everything
goes through an IPSec tunnel. (My own machine doesn't allow relaying).

Wolfgang Rupprecht <wolfgang@wsrcc.com> writes:
> Setting up sendmail to use an ISP's mailhost should only take one
> extra line in the sendmail.mc file.
> 
> define(`SMART_HOST', esmtp:mailhost.myisp.com)

If I understand correctly, when you do that, *all* mail ends up going
to SMART_HOST. In my case, mail to certain domains must go to a
particular remote server, in order to assure that the mail goes
through an encrypted IPSec tunnel rather than in the clear over the
Internet.

Also, my backup connection is with a different ISP, so I would have to
reconfigure sendmail whenever I switched to the backup (or back to the
primary). Yet another detail to worry about.

Anyway, thankfully my primary connection is back up, and they don't
filter smtp. ;-)

Todd Vierling <tv@wasabisystems.com> writes:

> Actually, I've even seen ones that NAT-translate attempts to connect
> to port 25 back to their SMTP clusters.  That's even more ingenious,
> IMHO--roaming users don't have to change their configs (or have the
> knowledge to do so).  Fits right in with the average Internet user's
> network IQ.  :>

Ah, now that sounds like a *much* better solution! It would actually
work for me, whereas the current setup doesn't, even if I set
SMART_HOST (see above). I doubt I would have any complaints if they'd
set things up this way.