At 17:39 2004-05-30 -0400, Don Hammond wrote:
I did read the post, and the blog. Sorry I didn't acknowledge it.
My cite of it wasn't expecting acknowledgement, merely pointing out that
the approach I outlined means you don't waste cycles dealing with spam
being sent to these "expired" addresses -- in your current plussed scheme,
the more you cycle, the worse things will eventually get for you.
Remember, spammers don't scrub bad addresses from their dbs. If you have
just ONE account which you cycle, and you cycle it once a week, that means
you have the potential of 52 new addresses for the spammers to harvest each
year. For one user.
I agree with your points and do like your idea very much. Right now,
I host my own mail server but dns is done by my provider.
If it's YOUR domain, and you have a reachable host (fixed IP), that system
can be the authoritative master for the zone, but needn't be the host which
is published as an answering nameserver in your domain registration (i.e.
your host can control the zone contents, but doesn't have to answer queries
- it merely sends notifies and performs a zone AFXR with the published
nameservers). Setup for this is pretty trivial. Once set up, there's no
need to get your hosting service to do anything when you want to make a DNS
change, unless your IP changes.
For what it's worth, which is admittedly not much, this hasn't yet
led to a marked increase to those addresses, at least not apparently.
Although the overall spam (attempts) are increasing exponentially,
the User unknown rejections to these addresses are, so far, minimal.
That will change over time. I'm seeing a *LOT* of hits on things which are
not even addresses -- the spammers are harvesting messageids because they
generally appear like addresses: (something)@(host.domain.tld)
That doesn't mean that other rejections (check_mail, check_relay)
aren't the result of increases to those addresses, but I'd think it
would also be evidenced in the User unknowns if that were the case.
A plussed account won't generate user unknowns unless you're explicitly
listing the expired plussed aliases in the virtusertable with an ERROR:NOUSER
It didn't used to rely on plussed addresses. I have you to thank for
that. ;-) I used to use newly generated aliases. It was a discussion
some months ago where I learned that even if deh is undeliverable (it
is) I can specify deh+whatever in the virtusertable and it will be
deliverable.
Ah, so deh isn't a valid account otherwise. That invalidates my point
about the ERROR:NOUSER bit above, which was predicated on deh being your
usual account. Using the ionvalid base account and then plussing on top of
that means you don't have to maintain a list of the old expired accounts,
which is good, though you still have to contend with the assault of
connections to your MX.
unreachable from the outside. This means I never have to mess with
adding/deleting user accounts and only have to modify 1 entry in 1
virtusertable (on the SMART HOST) for each change.
This could even be done with a cron invoked script... <g>
1. Limits spam. Right now it has eliminated it except from lists.
2. Does not transfer the cost to others.
Both good objectives, particularly the second one.
Although I've gotten in one "discussion" with someone who took offense,
I consider that to have been his problem not mine. He is incapable of
grokking that not everyone has to do things and see things exactly his
way. We all know the type. I've never said it is a silver bullet.
No, nor is anything I've offered. You're certainly welcome to use what
technique works for you, and this one certainly should be acceptable to
others since it doesn't involve a PYLM validation scheme. THOSE are annoying.
at all. The only place it won't do any good is in an address book.
Heh, and that means your address is reasonably shielded against viruses and
spyware harvesters.
Also, I like to exercise a little judgement. If I've recently posted
with the address, I'll keep it enabled a little longer.
Well, if you say change the alias once a month, it makes sense to keep the
alias live for say two weeks into the new month. The potential volume of
spew you'd get as a result should be nominal, and you could still elevate
spammishness on a message addressed to a recently cycled (but not yet
expired) alias.
Note that you could employ *BOTH* techniques: cycle the plussed account,
and then once or twice a year (which is doable with someone else managing
your DNS, and certainly no more often than I'd suggest needing to do it
with that approach alone), you cycle the hostname portion.
Low-administration avoidance in the here and now, plus connection shedding
for the long term.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail