At 13:06 2003-02-25 -0300, FRODRIGUEZC(_at_)REPSOLYPF(_dot_)COM wrote:
Hi, I have just subscribed to the list because I feel a total jerk,
trying to make something apparently simple work!
Lighten up on yourself - learning new things doesn't make you a jerk.
However, what you're trying to accomplish is _thoroughly_ a matter for
sendmail configuration. The only involvement of procmail is to optionally
tweak the sent message to appear within the body of a message you then
forward to a local admin. But, you've still got to "capture" the delivery
first.
In the company I work, they inform that there is a virus that once
in an infected machine, it mails some account the details of the
infected machine (the account, by the way is hacker117(_at_)163(_dot_)com).
Ah, but does the client machine attempt to connect to a _remote_ SMTP
server, or its own? If it connects to the remote SMTP directly, you won't
be able to block this through your own SMTP. Alternatives include
firewalling 163.com (and it's backup MX) from your LAN (which is fraught
with issues), or setting up a bogus DNS zone for 163.com within your DNS
server (adviseable only if you don't provide DNS services to other parties,
unless you set up an Access Control List (ACL) in Bind 9. SysAdmin
Magazine, May 2002 (v11n5) had an article about Bind 9 ACL). Both
workarounds mean that _all_ mail to 163.com will be disposed of.
Anyway, if it does indeed run through _your_ SMTP server, you can make the
following config changes (keeping in mind that any other message sent to
163.com through _your_server_ will be met with a "user unknown" error):
Basically, to the mc file which you use to generate your sendmail.cf, add:
VIRTUSER_DOMAIN_FILE(`/etc/mail/virtual-domains')dnl
In the /etc/mail/virtual-domains file, add (as if you couldn't guess):
163.com
In /etc/mail/virtusertable.txt, add:
hacker117(_at_)163(_dot_)com somelocalaccount
Note that the above syntax (and local account) can be shared among
_multiple_ such dropbox redirections. That local account could simply be a
drop box for the admin to check, or you could further set up an alias for
that account to invoke a specific procmail script:
(sendmail aliases)
somelocalaccount "|/usr/bin/procmail -m
/etc/procmailrcs/somevirus.rc realaddress"
(all one line)
Then (if you set the above alias), in /etc/procmailrcs/somevirus.rc, you
could do the following:
# notification recipe for known virus dropboxes
#
SHELL=/bin/sh
# ALL messages coming through THIS filter are assumed to be virus
# notifications bound for the dropbox. Let's encapsulate them and forward
# them to the real admin (provided to us as $1)
LOOPALERT=virusnotify(_at_)yourdomain(_dot_)tld
:0
* $ ^X-Loop: $LOOPALERT
| ( formail -I "Subject: Notice of infected machine" \
-A "X-Loop: $LOOPALERT" -I "To: $1" \
-I "From: VirusNotify(_at_)youdomain(_dot_)tld") | $SENDMAIL $1
(as per my disclaimer, the above isn't tested)
Once you have all that in place, generate your sendmail.cf from the .mc
file (make a backup of what you have now, in case some bonehead manually
edits the sendmail.cf and you have to go back to it), install that file and
restart sendmail. Send this address a test message. You might initially
try setting a different address (say, your _own_ hotmail account or
something), so if your tests fails, you'll not be sending a heads up to the
virus dropbox.
So, what they want is that I forward, from the mail relays
(sendmail+procmail) all mail to that account to a local mail account, so
they know which machines are actually infected.
Good idea -- provided that the email is passed through your SMTP in the
first place (which an inspection of your mail logs would confirm).
This works like charm for a mail sent to hacker117, but if the mail goes to
any other innocent user of the 163.com domain, it will fail with the
following error:
Are there innocent users of 163.com? All I've ever _received_ from that
domain has been spam (and these days, I just reject everything from that
domain, but that doesn't apply to blocking email from being sent to that
domain). I guess it could just be a chinese hotmail type service, which
makes it useful to spammers and crackers alike.
---
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