procmail
[Top] [All Lists]

Re: getting sendmail & procmail to use + addressing for virtual domains

2002-07-26 15:10:49
At 14:10 2002-07-26 -0700, Charles Hornberger did say:
one of them -- my old charlie(_at_)tabloid(_dot_)net address -- has been 
completely
inundated with spam, and I'd like to stop using it ... but I don't
necessarily want to start sending bounces right away. I'd prefer to
generate an auto-reply to any messages that arrive at the
charlie(_at_)tabloid(_dot_)net address, telling people (nicely) that unless 
they're
sending me spam, they should use my other address
(charlie(_at_)nothingspecial(_dot_)com).

Why "ease" anyone into it? Those whom you _actually_ communicate with should catch on quick enough, and the sooner they switch to your new address, the sooner you're not accepting spam at the abused address. So, why not just create a bounce via virtusertable:

charlie(_at_)tabloid(_dot_)net ERROR: 550 SPAM not accepted here, see <http://blah....> for updated contact information.


This way, you're refusing the message right at the addresssing phase, rather than accepting the whole darned thing (that includes the volumes of spam that you're closing the account because of), *AND* you're not providing the email address in the clear - either via an autoreply (which MIGHT go to a spammer, though generally will just bounce), or via the bounce text (which you could list the address instead of a URL if you wanted to). People interested in still emailing you could click on the URL and get info (and perhaps that nice explanation you want to provide them with). Mailing lists to which you might be subscribed should eventually purge the address (though, if you're subscribed to anything, YOU should take the initiative and unsub).

Total technical investment: tweak to virtusertable entry, and a simple webpage.

(It might be worth noting at this point that I don't actually log in
over POP3 to the 'charlie' account, since that account has shell access
to the server and I don't like sending such passwords in the clear;
instead, the last line in my .procmailrc file forwards all messages for
charlie to a mail-only account on the same machine.)

I can think of several alternate approaches, but this is workable for you...

looking for. It seems like procmail just isn't getting passed the '+'
part of the recipient address ... either that or it's storing it
somewhere other than in $1.

The recipient _address_ isn't passed on the commandline to the LDA. The "address" which the LDA is provided with is the user _account_ (which plussing doesn't apply to).

Since you obviously administer the server, if the above suggestion of setting it to BOUNCE with a specific message isn't workable, then how about you try setting up an alias:

[virtusertable]
charlie(_at_)tabloid(_dot_)net     charlie_xx

[aliases]
charlie_xx charlie, "|/usr/local/bin/procmail -m /etc/procmailrcs/charlie_bounce.rc charlie(_at_)tabloid(_dot_)net"


this way, the mail still arrives at your mailbox (and is filtered normally), and *SEPARATE FROM THAT*, a copy is delivered to an rcfile that handles your autoreply advisory, and as an argument to that, is being passed the address which the alias is tied to (if you wanted to use the script to handle more than one such notification condition).

When at some point, you want to send just the notification but not deliver the messages to a user, you would strip charlie from the list of recipients. Alternatley, you'd remove both entries, and/or change the virtusertable one to a bounce message similar to the one I describe above.

---
 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

<Prev in Thread] Current Thread [Next in Thread>