AOL bans mail servers from DSL providers. Check your email lists....
 

Check your lists and filter out any AOL mails if you are sending them from inside these networks.

AOL is now scanning for mail servers within DSL providers.

*************************************

[linux-elitists] AOL says goodbye to AT&T/Comcast and residential mail spools
Aaron Sherman [email protected]
10 Apr 2003 23:19:39 -0400

Previous message: [linux-elitists] SSL security certificates
Next message: [linux-elitists] AOL says goodbye to AT&T/Comcast and residential mail spools
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

--------------------------------------------------------------------------------

--=-mwIPc/qgXAQjPTyeqgKK
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hope no one here has friends or relatives that use AOL if you run your
home MTA on a residential network.... If you do, you'll have to start
relaying mail for AOL through the public relay (probably slow and flaky)
that your ISP provides. Why?

AOL has instituted a new policy: TCP sessions established on port 25 to
any of their MX hosts from systems that obtain their IP addresses
dynamically (their term, I don't know exactly how they define it, since
I'm not on any reputable, public dynip BLs that I can find) will be
summarily disconnected after the transmission of several lines of text
which resemble an SMTP error.

I say "resemble" because the SMTP RFC is clear on their options at this
point in a session (e.g. after the transport session has first been
established):

The SMTP protocol allows a server to formally reject a transaction
while still allowing the initial connection as follows: a 554
response MAY be given in the initial connection opening message
instead of the 220. A server taking this approach MUST still wait
for the client to send a QUIT (see section 4.1.1.10) before closing
the connection and SHOULD respond to any intervening commands with
"503 bad sequence of commands". Since an attempt to make an SMTP
connection to such a system is probably in error, a server returning
a 554 response on connection opening SHOULD provide enough
information in the reply text to facilitate debugging of the sending
system.

AOL violates this on two major points:

1. They issue a series of 550 responses, not 554, like so:

550-The IP address you are using to connect to AOL is either open to
550-the free relaying of e-mail, is serving as an open proxy, or is a
550-dynamic (residential) IP address. AOL cannot accept further e-mail
550-transactions from your server until either your server is closed to
550-free relaying/proxy, or your ISP removes your IP address from their
550-list of dynamic IP addresses. For additional information,
550-please visit http://postmaster.info.aol.com.
550 Goodbye

2. They then send a reset packet to disconnect the session.

I'm going to look into what it takes to get a site on the various
RFC-non-compliance lists, but ultimately, the RFC lossage is not my core
beef (though it certainly is indicative of an attitude that has lead us
down this path). My concern is that more and more companies and
individuals are slicing out those portions of the Internet that they
don't think that they would ever want to interact with in relatively
blind and poorly managed ways.

You cannot, for example, get your well-behaved mailer removed from the
list, since even the initial report that they will send you from their
Web-tool is emailed, not to the IP in question, but to root at the
domain that registered the IP with ARIN!

How much further down this path of large ISPs slicing out the "unwanted"
do we have to see before all ISPs will simply stop passing packets past
their own networks which do not originate from their servers or a
"registered business partner" of some sort?

I'm recommending to all of my friends and family that (a) it will be a
cold day in hell before my mailer config is polluted with a special
entry for every ISP that thinks DHCP-assigned IPs aren't really part of
the Internet, and (b) unless they have the swing to change AOL's policy
on this one, they're better off getting an account with an ISP that
might warn them before taking such drastic and harmful actions.

Sorry for the rant, but I'm annoyed as hell over this. Thanks.


--=-mwIPc/qgXAQjPTyeqgKK
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA+ljRLL7LA8FwnXp4RAoUgAJ40Q9D3B8thUxBC6a8MSq C33Qa+mQCfXuHM
G5IxuEqXI1VW7Ks2+GM640A=
=rIFE
-----END PGP SIGNATURE-----

--=-mwIPc/qgXAQjPTyeqgKK--

Um, any chance of getting the English translation into what, exactly, this means?

Yeah, I'm not too fluent in geekspeak.

Basically if you are running a mail server or software that looks or acts like a mail server and it looks like a dynamic ip then AOL is going to tell you to get lost with your mail.

Dynamic ip's are how most DSL users, and dialup users for that matter, are connected to the net.

LOL,, i was thinking the same thing,

Oh well, I dont care if blocks legit emails.. as long as it blocks spammers also, then I'm for it :thumbsup

Good thing I've got a block of fixed IP's from my DSL provider :Graucho

:glugglug

:glugglug

Fuck it. :glugglug

Just to clear up any potential confusion,

This will not affect DSL/Cable users sending mail through their broadband ISP's mail server.

It will only affect users who setup their own mailserver on their machine that is connected through the DSL connection. To be quite honest I don't see any reason to do this in the first place because a lot of ISPs are starting to block "residential" ips anyway.

Besides most DSL/Cable companies forbid running a server so this is all a moot point anyway.

If you are running a 4free program and doing some serious opt in bulking than you'd be leasing dedicated ips anyway.

Also they've been blocking dynamic dialup ips for quite some time, so this really isn't anything new.

Personally I think they should let users decide on how to filter spam by offering powerful word and phrase version which users can individually enable rather than deciding for the user what he or she should see.