On 30 May, Professional Software Engineering wrote:
| At 00:29 2004-05-30 -0400, Don Hammond wrote:
| >Email address in From: header is valid * but only for a couple of days *
| >This is my reluctant response to spammers' unrelenting address harvesting
|
| I posted about an avoidance technique in my procmail blog a week or two ago
| (to which I posted a pointer to here on the procmail list). You might want
| to review that - the problem with changing the LHS of your address is that
| your mail server will be bombarded with progressively MORE spam as the old
| addresses make their way into more databases. Using a different HOST on
| the RHS however allows you to abandon that interrim host and *SHED* the MX
| contacts.
I did read the post, and the blog. Sorry I didn't acknowledge it.
I've just been absolutely buried for months and haven't had time
to participate, though I do still read most everything.
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. I've tried
to keep dns changes to a minimum, probably being overly cautious, to
avoid being a nuisance. Since the mail server is mine, I have no
reservations about creating work for myself, so my efforts have
centered more on what I can do with the MTA, even if a little kludgy.
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 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.
There is also an upside, though unintended when I first implemented
this. The User unknown bounces serve as an early warning system
that allows me to more aggressively manage the access.db. I reject
far more email from the access.db than as User unknown.
| [...]
| As your method clearly relies upon PLUSSED addresses, unless you have an
| entry for each "retired" plussed address in your virtusertable or similar
| MTA facility, your server continues to ACCEPT the traffic and deliver it
| into your mailbox (and even if each retired address is listed, that's both
| a lot of management work as well as continuing MX hits, even if you decline
| them during the SMTP stage).
|
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. The logic works conversely to your guess above. Instead
of denying old addresses. I deny everything, including the underlying
user part of the plussed address, and specifically allow each new
address. By using a SMART HOST to talk to the outside world, an
internal MAIL HUB, and (slightly modified) null clients on the rest of
the lan, deh can still receive local (to the lan) mail, but is
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.
I don't want to go into the whole thing, since it's off topic. I'm
in the process of writing some web pages to document the whole thing
and I'll send out a notice when they're ready. The bottom line is it
does what I need it to do:
1. Limits spam. Right now it has eliminated it except from lists.
2. Does not transfer the cost to others.
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.
It wouldn't work for everyone. For my usage, though, it works
perfectly. If someone wants to reply to a message with one of these
addresses, they can. No PYLM, no editing munged addresses. No hoops
at all. The only place it won't do any good is in an address book.
In the places I use these addresses that's irrelevant. If anyone wants
a more permanent address, they're welcome to it. All my family,
friends, and business acquaintenances have one, and have no problem.
I've only had to change one of those more permanent addresses one
time in 3 or 4 years.
The rest of the work is pretty minimal. Subscription/unsubscription
processes are automated with procmail. All I have to do is generate
a new tmp address, update the virtusertable, subscribe it, then all the
rest, including unsubscribing the old address, is done automatically.
The only reason the whole thing isn't fully automated is I've been
tweaking the procmail parts and don't want to integrate them in a
comprehensive process until it's done and I know everything is safe.
Also, I like to exercise a little judgement. If I've recently posted
with the address, I'll keep it enabled a little longer.
All that said, I do agree your idea is better, for all the reasons
you lay out. It is almost fiendish, and I mean that as flattery. ;-)
There are some weaknesses in my scheme that have yet to be exposed,
but I know it's only a matter of time. I hope before that happens,
I can implement some of your ideas.
Don
--
Email address in From: header is valid * but only for a couple of days *
This is my reluctant response to spammers' unrelenting address harvesting
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail