<snip>
> > If they use AOL mail, they _have_ to use the AOL client as far as I
am
> > aware.
>
> That's true, if I remember rightly.
If they use the AOL email client, yes. But as long as they are
connected via AOL, they can use any email client they choose. Many
users wouldn't know this, I suspect. But some do. However, see
discussion below about port 25.
>
> However, they might not be using AOL mail or sending via an AOL
gateway -
> for example, user@??? might also connect via another ISP and send
out
> mail via the separate ISP addressed from user@???, perfectly
> legitimately. Any restrictions based on the User-Agent / X-Mailer or
similar
> would reject any such mail.
>
> While the number of users with AOL addresses likely to do this is
small, it
> seems very draconian (and arguably wrong) to reject their mail.
Obviously
> you're also going to reject any legitimate mail coming via AOL should
they
> (quite reasonably) change the information in the headers they send.
I agree.
>
> As an aside, SMTP callbacks should work with AOL as they 550 unknown
users
> at RCPT time. Of course there's probably so many usernames that many
*will*
> exist though...
I don't know if this adds much to the thread (other than hot air), but
for what it may be worth:
I am a "web presence provider" (that is, I host domains, for both
websites and email), but NOT an ISP (that is, I do not have any dial-up
connections or anything of the sort... my customers must have a
separate ISP to actually connect to the internet. They use SMTP and
either POP or IMAP to interact with my mail server). The main idea is,
my users are free to change ISP without having to change their web
identity. I also provide several security features, such as only using
encrypted channels for password transmissions, that most ISPs do not
currently provide.
OK, that's the background. Now, for the AOL issues. Anyone using AOL
to connect to the internet is not permitted to contact port 25 on any
arbitrary host. AOL hijacks the port, and diverts all IP packets to any
IP address:port 25 to one of their own AOL mail servers. This is
intended to cut down on spamming through AOL, by denying access to "open
relays" via AOL dial-ups.
What this meant for me was, (after discovering it, when my first AOL
using customer signed up), I had to open another port on my server.
This allows my customers to send email via SMTP relay, through my
server, but only AFTER successful authentication (see note above, about
requiring encryption, to avoid spammers cracking into the server through
said path). They just have to tell their email client package (Outlook,
or whatever) that my server is their SMTP server, and that
authentication and SSL are required; and also, change the SMTP port
number to what I tell them.
Now, these emails are perfectly legitimate, and in order to keep my
business model intact, I need to understand any issues that might cause
some of their email to fail, when it should not.
I've said this before, but I'll repeat it here: I do NOT permit
spammers to be customers. If they were caught, they would be terminated
instantly, without a refund. Spam is not only illegal in the state I
live in, it also violates the contract with my ISP; I am perfectly
within my rights to instantly cut-off anyone trying to spam through my
server. So far, I have had zero problems with this; but, I am still
small. ;)
So, I guess my point is, try not to build anti-spam systems based on
things that you ASSUME about the headers in an email. Base it on things
that are difficult to fake (such as the IP of the sending host - see
RBLs, callbacks, etc.), or on the content of the mail itself (e.g.
Spamassassin), or the existence of executable content (e.g. Nigel's
system filter).
To put it simply, "innocent until proven guilty" is my motto, with
respect to evaluating emails. It is better to let through a few actual
spams, than to block even one legitimate email. End-users can handle
the occasional piece of spam just fine. It's when they get more spam
than real mail that there's a problem. You may disagree with this
philosophy. To each his/her own. Just be careful when inventing clever
new spam-blocking schemes, that you don't "throw the baby out with the
bath water."
The internet is continuing to evolve. You'll want to avoid implementing
a scheme that works great today, but may break all kinds of things
tomorrow. Sure, "fix it when it happens"... And how long before you
realize it needs fixing? 3 hours? 5 days? 6 months? Ever? I'm just
saying "be careful, think it through." And remember that TIMTOWTDI.
I don't just mean, more than one way to block spam. I mean, more than
one way for legitimate users to be sending their emails. Many, many,
many people send email from remote locations. They may not be able to
control which ISP they are using to connect to the net. But, if they
have a "home" server (like mine) which permits them to securely send and
receive their emails, I sure don't think it would be a good idea to cut
off their email just because they chose the "wrong" ISP to get online
through!
Anyway, just because an email has "aol" in one or more headers, doesn't
make it spam. As the previous writer noted, someone can log in via AOL,
and then send an email via a 3rd party SMTP server (like mine). That
does not make it spam. It makes it a convenience for the customer. And
it is critical to my business model, which (I think) is a good one,
because it gives users more control over their internet experience
(freedom to choose any ISP, without being forced to change their email
or web address each time).
Just my 2 cents worth. Sorry for the lengthy post.
Jim Roberts
Punster Productions, Inc.
p.s. - There is going to be an Anti-Spam conference, at M.I.T.
(Cambridge, MA, USA) this coming January. I heard about it through the
MIT Alumni Association. All interested parties are invited. See
http://spamconference.org/ for more details.
