On Mon, 13 Sep 2004, Mike Davis wrote:
The problem with listing each member individually is that there are 200 plus
members and the membership is very dynamic, adds and deletes on a daily
basis... this would be an absolute nightmare to keep on top of. What I've
done is white list messages addressed to the list, regardless of who sent
them... the list server then has the burdon of verifying whether they are a
valid member and able to post.
Just a suggestion to stop the message sooner since you expressed concern
about the extra processing overhead letting them through. A _small_ Perl
script run as a cron job (err, Task Scheduler task) could automate this
for you. Probably not worth the effort though since you probably don't
have any major processor utilization problems.
Just don't bounce invalid (non list member) email to the list. In the
event that someone legitimate tries to email the list but hasn't signed up
they're not going to be any worse off than if the message bounced (unless
you're including contact info in your bounce messages, in which case
you're going to get even more spam). Hopefully a legit person (who
hasn't subscribed) will have the common sense to email you directly or go
to your website after a few attempts at sending mail to the list.
Invalid mail will be returned to the sending address... it will not get
bounced to the list.
I didn't mean that you were sending bounce messages to all the list
recipients. I meant that any invalid mail addressed to the list could be
simply dropped on the floor. Don't even bounce it back to the _apparent_
sender listed in the From: header. The vast majority of spam has forged
From: headers anyway.
The odd legit person who tries to send mail to the list without
subscribing (who would normal get a bounce message, but the bounce has
been dropped) should clue in that they're not doing something correct.
This would solve your returned bounce message problem.
But until shaw.ca finds a better way to deal with their spam problems
then
just turning their inbound mail servers off, I'm not sure what else to
do.
I thought you were being sarcastic. Although I don't doubt it (or you), I
find it hard to believe that their customers aren't screaming at them for
stopping all mail, even legit mail, from being received.
Simply amazing.
You're asking Shaw to open their servers, and thus their users, to be more
vulnerable to spam (spam harvesters connect to SMTP servers and do brute
force attacks to find out a systems legitimate addressess) so that you
get less spam. You can see why they don't want to do it. What you're
asking them to do isn't even required by any RFCs.
You're mis-understanding what it is that Shaw is doing... when they are
under attach, they simply take their servers down... this means that the
published MX records for shaw.ca are invalid during this period.
Got it. Still sounds crazy though. They're not just blocking spam and
you from verifying accounts, they're blocking everything.
Does anybody with a Shaw account ever notice significant delays in
receiving their email?
When my
system attempts to perform it's sender authentication it can't connect to
shaw.ca servers, and refuses to accept mail from them since it can't verify
that the sending address is valid. I don't expect Shaw to "open" up their
servers, but when their published inbound mail servers don't respond to
connection request, how can you verify addresses from shaw.ca.
You can't, and you can't expect to even if their inbound MXs are up.
You can verify they'll accept mail for the account, but you can't
verify the account actually exists. Many domains will accept all mail
and drop mail to non-existent accounts on the floor to prevent address
harvesting. Of course if they do this it'll satisfy your check to see if
they'll accept mail for that account.
I don't agree with this method (there are far better ways to prevent
harvesting), but it's a common method nonetheless.
A similar situation is a boundary MX server with no directory service.
It'll accept all mail too.
Worst of all, and luckily not so commmon, but certainly existent
(especially with users of vanity domains), are domains using DomainPOP.
I'm not sure what the issue is with your software, but it seems to try and
query the sending server, and not the proper MX (why I don't know, but it
did it too me when I was using DomainPOP this summer -- yes, my MXs are
correct).
In any case, it's a fairly flawed method which doesn't give you reliable
info. At best you get the account doesn't exist or that the account might
exist. It also puts you in great risk of getting tarpitted or blacklisted
(see below).
Shaw told me
that they would white list my mail server, but I still got a number of
failed connection request after the fact. Over the course of 10 days I
tried to connect manually to both of their inbound mail servers and 9 out of
10 times, one of those servers failed. There are simply more problems here
then Shaw simply trying to protect themselves.
It _really_ sounds like you (or your server) were checking to see if too
many (possibly as few as one, two, or three) non-existent shaw.ca accounts
existed and were being tarpitted by their inbound MXs.
That makes much more sense then them shutting down their mail service and
matches the symptoms exactly.
Have you tried connecting to their MX servers from a _different network_
at the same time you can't connect via your own?
As for them whitelisting you... I doubt they actually did it. Especially
if you only talked to first or second tier support at Shaw. Those folks
don't even get to touch server configs. Maybe you talked to someone
higher though?
Another way to prevent your gateway server from accepting spam is to do
xRBL and SBL lookups on each connection. Depending on your Windows mail
server, you may or may not be able to do that though. MDaemon
(
www.altn.com) for Windows will do that.
Already do this...
You probably already do reverse, then forward lookups, but it's worth
mentioning just incase. It's actually not required by any RFCs either,
but anyone who doesn't do it is an idiot (and they're going to get their
mail rejected from most major providers).
Anyway, tell me to shut up if you want. :) I probably should anyway
before I bore everyone even more.
Daryl
-----------------------------------------------------------------
List archives located at:
https://mail.dcsol.com/login
username "rebel" password "builder"
Unsubscribe:
rebel-builders-unsubscribe@dcsol.com
List administrator:
mike.davis@dcsol.com
-----------------------------------------------------------------