[Mimedefang] Help Request: MimeDefang breaks Sendmail
Hello, I'm new to this list and to MimeDefang. After seeing other mailing lists I'm on successfully use MimeDefang, I'm trying to get it running for my mailing lists. I'm having a problem and I hope someone on this list can help me. In short, when I insert MimeDefang into my system, sendmail is suddenly unable to send anything. I've looked in the archives, and found some similar issues in December of last year, but nothing that seems to solve my issue. Allow me to detail the problem... (I'll be happy to provide any additional information) The System: Sun SparcStation 20 SM51 CPU 384 MB RAM Solaris v2.8 with MU #7 and latest Recommended Patches uname -a output: SunOS myhost 5.8 Generic_117000-03 sun4m sparc SUNW,SPARCstation-20 The software: Sendmail v8.12.11 - Installed and functioning (can send and receive) Perl v5.8.4 (Installed and functioning - Majordomo v1.94.5 likes it just fine) [Attempting to install] MimeDefang v2.43 Digest::SHA1 v2.10 IO::stringy v2.109 Mail::Tools v1.62 MIME::Tools v5.411aP2 UNIX::Syslog v0.100 (note: the problem occurred before and after UNIX::Syslog was installed) The problem: MimeDefang appears to start up just fine: # /etc/init.d/mimedefang start Starting mimedefang-multiplexor:[OK] Starting mimedefang:[OK] # Similarly, sendmail starts fine: # /etc/init.d/sendmail start # However, the following appears in /var/log/syslog (and also on the console): Jun 2 18:32:28 myhost mimedefang-multiplexor[18267]: [ID 268819 mail.info] started; minSlaves=2, maxSlaves=10, maxRequests=200, maxIdleTime=120, busyTimeout=300, clientTimeout=10 Jun 2 18:32:28 myhost mimedefang-multiplexor[18267]: [ID 778059 mail.info] Starting slave 0 (pid 18268) (1 running): Bringing slaves up to minSlaves (2) Jun 2 18:32:28 myhost mimedefang-multiplexor[18267]: [ID 731849 mail.info] stats 1086215548.446 StartSlave slave=0 nslaves=1 nbusy=0 reason="Bringing slaves up to minSlaves (2)" Jun 2 18:32:30 myhost mimedefang[18280]: [ID 936676 mail.info] Multiplexor alive - entering main loop Jun 2 18:32:37 myhost mimedefang-multiplexor[18267]: [ID 980602 mail.info] Slave 0 stderr: unix dgram connect: Socket operation on non-socket at /opt/mimedefang/bin/mimedefang.pl line 465 Jun 2 18:32:37 myhost mimedefang-multiplexor[18267]: [ID 980602 mail.info] Slave 0 stderr: no connection to syslog available at /opt/mimedefang/bin/mimedefang.pl line 465 Jun 2 18:32:38 myhost mimedefang-multiplexor[18267]: [ID 260045 mail.error] Reap: Idle slave 0 (pid 18268) exited normally with status 255 (SLAVE DIED UNEXPECTEDLY) Jun 2 18:32:38 myhost mimedefang-multiplexor[18267]: [ID 638987 mail.info] Slave 0 resource usage: req=0, scans=0, user=7.330, sys=0.960, nswap=0, majflt=0, minflt=0, maxrss=0, bi=0, bo=0 Jun 2 18:32:38 myhost mimedefang-multiplexor[18267]: [ID 731849 mail.info] stats 1086215558.032 ReapSlave slave=0 nslaves=0 nbusy=0 Jun 2 18:32:38 myhost mimedefang-multiplexor[18267]: [ID 778059 mail.info] Starting slave 0 (pid 18281) (1 running): Bringing slaves up to minSlaves (2) Jun 2 18:32:38 myhost mimedefang-multiplexor[18267]: [ID 731849 mail.info] stats 1086215558.506 StartSlave slave=0 nslaves=1 nbusy=0 reason="Bringing slaves up to minSlaves (2)" Jun 2 18:32:46 myhost sm-mta[18284]: [ID 702911 mail.info] starting daemon (8.12.11): [EMAIL PROTECTED]:00:00 Jun 2 18:32:47 myhost sm-msp-queue[18287]: [ID 702911 mail.info] starting daemon(8.12.11): [EMAIL PROTECTED]:30:00 Jun 2 18:32:48 myhost mimedefang-multiplexor[18267]: [ID 980602 mail.info] Slave 0 stderr: unix dgram connect: Socket operation on non-socket at /opt/mimedefang/bin/mimedefang.pl line 465 Jun 2 18:32:48 myhost mimedefang-multiplexor[18267]: [ID 980602 mail.info] Slave 0 stderr: no connection to syslog available at /opt/mimedefang/bin/mimedefang.pl line 465 Jun 2 18:32:48 myhost mimedefang-multiplexor[18267]: [ID 260045 mail.error] Reap: Idle slave 0 (pid 18281) exited normally with status 255 (SLAVE DIED UNEXPECTEDLY) Jun 2 18:32:48 myhost mimedefang-multiplexor[18267]: [ID 638987 mail.info] Slave 0 resource usage: req=0, scans=0, user=7.210, sys=1.010, nswap=0, majflt=0, minflt=0, maxrss=0, bi=0, bo=0 Jun 2 18:32:48 myhost mimedefang-multiplexor[18267]: [ID 731849 mail.info] stats 1086215568.321 ReapSlave slave=0 nslaves=0 nbusy=0 Jun 2 18:32:48 myhost mimedefang-multiplexor[18267]: [ID 778059 mail.info] Starting slave 0 (pid 18289) (1 running): Bringing slaves up to minSlaves (2) Jun 2 18:32:48 myhost mimedefang-multiplexor[18267]: [ID 731849 mail.info] stats 1086215568.603 StartSlave slave=0 nslaves=1 nbusy=0 reason="Bringing slaves up to minSlaves (2)" Jun 2 18:32:57 myhost mimedefang-multiplexor[18267]: [ID 980602 mail.info] Slave 0 stderr: unix dgram connect: Socket operation on non-socket at /opt/mimedefang/bin/mimedefang.pl line 465 Jun 2 18:32:57 myhost mimedefang-multiplexor[18267]: [ID 980602 mail.info] Slave 0 stderr: no connection to syslo
RE: [Mimedefang] Help Request: MimeDefang breaks Sendmail
Thanks for the replies so far. Here's some additional information. On Thu, 3 Jun 2004, Rob wrote: > > -Original Message- > >I'm having a problem and I hope someone on this list can > > help me. In > > short, when I insert MimeDefang into my system, sendmail is suddenly > > unable to send anything. I've looked in the archives, and found some > > similar issues in December of last year, but nothing that > > seems to solve my issue. > > Ok, what's in your sendmail.mc file? Looks like you've given the wrong > path for the MD socket. It should have an entry like this: > > INPUT_MAIL_FILTER(`mimedefang', > `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:2m;R:2m') Here is the exact text the relevant part of of my sendmail.mc file: ## # MILTER Section # ## INPUT_MAIL_FILTER(`mimedefang',`S=unix:/var/spool/mimedefang/mimedefang.sock, F=T, T=S:360s;R:360s;E:15m') This is constructed precisely as advised by the MIMEDefang README file for v2.43, in Section 5 of that document. Here are my relevant directories: # pwd /var/spool # ls -la m* drwx-- 2 defang defang 512 Jun 2 06:00 md-quarantine/ drwx-- 9 defang defang 512 Jun 2 18:40 mimedefang/ drwxr-x--- 2 root bin 512 Jun 2 18:39 mqueue/ Also, another person asked what the output from "mimedefang -test" was: # perl mimedefang.pl -test unix dgram connect: Socket operation on non-socket at mimedefang.pl line 465 no connection to syslog available at mimedefang.pl line 465 Dirk ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Help Request: MimeDefang breaks Sendmail
On Thu, 3 Jun 2004, David F. Skoll wrote: > On Thu, 3 Jun 2004, Dirk the Daring wrote: > > > # perl mimedefang.pl -test > > unix dgram connect: Socket operation on non-socket at mimedefang.pl line 465 > > no connection to syslog available at mimedefang.pl line 465 > > Make sure that on your system, syslogd is started so that it listens on > a UDP port. In other words, do *not* use the "-t" option when syslogd > starts. No indicaton that the -t option is in use. I did not alter /etc/init.d/syslog, so its whatever Solaris 2.8 defaults to. # ps -ef | grep syslogd root 176 1 0 May 08 ?0:13 /usr/sbin/syslogd Dirk ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Help Request: MimeDefang breaks Sendmail
On Thu, 3 Jun 2004, Alex S Moore wrote: > On Thu, 3 Jun 2004 21:21:33 -0400 (EDT) > Dirk the Daring <[EMAIL PROTECTED]> wrote: > > > On Thu, 3 Jun 2004, David F. Skoll wrote: > > > >No indicaton that the -t option is in use. I did not alter > > /etc/init.d/syslog, so its whatever Solaris 2.8 defaults to. > > >From man page: > -TEnable the syslogd UDP port to turn on logging of > remote messages. This is the default behavior. See > FILES. Hmmm, that's not the Solaris v2.8 man page: -tDisable the syslogd UPD port to turn off logging of remote messages. Altho I think the end result is the same in any case. Dirk ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Help Request: MimeDefang breaks Sendmail
On Thu, 3 Jun 2004, David F. Skoll wrote: > On Thu, 3 Jun 2004, Dirk the Daring wrote: > > >No indicaton that the -t option is in use. > > Ignore my advice; it was wrong. > > Did you install Unix::Syslog before building MIMEDefang? Did MIMEDefang's > ./configure script appear to pick it up? No, I installed UNIX::Syslog after I built MIMEdefang. It wasn't until I saw the syslog-related error messages and looked at the archives of this mailing list that I decided to install UNIX::Syslog. Should I re-build MIMEDefang (perform a "make clean" and then re-run configure)? Dirk ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Help Request: MimeDefang breaks Sendmail
On Thu, 3 Jun 2004, Alex S Moore wrote: > >Hmmm, that's not the Solaris v2.8 man page: > > > > -tDisable the syslogd UPD port to turn off logging of > >remote messages. > > > > I think that you have it now, but my post was from Solaris 8. Note > the difference in capitalization. I noticed the capitalization difference first time around. Sol8 on what platform? I'm on SPARC and my man page for syslogd does not have a "-T", only a "-t". Dirk ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Help Request: MimeDefang breaks Sendmail
On Thu, 3 Jun 2004, David F. Skoll wrote: > >Should I re-build MIMEDefang (perform a "make clean" and then re-run > > configure)? > > Yes; then it should work. OK, I did that, and along the way fixed a problem where the md-quarantine directory was incorrectly speced. I had high hopes that the problem was fixed, but this is what happened: # pwd /etc/init.d # ./mimedefang start [syslog] Jun 4 00:09:25 myhost mimedefang-multiplexor[22381]: [ID 268819 mail.info] started; minSlaves=2, maxSlaves=10, maxRequests=200, maxIdleTime=120, busyTimeout=300, clientTimeout=10 Jun 4 00:09:25 myhost mimedefang-multiplexor[22381]: [ID 778059 mail.info] Starting slave 0 (pid 22384) (1 running): Bringing slaves up to minSlaves (2) Jun 4 00:09:25 myhost mimedefang-multiplexor[22381]: [ID 731849 mail.info] stats 1086322165.986 StartSlave slave=0 nslaves=1 nbusy=0 reason="Bringing slaves up to minSlaves (2)" Jun 4 00:09:27 myhost mimedefang[22394]: [ID 936676 mail.info] Multiplexor alive - entering main loop Jun 4 00:09:34 myhost mimedefang-multiplexor[22381]: [ID 980602 mail.info] Slave 0 stderr: unix dgram connect: Socket operation on non-socket at /opt/mimedefang/bin/mimedefang.pl line 465 Jun 4 00:09:34 myhost mimedefang-multiplexor[22381]: [ID 980602 mail.info] Slave 0 stderr: no connection to syslog available at /opt/mimedefang/bin/mimedefang.pl line 465 Jun 4 00:09:35 myhost mimedefang-multiplexor[22381]: [ID 260045 mail.error] Reap: Idle slave 0 (pid 22384) exited normally with status 255 (SLAVE DIED UNEXPECTEDLY) Jun 4 00:09:35 myhost mimedefang-multiplexor[22381]: [ID 638987 mail.info] Slave 0 resource usage: req=0, scans=0, user=7.460, sys=0.940, nswap=0, majflt=0, minflt=0, maxrss=0, bi=0, bo=0 Jun 4 00:09:35 myhost mimedefang-multiplexor[22381]: [ID 731849 mail.info] stats 1086322175.064 ReapSlave slave=0 nslaves=0 nbusy=0 Jun 4 00:09:36 myhost mimedefang-multiplexor[22381]: [ID 778059 mail.info] Starting slave 0 (pid 22395) (1 running): Bringing slaves up to minSlaves (2) Jun 4 00:09:36 myhost mimedefang-multiplexor[22381]: [ID 731849 mail.info] stats 1086322176.045 StartSlave slave=0 nslaves=1 nbusy=0 reason="Bringing slaves up to minSlaves (2)" Jun 4 00:09:44 myhost mimedefang-multiplexor[22381]: [ID 980602 mail.info] Slave 0 stderr: unix dgram connect: Socket operation on non-socket at /opt/mimedefang/bin/mimedefang.pl line 465 Jun 4 00:09:44 myhost mimedefang-multiplexor[22381]: [ID 980602 mail.info] Slave 0 stderr: no connection to syslog available at /opt/mimedefang/bin/mimedefang.pl line 465 Jun 4 00:09:44 myhost mimedefang-multiplexor[22381]: [ID 260045 mail.error] Reap: Idle slave 0 (pid 22395) exited normally with status 255 (SLAVE DIED UNEXPECTEDLY) [SNIP] # ./sendmail start [syslog] Jun 4 00:10:57 myhost sm-mta[22408]: [ID 702911 mail.info] starting daemon (8.12.11): [EMAIL PROTECTED]:00:00 Jun 4 00:10:58 myhost sm-msp-queue[22411]: [ID 702911 mail.info] starting daemon (8.12.11): [EMAIL PROTECTED]:30:00 [SNIP] Using PINE, I now tried to send an E-Mail out to an external address [syslog] Jun 4 00:11:14 myhost mimedefang[22394]: [ID 893429 mail.debug] Entering mfconnect (line 363) Jun 4 00:11:14 myhost mimedefang[22394]: [ID 893429 mail.debug] Entering mfclose (line 1472) Jun 4 00:11:14 myhost mimedefang[22394]: [ID 893429 mail.debug] Entering cleanup (line 1522) Jun 4 00:11:14 myhost mimedefang[22394]: [ID 521097 mail.debug] Exiting cleanup (line 1524) ret=SMFIS_CONTINUE Jun 4 00:11:14 myhost mimedefang[22394]: [ID 521097 mail.debug] Exiting mfclose (line 1488) ret=SMFIS_CONTINUE Jun 4 00:11:14 myhost mimedefang[22394]: [ID 521097 mail.debug] Exiting mfconnect (line 502) ret=SMFIS_CONTINUE Jun 4 00:11:14 myhost mimedefang[22394]: [ID 893429 mail.debug] Entering envfrom (line 556) Jun 4 00:11:14 myhost mimedefang[22394]: [ID 521097 mail.debug] Exiting envfrom (line 763) ret=SMFIS_CONTINUE Jun 4 00:11:14 myhost mimedefang[22394]: [ID 893429 mail.debug] Entering rcptto (line 785) Jun 4 00:11:14 myhost mimedefang[22394]: [ID 521097 mail.debug] Exiting rcptto (line 864) ret=SMFIS_CONTINUE or SMFIS_ACCEPT Jun 4 00:11:15 myhost sm-mta[22414]: [ID 801593 mail.info] i544BDtg022414: from=<[EMAIL PROTECTED]>, size=251, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=ESMTP, daemon=MTA, relay=myhost.domain.com [xxx.yyy.zzz.aaa] Jun 4 00:11:15 myhost mimedefang[22394]: [ID 893429 mail.debug] Entering header (line 886) Jun 4 00:11:15 myhost mimedefang[22394]: [ID 521097 mail.debug] Exiting header (line 977) ret=SMFIS_CONTINUE Jun 4 00:11:15 myhost mimedefang[22394]: [ID 893429 mail.debug] Entering header (line 886) Jun 4 00:11:15 myhost mimedefang[22394]: [ID 521097 mail.debug] Exiting header (line 977) ret=SMFIS_CONTINUE Jun 4 00:11:15 myhost mimedefang[22394]: [ID 893429 mail.debug] Entering header (line 886) Jun 4 00:11:15 myhost mimedefang[22394]: [ID 521097 mail.debug] Exiting header (line 977) ret=SMFIS_CONTINUE Jun 4 00
[Mimedefang] From-scratch install of SA and MD
Does anyone have a website or other document that lays out a from-scratch install of SA (v3) and MIMEDefang on a Solaris v8 system with sendmail v8.12.11 and ProcMail v3.22 (global install)? I have a new server I'm setting up as a mail relay, and since its new, with no user accounts, I have the run of the system, so I'd prefer to get it right the first time. Dirk ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] When does SA v3.0 go "gold"?
Does anyone know when SA v3.0 is going to go into final release? I'm starting to add MD and SA to my existing sendmail v8.12.11 system and if SA is going gold soon, then I'll wait for it. Dirk [EMAIL PROTECTED] The PsiCorps is your friend. Trust the Corps. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Sendmail config (slightly OT)
Hello, MIMEdefang gurus. I'm setting up a mail relay to which I'll be
adding MIMEdefang, SpamAssassin and ClamAV. However, I'm running into
some problems with the sendmail config, and I hope someone on here can
help me iron this out, so I can progress on to the other installs and
get MD and SA running. Obviously, I want to have sendmail 100%
configured before progressing on.
Documentation at hand includes the Bat Book (_Sendmail_3rd_edition_),
Hunt's _Sendmail_Cookbook_, and the online sendmail docs. I've consulted
the list Archives and been unable to find the answers I need.
I'm running sendmail v8.12.11 under Solaris v8 on a SparcServer 20,
2x 200 MHz HyperSparc CPUs, 512 MB RAM. sendmail has been compiled with
support for Berkeley DB 4.1.25 as shown in its debug output:
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NDBM NETINET NETINET6 NETUNIX NEWDB NIS
NISPLUS PIPELINING SCANF USERDB XDEBUG
Let's call this Host IO (as in I/O).
The main purpose IO has in life is to be a mail relay for multiple
Domains that I host - there is NO need for local delivery (i.e. there
are no user accounts on IO). An E-Mail for a given Domain can go to any
one of several interior servers (let's call them A, B and C). So E-Mail
for [EMAIL PROTECTED] might go to Server A, while E-Mail for
[EMAIL PROTECTED] might go to Server B. However, all E-Mail to any
address @Domain2.com goes to Server C.
Servers A, B and C all relay OUT thru IO (that is, they are all
configured to regard IO as their "Smart" mailhost). Only IO sends E-Mail
out from my network.
IO is configured to use RBLs with the FEATURE(`dnsbl') and
FEATURE(`enhdnsbl') entries in sendmail.cf. It does this successfully.
I wish to employ the sendmail access database (/etc/mail/access) to
selectively blacklist both senders and recipients. To this end, I have
added FEATURE(blacklist_recipients). Since I want a legit sender who has
been BLed to be able to reach me to request whitelisting, I also employ
FEATURE(`delay_checks') so I can put an entry in the access db to permit
otherwise blocked mail to reach one specific address. Finally, entries
in the access db allow Servers A, B and C to bypass RBL checks (using
the "connect:" keyword on the LHS). So the access db is important.
So far, so good.
The problem arises in how to properly route E-Mail. I can't use
RELAY_DOMAINS (Class {R}), as that bypasses the access db for the listed
Domains. If I use RELAY_DOMAINS, it becomes impossible to blacklist
recipients.
I can use FEATURE(`virtusertable') to translate addresses to the
proper host, with entries like this:
@Domain2.com[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
However, as I understand it, I still need mailertable
(/etc/mail/mailertable) to route the E-Mail to the proper host, with
entries like this:
serverA.mydomain.comsmtp:[servera.mydomain.com]
serverB.mydomain.comsmtp:[serverb.mydomain.com]
serverC.mydomain.comsmtp:[serverc.mydomain.com]
The problem being that I cannot use VIRTUSER_DOMAIN_FILE because
those entries get added to Class {R} and again break the access db.
As a final complication, I also can't use /etc/mail/local-host-names
(Class {w}), because that breaks mailertable (i.e. mailertable is not
consulted for Domains in Class {w}). Besides, as I noted, there is no
local delivery at all.
So, my questions to the sendmail gurus in this forum are:
1) Is there any definitive listing of what tables are
consulted in what order and when during the
sendmail mail-handling process?
2) How can I host multiple Domains on a relay without
being forced to add the Domains to /etc/access
(thus bypassing some checks), or adding them
to Class {R} (thus bypassing practically all
checks aside from RBLs), or adding them
to Class {w} (thus breaking mailertable); while
still retaining the ability to selectively route
E-Mail and selectively blacklist recipients and/or
senders? Right now, I've added the Domains to
/etc/mail/access with the RELAY action.
3) Does anyone know, for sure, how sendmail looks up
entries in its tables? That is, does it stop once
it find the first matching key (which is the way
I'd do it), or does it have some sort of resolution
mechanism for when multiple keys in, say,
/etc/mail/access, match? I can't find a definitive
answer to this question in any online or printed docs.
4) I'd like to blacklist certain TO: addresses for ALL
Domains I host, without having to make an entry
[Mimedefang] Re: Sendmail config (slightly OT) (Sven Willenberger)
On Tue, 11 Jan 2005 Sven wrote: >From how our system works, I can infer that delay_checks causes sendmail >to do a lookup in access first. A REJECT will do that .. an OK will >allow sendmail to continue processing the mail. In this case, unless a >user is specifically listed in the access table, mail is blocked with a >standard 550 ERROR: Mailbox Disabled for this recipient. Sven, Thanks for the reply. Specifying each user/address allowed to go thru is a cure that, for me, would be as bad or worse than the disease. I appreciate you taking the time to respond, tho. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Sendmail config (slightly OT) (Ashley M. Kirchner)
On Tue, 11 Jan 2005 Ashley M. Kirchner wrote: >Dirk the Daring wrote: > >> 2) How can I host multiple Domains on a relay without >> being forced to add the Domains to /etc/access >> >Yes. I have one master incoming MX which then forwards to the final >servers: Thanks for replying, Ashley. Yep, I do that too. All the Domains have MX records pointing to this one relay server. >/etc/mail/mailertable > pcraft.com esmtp:spool.pcraft.com > yeehaw.net esmtp:swiri.yeehaw.net OK, so what do you do if SOME of the addresses @pcraft.com need to go to spool.pcraft.com and the rest need to go to otherserver.pcraft.com ? >/etc/mail/local-host-names >/etc/mail/generics-domains > these files have ONE entry in them, and that's the MX's FQDN Hmmminteresting. Hadn't thot of that. >incoming e-mail gets denied or accepted based on each individual >(recipient) server's virtusertable. This way I don't have to maintain >one master file for everyone's server. They can do that themselves. Well, I am *it* for the mail guru, so I might as well have one central place. >/etc/mail/relay-domains > Contains every single domain hosted across our entire network The problem here is that I lose the ability to blacklist by recipient in /etc/mail/access I think I've resigned myself to having a rather complex access db. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Sendmail config (slightly OT) (Jan Pieter Cornet)
On Tue, 11 Jan 2005 Jan Pieter Cornet wrote:
>On Tue, Jan 11, 2005 at 10:59:42AM -0500, Dirk the Daring wrote:
>>The main purpose IO has in life is to be a mail relay for multiple
>> Domains that I host - there is NO need for local delivery (i.e. there
>>Servers A, B and C all relay OUT thru IO (that is, they are all
>> configured to regard IO as their "Smart" mailhost). Only IO sends E-Mail
>> out from my network.
>
>Note that it saves hassles and confusion if you split the I and O
>functionality here, ie. have one dedicated incoming MX server, and
>one dedicated outgoing smarthost.
>You can combine them, of course, this is just what I'd recommend.
>Hardware cost should be peanuts compared to the ease of maintenance
You left the issues of supplying UPS-protected power, and cooling
to deal with the heat dissipation, out of your cost calculations.
Really, this is a small-time operation running on a shoestring that's as
much wishful thinking as anything else. A single machine does fine.
>>IO is configured to use RBLs with the FEATURE(`dnsbl') and
>> FEATURE(`enhdnsbl') entries in sendmail.cf. It does this successfully.
>
>You could move that to mimedefang, with some added flexibility (eg,
>we do that to allow per-recipient selectable DNSbls). But it works well
Global RBLs are fine, and the sooner I drop the spammer's connection,
the sooner that resource is freed for legit E-Mail. No one on my system
is going to be interested in twiddling with their RBLs - that's what
they've got me for.
>>The problem arises in how to properly route E-Mail. I can't use
>> RELAY_DOMAINS (Class {R}), as that bypasses the access db for the listed
>> Domains. If I use RELAY_DOMAINS, it becomes impossible to blacklist
>
>Class {R} is evil. And a downright security risk if you do not control
>the DNS of one of the domains in it. Do not use it.
Agreed - I have no desire to use Class {R}, and have already
eliminated it from my configuration. I need to be able to blacklist
based on recipients.
>>I can use FEATURE(`virtusertable') to translate addresses to the
>>The problem being that I cannot use VIRTUSER_DOMAIN_FILE because
>> those entries get added to Class {R} and again break the access db.
>
>You do not have to use VIRTUSER_DOMAIN_FILE. That is just a macro
>that fills class {VirtHost}. You simply put all domains that you
>wish to relay for in /etc/mail/virtuser.domains, and put this in your
>sendmail.mc:
>
>LOCAL_CONFIG
>F{VirtHost}/etc/mail/virtuser.domains
I'm unclear on how that is different. Won't the contents of Class
{VirtHost} get added to Class {R}? Or is this a way to bypass that?
Since this is a pure relay, with NO local accounts, should I even use
Class {VirtHost}?
>>As a final complication, I also can't use /etc/mail/local-host-names
>> (Class {w}), because that breaks mailertable (i.e. mailertable is not
>> consulted for Domains in Class {w}). Besides, as I noted, there is no
>> local delivery at all.
>
>You don't want Class {w}, that will make [EMAIL PROTECTED] equivalent
>to [EMAIL PROTECTED], which is not necessarily what you want.
I tend to agree, but then how do accomplish the things I want to do
such as having an /etc/mail/access entry like
to:someaddr@REJECT
and having that applied to ALL Domains I host? So that
SMTP RCPT TO: [EMAIL PROTECTED] results in a REJECT, as does SMTP
RCPT TO: [EMAIL PROTECTED]
>> 1) Is there any definitive listing of what tables are
>> consulted in what order and when during the
>> sendmail mail-handling process?
>
>Well, cf.README (or the README in the cf/ subdirectory) does
>something, but it doesn't really do it very well. Look for the
>section marked
I've read that, back-to-front, and its basically a rehash of other
docs in the Bat Book and also online at www.sendmail.org/features
Someone else suggested using the debug commands.
>Or, easier and better configurable, do it within MIMEDefang:
>
>sub filter_end {
>if ( grep { /foulword|badlanguage|deity/ } @Recipients ) {
> return action_bounce("No swearing");
>}
>}
>
>This has the side-effect of blocking messages completely that
>are even Cc-ed to those with the illegal usernames. Which can be
>construed as a feature.
That's probably going to be my long-term route. I was just trying to
get some basic blocking working before I started on implementing MD and
SA. And yes, blocking the addresses in CC is fine by me.
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Sendmail config (slightly OT) (Ashley M. Kirchner)
On Wed, 12 Jan 2005 Ashley M. Kirchner wrote:
>> OK, so what do you do if SOME of the addresses @pcraft.com need to go
>>to spool.pcraft.com and the rest need to go to otherserver.pcraft.com ?
>>
>I don't have that setup. All domains reside on one (respective)
>server (on other words, I don't have any domains split over multiple
Thanks for continuing on this thread.
Unfortunately, I do have that setup. Else this would be simpler - use
mailertable and be done with it. But instead I need to use
virtusertable AND mailertable.
>>> /etc/mail/relay-domains
>>> Contains every single domain hosted across our entire network
>>>
>> The problem here is that I lose the ability to blacklist by recipient
>>in /etc/mail/access
>>
>No you don't. I have individual recipient blocked in my
>/etc/mail/access file and it works just fine. access gets read after
>relay-domains.
That's not what I'm reading, altho you can tell me if I am
misinterpreting anything. Note that I am using FEATURE(`delay_checks')
which causes check_rcpt to be called before check_mail and
check_relay, as described on the Sendmail website at
http://www.sendmail.org/m4/anti_spam.html
Anyway, in the Bat Book, Chap 7.1.3 (page 292), its says that
check_rcpt rejects empty RCPT: values, then checks to see if the
envelope-recipient address is one that is allowed to be relayed.
Presumably, this is where Class {R} is consulted, so if I use Class {R},
this will permit relaying. The access database has not been checked at
this point.
I'm unclear as to, if relaying is permitted by the envelope-recipient
address check, if the access db is consulted next, but let's suppose
that it is. According to the bat book, check_rcpt looks up the HOST to
see if relaying is allowed, and then finally looks up the
envelope-recipient.
Again, I'm not clear as to the order of precedence: for example, if
the access db host check results in a REJECT but the envelope-recipient
address check in the same place results in RELAY, what is the result? Or
does check_rcpt return on the first match, meaning that if the second
check (envelope-recipient address allowed to be relayed?) results in a
RELAY, there are no futher checks? Also, if any result $# is returned by
check_rcpt, check_relay isn't called at all.
Finally, during my testing, I was unable to get access db entries to
be effective while I had defined Class {R}. And Jan Pieter Cornet (who
also replied in this thread) regards Class {R} as "evil". :-)
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Sendmail config (slightly OT) (Jan Pieter Cornet)
On Wed, 12 Jan 2005 Jan Pieter Cornet) wrote:
>On Wed, Jan 12, 2005 at 04:07:59PM -0500, Dirk the Daring wrote:
>> Global RBLs are fine, and the sooner I drop the spammer's connection,
>
>Not everything that's on an RBL is necessarily spam :) You might want
>to protect "[EMAIL PROTECTED]" with l2.spews, but not [EMAIL PROTECTED]
>But it's OK to start with central blacklists, and step up to doing it
>in MD later of course, if or when it becomes necessary...
That's why I employ FEATURE(`delay_checks') as I noted in another
message. This allows E-Mail from "legit" RBLed sites to reach me for
whitelisting.
And *I* am the "ceo" :-)
>> >LOCAL_CONFIG
>> >F{VirtHost}/etc/mail/virtuser.domains
>>
>>I'm unclear on how that is different. Won't the contents of Class
>> {VirtHost} get added to Class {R}? Or is this a way to bypass that?
>> Since this is a pure relay, with NO local accounts, should I even use
>> Class {VirtHost}?
>
>It's different precisely because it DOES NOT add class {VirtHost} to
>class {R}. The default VIRTUSER_DOMAIN_FILE macro will do that for you,
>in a misguided attempt to be user-friendly, but you don't have to use
>that macro.
OK, I understand the difference - the m4 macro wants "helpful" and
does both things, but if I manually set the value of Class {VirtHost} it
doesn't propogate to Class {R}. That makes sense.
>>I tend to agree, but then how do accomplish the things I want to do
>> such as having an /etc/mail/access entry like
>> to:someaddr@REJECT
>>and having that applied to ALL Domains I host? So that
>> SMTP RCPT TO: [EMAIL PROTECTED] results in a REJECT, as does SMTP
>> RCPT TO: [EMAIL PROTECTED]
>
>You can't. You can't have it both ways. Once use put the domains in
>class {w}, recipients will ALWAYS be treated the same, you cannot split
OK, Class {w} is out. This is the problem I noted in my last E-Mail
to the list in reply to Ashley's message, and it seems to be confirmed
on the Sendmail website, at http://www.sendmail.org/m4/anti_spam.html,
down near the bottom where FEATURE(`delay_checks') is discussed, where
it says that the implied "localdomain" following an access db entry ending
in an @ is checked against Class {w}.
So if I don't use Class {w}, and it seems I should not, I'm back to
the "stone knives and bear skins" level of management (at least until I
get MD running).
>You might consider "blocking some list of aliases in every domain"
>is not basic filtering anymore, and delay that until you have MD
>running :)
It still something I need to have, and given that getting MD running
is fairly high on the List Of Things To Do, I can stomach the manual
blocks in /etc/mail/access until MD is operational.
>Oh... one more thing. From your questions I take it that your "IO"
>host will simply accept every address on all domains that you host,
>and then bounce the stuff that's rejected on the target machines.
>This is generally considered a bad idea these days. We (unfortunately)
>have this setup for some clients in a batched-SMTP setup, and I regularly
>see spammers drop thousands upon thousands of dictionary spam on those
Yeah, that is my v1.0 implementation.
>Fortunately, MD to the rescue again. MD has a function
>md_check_against_smtp_server(), that allows you to check a recipient
>against a remote SMTP server, while the recipient is being offered to us.
>You will very probably want to use it. And it's dead easy because your
>sendmail setup will already provide MIMEDefang with the correct remote
>host to check against (in $rcpt_host, given that $rcpt_mailer =~ /smtp/).
Yep. Another reason that getting MD running is so high on the List Of
Things To Do. Main purpose of this thread is for me to get sendmail
operating as best it can before I start working on MD. I want to have
sendmail all tweaked and configured, then I'll start implementing MD and
SA and CLAM. The md_check_against_smtp_server() function sounds like its
a feature I'll be using.
Thanks again for your input.
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Group for security
I'm installing MD v2.51 on Solaris v8, with Perl v5.8.5 and sendmail v8.12.11. I have created a user account for mimedefang to run as, and also an associated group. The group is the mimedefang user account primary group. I've also added it as a secondary group for the non-root administration user account. I've installed MD to /opt/mimedefang It is unwise to have the group ownership of that directory and its sub-directory structures (including bin/, man/ and etc/) be the mimedefang group? Is it unwise to have that mimedefang group have write permissions to, say, the config file in etc/ ? Does the group under which mimedefang runs matter? Or only the UID? The mimedefang-related directories under /var/spool are owned by the mimedefang user, but I wanted to add the associated group so the admin user account can look in the spool and quarantine directories. Any issues with that? Basically, I'm trying to minimize the things I have to do as root. This specific machine does not host user shell accounts. It is primarily a mail relay, and its been thru extensive hardening. Practically every thing that can be turned off or locked out has been done. Just need a sanity check here. Dirk ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Stripping Selected Headers
Hello, I would like to get some help on a specific task in MD. I've searched the mailing list archives, and I've not found what I want to do in there. I'm running MIMEDefang v2.51 in a sendmail v8.13.4 environment on Novell SUSE Linux Enterprise Server v9 (SLES 9) platform. I think I have MIMEDefang working properly, and now I want to use it to do something (that seems) fairly simple. Currently, the filter that was included with MD is what's running. When an E-Mail arrives, I want to strip any header that starts out "Received: from" For example: Received: from www.roaringpenguin.com (localhost.localdomain [127.0.0.1]) by www.roaringpenguin.com (8.13.4/8.13.1) with ESMTP id j4UG03kE012592; I'd like to completely eliminate any such headers in the E-Mail that this system receives. After that, I want to add a header: X-Comment: Header Strip I don't need to futz with the E-Mail any more. At this point, I want to do this stripping universally (for all E-Mail the server handles, regardless of origin - later I'll want to getting into doing it on a case-by-case basis). Any assistance would be appreciated. Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] RE: Stripping Selected Headers
On Tue, 31 May 2005 [EMAIL PROTECTED] wrote: >From: "David F. Skoll" <[EMAIL PROTECTED]> > >>When an E-Mail arrives, I want to strip any header that starts out >> "Received: from" > >No, you don't. Trust me. I understand your concerns. Please let me explain why I actually do want to do this. >1) It violates RFC 2821. Yes, it does, and this is acceptable to us in this particular context. E-Mail passing thru this server will hit another sendmail server before it reaches the 'Net, so RFC 2821 will be observed, more or less (that is, by the time the E-Mail reaches a system somewhere else on the 'Net, it will have had at least 2 "Received from" headers added). >2) It can make detection of mail loops impossible. The system doing this is a relay, and does not talk to the 'Net directly (either sending or receiving). It talks to a small selection (<20) of internal (e.g. inside our network) hosts, and an even smaller selection (<5) of external (at our ISP) hosts. It also has no local user accounts. I'm not worried about mail loops because of mailertable and [ ] around the RHS entries. Everything is spelled out for sendmail, it does not rely on MX records - so the danger of loops is minimal. >3) If you think it adds security: it doesn't. In our peculiar case, it does. And, perhaps more importantly, the "Security" people and PHBs *think* it does. I'd really like to use MD for this, because if I don't Kernigan only knows what they'll have me do instead - bending RFC 2821 will be the least of my worries. >What you want to do is possible with MIMEDefang. But I won't tell you how, >and I'd ask others on this list not to either. :-) It's all in the man page >if you really want to do it. I appreciate that you do not want the information widely-disseminated. I'd be fine with private replies that don't go to the mailing list. I understand that the info is in the man page, but I'm under a lot of time pressure and my Perl is a little rusty. I could figger it out, but it'd take me more time than I have. Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] [off-topic] Stripping Headers - answers to questions
>From: Rob MacGregor <[EMAIL PROTECTED]> > >On 31/05/05, Dirk the Daring <[EMAIL PROTECTED]> wrote: >>Hello, I would like to get some help on a specific task in MD. I've >> searched the mailing list archives, and I've not found what I want to do >> in there. > >You may want to look into the actual value of "security through >obscurity". I suspect you'll find it doesn't buy you anything like >what you're thinking it does. Yes and no. See my other response on this topic below. >From: "Kevin A. McGrail" <[EMAIL PROTECTED]> > >However, more to the point, Dirk: What is your end-goal in modifying the >headers because it's a setup for a nightmare in debugging a lost email. The >strength of email and sendmail especially is the culpability and tracking. >You will be removing a cornerstone of that culpability. True, but as I mentioned in an earlier E-Mail, this system does not talk directly to the 'Net, is very restricted in the hosts to which it does talk (in practical terms, less than a dozen total), and the necessary tracking can be handled via logging. >From: Rob MacGregor <[EMAIL PROTECTED]> > >I agree - if you're using obscurity as part as you're overall >strategy, and you've really thought it through and identified what >it's buying you (as hopefully you've done for all your other security >measures) then yes, it's valid. Heck, I use it as part of some >solutions myself - but only part. That is the situation here. The decision to eliminate certain headers is just one part of an overall security plan. >Could you post the reasons they're pushing? That information would still be >useful to all the mail admins here and if it's indeed bogus we can work >towards white papers that address the issues. It might even be good fodder >for the wiki. Basically, they want to eliminate any mentions of hostnames, IP addresses, and MTA softwares/versions for internal hosts. To that end, this central relay is being established. All internal hosts will relay out thru it (and the central relay itself utilizes another relay at the ISP), and it will also be the mail entry point. Eliminating the headers identifying internal hosts is a bit like, as someone else suggested, hiding the building blueprints for the gold repository at Fort Knox. Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Adding clamd *after* MD install
I've looked at the MD docs and Googled, but I'm not finding a good solution for this situation. Hopefully, someone else has done this. Running configuration: Novell SUSE Linux Enterprise Server 9 Sendmail v8.13.4 MIMEDefang v2.51 For various reasons, I was not able to build and install ClamAV until MD was already up and running. ClamAV v0.85 has been built and installed. I've edited clamd.conf to use the MD socket directory and to run clamd as the "defang" user (with AllowSupplementaryGroups enabled and the "defang" user added to the ClamAV group in /etc/groups). clamd starts fine. If I use "perl mimedefang.pl -features", ClamD shows as disabled. How do I get MD to recognize and use clamd? Do I have to rebuild and reinstall MIMEDefang? Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Start order for sendmail, MD and Clam
Is there a particular order in which I should start sendmail, MD and Clam? That is, are there any dependencies, or reason that one should be running before the other (seems that sendmail will gripe about a missing socket if MD is not running, so I start MD first, but what about Clam?) Sendmail v8.13.4 MIMEDefang v2.51 Clam v0.85 Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: [Resolved}: Adding clamd *after* install
Hello, all. I asked:
>Date: Mon, 6 Jun 2005 13:24:41 -0400 (EDT)
>
>Running configuration:
> Novell SUSE Linux Enterprise Server 9
> Sendmail v8.13.4
> MIMEDefang v2.51
>
> For various reasons, I was not able to build and install ClamAV
>until MD was already up and running. ClamAV v0.85 has been built and
>installed. I've edited clamd.conf to use the MD socket directory and
>
>
> If I use "perl mimedefang.pl -features", ClamD shows as disabled. How
>do I get MD to recognize and use clamd? Do I have to rebuild and
>reinstall MIMEDefang?
Thanks to everyone who replied. I ended up adding some lines to
mimedefang-filter as suggested by the replies below. I felt this was a
better idea than hacking the mimedefang.pl script - that if, add the
function via a configuration file change as opposed to altering the code
itself (altho I'm sure changing mimedefang.pl would work well).
>--
>From: Kenneth Porter <[EMAIL PROTECTED]>
>
>I have this near the top of my mimedefang-filter:
>
># manually override compile-time features, clamd is installed
>$Features{'Virus:CLAMD'} = 1;
>$ClamdSock = "/var/run/clamav/clamd.sock";
>--
Dirk
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] [Resolved] Start order for sendmail, MD and Clam
>From: alan premselaar <[EMAIL PROTECTED]> > >>Is there a particular order in which I should start sendmail, MD and >> Clam? That is, are there any dependencies, or reason that one should be >> running before the other (seems that sendmail will gripe about a missing >> socket if MD is not running, so I start MD first, but what about Clam?) > >CLAMD >MIMEDefang >Sendmail Thanks, Alan. That's what I'm looking for. I'm writing my start scripts to check for dependencies accordingly (Clam starts first, doesn't check for MD or sendmail; MD starts next, checks for clam before starting; sendmail starts last, checks for MD before starting). The "stop" scripts are a little more problematic. I've decided that for stopping, say, clam, it should check for MD being run, generate a warning if MD is up, but still proceed with the stop even if MD is running. Same for MD with relation to sendmail. Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Timeouts when filter-sender is employed
Background:
sendmail v8.13.4 on SPARC Solaris 8/117350-25
MIMEDefang v2.52
sendmail alone runs fine and delivers E-Mail
If I use MIMEDefang without the -s parameter, everything continues to
work
If I add the -s to the invocation of MIMEDefang, then for all E-Mail
handled by the MTA, I see error messages like this:
Jun 15 17:16:34 host sm-mta[23303]: [ID 801593 mail.info]
j5FLESWV023303: Milter: data, reject=451 4.3.2 Please try again later
In mimedefang-filter, I have:
##
sub filter_sender {
my($sender, $hostip, $hostname, $helo) = @_;
# Can't be "psicorps.org" unless it's one of our IP's.
if ($helo =~ /(^|\.)psicorps\.org$/i) {
if ($hostip ne "127.0.0.1" and $hostip ne "209.170.141.XXX" and
$hostip ne "209.170.141.XXX" and $hostip ne "209.170.141.103") and
$hostip ne "209.170.141.XXX" and $hostip ne "209.170.141.XXX") {
syslog('info', "MIMEDefang rejected a connection where Host $hostip
said HELO $helo");
return(0, "Connection Rejected: $hostip is not authorized to use
$helo for identification");
}
}
return (1, "OK");
}
##
The rest of mimedefang-filter is pretty much stock as it shipped with
MD.
I do have "delay_checks" enabled in sendmail.mc, if that makes any
difference.
All internal hosts are listed in the access map with:
GreetPause:INTERNAL.HOST.IP.ADDR0
Connect:INTERNAL.HOST.IP.ADDR RELAY
The MILTER line in sendmail.mc reads:
INPUT_MAIL_FILTER(`mimedefang',
`S=unix:/var/spool/defang/MIMEDefang/mimedefang.sock, F=T,
T=C:30m;S:30m;R:30m;E:30m')
MIMEDefang and the Multiplexor are invoked like this (broken up for
readability):
/opt/mimedefang/bin/mimedefang-multiplexor
-U defang -i 60 -l -T -I 200 -S local4 -E -L 60 -Y Plex
-s /var/spool/defang/MIMEDefang/mimedefang-multiplexor.sock
-p /var/run/mimedefang-multiplexor.pid
/opt/mimedefang/bin/mimedefang -U defang -b 200
-s -P /var/run/mimedefang.pid -T -S local3
-p /var/spool/defang/MIMEDefang/mimedefang.sock
-m /var/spool/defang/MIMEDefang/mimedefang-multiplexor.sock
/var/spool/defang and the needed subdirs exist, owner defang:defang,
mode either 700 or 750. These are on a RAM disk, created with:
swap- /var/spool/defang tmpfs - yes size=128m,nosuid
I can't fathom why adding filter_sender starts giving me timeouts.
Any help would be appreciated.
Dirk
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Timeouts when filter-sender is employed (various)
>From: alan premselaar <[EMAIL PROTECTED]>
>
>Dirk the Daring wrote:
>> if ($helo =~ /(^|\.)psicorps\.org$/i) {
>> if ($hostip ne "127.0.0.1" and $hostip ne "209.170.141.XXX" and
>> $hostip ne "209.170.141.XXX" and $hostip ne "209.170.141.103")
>> and
>
> the ) before the and in the above line is probably
> what's causing your problem. (non-matching parens)
Thank you, Alan!! That was exactly the problem. I'd stared at that
code for hours, and even rewrote it once, and hadn't caught that
problem.
>I'm sure it's been recommended that instead of returning 0 or 1 etc, you
>should return 'CONTINUE' or 'REJECT' etc. it shouldn't cause filter
Yes, looking into the mimedefang-filter man page, I see that. I got
the code I used from the Wiki, so I suppose the Wiki pages with the
example filters should be updated.
>when in doubt, running mimedefang.pl -test on your filter will show you
>most problems with your filter before running it live.
>perl -c should show you any serious compilation errors
I've added them to my toolbox. Thanks.
>From: "James Ebright" <[EMAIL PROTECTED]>
>
>OK, I assume the XXX you have in there are actually filled in with real
Yes, I merely obscured the addresses of the hosts that don't talk
directly to the 'Net.
>Simple enough to do, something like:
>if (($helo =~ /(^|\.)psicorps\.org$/i) || ($helo =~
>/(^|\[)209\.170\.141\.103\]$/i)) {
What if the address is *not* enclosed in [ ]s? Does one merely delete
the [ and ] from that test, or is it more complex than that?
>Also, I think you have your reject and ok flipped (ok is 0 and reject is 1 I
>think), returning the value is depreciated anyway, us the constants like so:
Seems to be working fine (I tested it by telnetting in from an
external host), and as I noted above, I got the snippet from the Wiki.
>From: "David F. Skoll" <[EMAIL PROTECTED]>
>
>It's unlikely to be a timeout. Ensure that the "-l" option is being supplied
>to mimedefang-multiplexor and check your logs for error messages.
Yes, the -l option is part of the invocation.
Thank you, Alan, James and David. MIMEDefang is working well right
now. Just basic filtering in place, but I want to add more.
Dirk
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Question about filtering relays and recipients
I've been reading more in the mimedefang-filter man page, and I'm unclear regarding some aspects of the section titled RBL LOOKUP FUNCTIONS. I'm just not very good at Perl, I'm afraid - I'm an old C hack, so program flow is not an issue, but the syntactical differences keep tripping me up. Anyway, the man page is unclear on WHERE (in mimedefang-filter) the relay_is_blacklisted_* functions should be placed. I would think that filter_relay would be the place, but I'm not sure. Could someone clarify that? I'm also looking for some example code using relay_is_blacklisted_multi_count, including how to construct the array of RBLs to pass to that function and how to properly evaluate the return value (for example, to REJECT with X or more "hits" but not trip over SERVFAIL or NXDOMAIN). Additionally, I'd love to use the md_check_against_smtp_server function, but I'm not sure I can. In my environment, where I host a number of Domains, the MIMEDefang server could relay to any one of 4 other servers. That is, "[EMAIL PROTECTED]" might have his mailbox of "server1.domain1.tld" while "[EMAIL PROTECTED]" has her mailbox of "server2.domain1.tld" and "[EMAIL PROTECTED]" has a mailbox on "server1.domain1.tld". Sendmail deals with this thru the use of mailertable and virtusertable. Do I need to employ stream_by_recipient ? Or should I use the SOCKETMAP functionality (I do have sendmail v8.13.4) to have MIMEDefang query virtusertable and mailertable? For that matter, as MIMEDefang looks at these E-Mail addresses, is it seeing them *before* or *after* sendmail has run thru aliases, virtusertable, and mailertable? Does anyone ever have an environment where they host multiple Domains across multiple interior servers? Also, does the SMTP server against which the "check" will be done need to support VRFY? If not, are there any of the usual anti-SPAM settings in sendmail (e.g. needhelo) that should be avoided so that MIMEDefang can place its query? Thanks again to the MD community for the assistance. Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] MaxMIMEParts and MIME::Tools
The man page states that I must have the Roaring Penguin-patch version of MIME::Tools v5.411a-RP-Patched02 or newer in order for MaxMIMEParts to be effective. The command: perl -MMIME::Tools -e'print "$MIME::Tools::VERSION\n";' gives me: 5.417 I'm unclear on if I have a "good" version. Is MIME:Tools v5.412 and up OK, or do I still need the "RP" version? Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Question about filtering relays and recipients
I've been reading more in the mimedefang-filter man page, and I'm
unclear regarding some aspects of the section titled RBL LOOKUP
FUNCTIONS. I'm just not very good at Perl, I'm afraid - I'm an old C
hack, so program flow is not an issue, but the syntactical differences
keep tripping me up.
Anyway, the man page is unclear on WHERE (in mimedefang-filter) the
relay_is_blacklisted_* functions should be placed. I would think that
filter_relay would be the place, but I'm not sure. Could someone clarify
that?
I'm also looking for some example code using
relay_is_blacklisted_multi_count, including how to construct the array
of RBLs to pass to that function and how to properly evaluate the return
value (for example, to REJECT with X or more "hits" but not trip over
SERVFAIL or NXDOMAIN).
Additionally, I'd love to use the md_check_against_smtp_server
function, but I'm not sure I can. In my environment, where I host a
number of Domains, the MIMEDefang server could relay to any one of 4
other servers. That is, "[EMAIL PROTECTED]" might have his mailbox of
"server1.domain1.tld" while "[EMAIL PROTECTED]" has her mailbox of
"server2.domain1.tld" and "[EMAIL PROTECTED]" has a mailbox on
"server1.domain1.tld". Sendmail deals with this thru the use of
mailertable and virtusertable.
Do I need to employ stream_by_recipient ? Or should I use the
SOCKETMAP functionality (I do have sendmail v8.13.4) to have MIMEDefang
query virtusertable and mailertable? For that matter, as MIMEDefang
looks at these E-Mail addresses, is it seeing them *before* or *after*
sendmail has run thru aliases, virtusertable, and mailertable? Does
anyone ever have an environment where they host multiple Domains
across multiple interior servers?
Also, does the SMTP server against which the "check" will be done
need to support VRFY? If not, are there any of the usual anti-SPAM
settings in sendmail (e.g. needhelo) that should be avoided so that
MIMEDefang can place its query?
Thanks again to the MD community for the assistance.
Dirk
--
Message: 8
Date: Thu, 16 Jun 2005 17:49:10 -0400 (EDT)
From: Dirk the Daring <[EMAIL PROTECTED]>
Subject: [Mimedefang] MaxMIMEParts and MIME::Tools
To: mimedefang@lists.roaringpenguin.com
Message-ID: <[EMAIL PROTECTED]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
The man page states that I must have the Roaring
Penguin-patch version of MIME::Tools v5.411a-RP-Patched02 or newer in
order for MaxMIMEParts to be effective.
The command:
perl -MMIME::Tools -e'print "$MIME::Tools::VERSION\n";'
gives me:
5.417
I'm unclear on if I have a "good" version. Is MIME:Tools v5.412 and up
OK, or do I still need the "RP" version?
Dirk
--
Message: 9
Date: Fri, 17 Jun 2005 00:03:09 +0200
From: Jan Pieter Cornet <[EMAIL PROTECTED]>
Subject: Re: [Mimedefang] Out of memory on FreeBsd 5.4
To: mimedefang@lists.roaringpenguin.com
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On Thu, Jun 16, 2005 at 04:13:33PM -0500, Jim McCullars wrote:
> > Jun 16 16:18:19 host1 mimedefang-multiplexor[7689]: Slave 1 stderr: Failed
> > to compile URI SpamAssassin tests, skipping: (Out of memory during
>
>In your MIMEDefang startup script, do you have values defined for
> MX_MAX_RSS or MX_MAX_AS? That could be the culprit.
Also, BigEvil is really deprecated, and eats gobs of memory. I suggest
you use surbl.org instead. It can be enabled by default with SA 3.x,
and is available via a plugin for SA 2.6x. That will require network
lookups, though, so you might consider mirroring the zones locally if
you have a large volume mail server.
--
#!perl -wpl # mmfppfmpmmpp mmpffm <[EMAIL PROTECTED]>
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}->(map{/p|f/i+/f/i}split//,$&)+97):qw(m p f)[map{((ord$&)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$&;$f.eig;# Jan-Pieter Cornet
--
___
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
End of MIMEDefang Digest, Vol 21, Issue 26
**
+++Processed by ProcMail v3.22+++
Handled by ProcMail v3.22
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Stopping bogus Domain in HELO
I've added MIMEDefang v2.52 to my sendmail v8.13.4 mail relay running
on Solaris 8, and have significantly reduced my SPAM (I *love* rejecting
SPAMmers who try to HELO as one of my own machines). Of the remaining
SPAM that leaks thru, I'm seeing things like:
> Received: from lh ([60.221.66.22]) by [my host] with SMTP id
"lh" is an obviously fake hostname. How would I go about requiring a
HELO, if an IP address in brackets is not given, to have a resolvable
FQDN?
Here is what I have in "filter_sender" already:
Cut Here
sub filter_sender {
my($sender, $hostip, $hostname, $helo) = @_;
# Check #1
# Can't be "psicorps.org" unless it's one of our IP addresses
if ($helo =~ /(^|\.)psicorps\.org$/i) {
if ($hostip ne "127.0.0.1" and $hostip ne "209.170.141.XXX" and
$hostip ne "209.170.141.XXX" and $hostip ne "209.170.141.103" and
$hostip ne "209.170.141.XXX" and $hostip ne "209.170.141.XXX") {
syslog('alert', "MIMEDefang rejected a connection where Host
$hostip said HELO $helo");
return('REJECT', "FRAUDULENT HELO/EHLO REJECTED: $hostip is not
authorized to use $helo for authentication");
}
}
# Check #2
# Check for HELO where IP address is the relay server address either
# without or with square brackets
if (($helo =~ /209\.170\.141\.103$/) ||
($helo =~ /(^|\[)209\.170\.141\.103\]$/i)) {
syslog('alert',"MIMEDefang rejected a connection where Host $hostip said
HELO $helo");
return('REJECT', "FRAUDULENT HELO/EHLO REJECTED: $hostip is not
authorized to use $helo for authentication");
}
# Check #3
# Check for IP-address-only HELO - SMTP standard requires it be enclosed
if ($helo =~ /^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/) {
syslog('alert',"MIMEDefang rejected a connection where Host $hostip said
HELO $helo");
return ('REJECT', "SMTP ERROR: Please conform to SMTP when saying HELO");
}
return('CONTINUE', "OK");
}
Cut Here
Or would this be better done in filter_relay?
Dirk
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Restarting MIMEDefang
MIMEDefang v2.52 with ClamAV v0.85.1 and sendmail v8.13.4 on Solaris 8. If I alter mimedefang-filter.pl, do I need to restart *both* the multiplexor and MIMEDefang, or just MIMEDefang? Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Stopping bogus Domain in HELO (James Ebright)
>From: "James Ebright" <[EMAIL PROTECTED]> > >On Mon, 20 Jun 2005 12:50:59 -0400 (EDT), Dirk the Daring wrote > >>"lh" is an obviously fake hostname. How would I go about >> requiring a HELO, if an IP address in brackets is not given, to have >> a resolvable FQDN? > >The problem with blocking on this is you will end up blocking alot of >legitimate email as well, some MTAs and most MUAs send pretty much whatever >they feel like for a helo string. One very popular one uses the username as >the helo string.. Well, this is a relay server. No MUAs should be talking to it directly, so it doesn't matter if popular MUAs are this stupid, they shouldn't be talking to this server in the first place. As for MTAs that are this stupid h. Which ones? Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] [FOLLOWUP] Re: Restarting MIMEDefang
>From: Jan Pieter Cornet <[EMAIL PROTECTED]> > >On Mon, Jun 20, 2005 at 10:20:48PM -0400, Dirk the Daring wrote: >> MIMEDefang v2.52 with ClamAV v0.85.1 and sendmail v8.13.4 on Solaris 8. >> >> If I alter mimedefang-filter.pl, do I need to restart *both* the >> multiplexor and MIMEDefang, or just MIMEDefang? > >You only need to tell the multiplexor to restart the mimedefang.pl slaves, >like this: > >mimedefang.pl -test && md-mx-ctrl reread Thanks! I've added a "restart" option to my start/stop script. As a followup, if I wanted to change one of the command-line options with which the multiplexor was invoked (for example, changing the "l" value, which periodically logs the slave status), could I stop and then restart just the multiplexor, or should I kill and restart both components? And what about MIMEDefang? If I wanted to change the invocation by, say, adding "-s" so it would filter on sender, can I stop/start that individual component without having to stop/start the multiplexor? Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Q about Rejecting based on charset
I've noticed that a lot of the SPAM that I get uses oddball character
sets, while most of my HAM is either US-ASCII or UTF-8. Examining the
SPAM a bit more, I've compiled a list of about 8 character sets that are
apparently always SPAM.
I found some sample filter code on a website, and I'm trying to adapt
it to what I want to do, which is reject E-Mail using these character
sets. I'd appreciate a sanity-check of both the code and the idea.
This is what I'm adding to "sub filter":
$head = $entity->head;
$charset = $head->mime_attr("content-type.charset");
if (defined($charset)) {
$charset =~ tr/A-Z/a-z/;
if ($charset eq "ks_c_5601-1987" or
$charset eq "euc-kr" or
$charset eq "iso-2022-kr" or
$charset eq "big5" or
$charset eq "windows-1251" or
$charset eq "windows-1255" or
$charset eq "gb2312" or
$charset eq "gb2312_charset") {
syslog('alert',"MIMEDefang rejected an E-Mail using charset $charset");
return ('REJECT', "CONTENT VIOLATION: Mail using character set
$charset not accepted here");
else {
return action_accept();
}
}
Thanks for help and advice.
Dirk
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] [SOLVED] Q about Rejecting based on charset
On Fri, 24 Jun 2005, I wrote: >I found some sample filter code on a website, and I'm trying to adapt > it to what I want to do, which is reject E-Mail using these character > sets. I'd appreciate a sanity-check of both the code and the idea. Jim McCullars: > If you don't have foriegn nationals at your organization that may need >to send/receive email in those character sets, then I don't see a problem. Nope, don't have that issue. Matthew van Eerde: > Implementation: looks sane OK, good. >Idea: looks insane >I think you're over-reacting. This is verging on an RFC violation: OK. Ordinarily I'd agree with you. However, an analysis of 10 YEARS of collected E-Mail has shown that 6 of those character sets are *only* associated with SPAM. Only the "windoze-125x" sets show up in any of my HAM, and then its very little - and I can drop those two sets out of my auto-reject list. And MD already technically violates RFCs. I think that worrying about this idea violating the spirit of an RFC "should" clause is like worrying that the finish on my new anti-burgler deadbolt lock violates the HOA-approved color scheme. >>James Ebright >Jim McCullars >> Would this not be better served by leaving this to Spamassassin? If it is not > > If he knows for a fact that he wants to reject those emails outright, >then rejecting them in filter() and avoiding a call to SA is the more >prudent choice. That is my objective - to ditch the garbage as early as possible. If I can avoid invoking SA and reliably kill SPAM, that's fine. Thanks to everyone for their feedback. Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] [Slightly OT]: Q about Rejecting based on charset
>From: "James Ebright" <[EMAIL PROTECTED]> >>If he knows for a fact that he wants to reject those emails >> outright, then rejecting them in filter() and avoiding a call to SA >> is the more prudent choice. > >Well, while true it would be more efficient, I would not call it more prudent, >to me allowing the end user the choice to decide what is and is not spam when >the only positive hit might be the charset is more prudent, you can easily >allow for that in SA. Basically you loose the flexibility SA allows for a bit >more efficiency (probably a moot amount unless you are slammed with these >types of messages). But, as you pointed out, it is his call. I have weathered amazing, tho brief, storms of SPAM. I agree that universally rejecting based on the 6 final charsets (I eliminated the "windows_125x" sets from my list) does lose some of the flexibility of SA, but like I said, in my 10 year mail archive, none of those 6 character sets were associated with HAM. My analysis of my individual situation (vis-a-vis the services I provide to the population I support) is that rejecting E-Mail using those character sets is a reasonable balance against imposing my SPAM rules on the user population and efficiently distributing my resources. >Also, Dirk, if you have a spam corpus of 10 years then you need to read the >thread about prior art and some recent patent debates, your information may be >usefull... [or were you exagerating a tad ;-) ] Got a link? Actually, I confess that my SPAM corpus is not that old. Probably only 2 years, 3 at most, and then much of that resides on backup media as opposed to online. My HAM corpus does indeed go back 10 years. I confess to being an E-Mail packrat. Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] MD on a fresh machine
I'm installing MD on a fresh machine (Solaris v8 w/latest patches,
Perl v5.8.6, sendmail v8.13.4) and in preparation I've installed
SpamAssassin v3.0.4 first, along with all the other modules needed for
both applications.
After installing SA, I used this script to check the installation
status of all the modules:
#!/opt/perl/bin/perl
use ExtUtils::Installed;
my $instmod = ExtUtils::Installed->new();
foreach my $module ($instmod->modules()) {
my $version = $instmod->version($module) || "???"
print "$module -- $version\n";
}
This was the result when I ran the script:
[EMAIL PROTECTED] /home/admin 5 % perl listmods.pl
Archive::Zip -- 1.14
Compress::Zlib -- 1.34
DB_File -- 1.811
Digest::HMAC -- 1.01
Digest::SHA1 -- 2.00
HTML::Parser -- 3.45
HTML::Tagset -- 3.04
IO::Stringy -- 2.110
MIME-tools -- ???
MIME::Base64 -- 3.05
Mail -- ???
Mail::Audit -- 2.1
Mail::SpamAssassin -- 3.04
Net -- ???
Net::DNS -- 0.51
Net::IP -- 1.23
Perl -- 5.8.6
Pod -- ???
Time::HiRes -- 1.66
Unix::Syslog -- 0.100
I'm concerned that the MIME-tools, Mailtools, Net and Pod modules do
not show up as having a version. These are what I installed:
Archive-Zip-1.14
Compress-Zlib-1.34
DB_File-1.811
Digest-HMAC-1.01
Digest-SHA1-2.00
HTML-Parser-3.45
HTML-Tagset-3.04
IO-stringy-2.110
MIME-Base64-3.05
MIME-tools-5.417
Mail-Audit-2.1
MailTools-1.67
Net-DNS-0.51
Net-IP-1.23
Time-HiRes-1.66
Unix-Syslog-0.100
libnet-1.19
podlators-1.27
Is this unusual? Or do those 4 modules just not implement a "version"
routine?
Dirk
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] [SOLVED] MD on a fresh machine
I wrote, in part: >>I'm concerned that the MIME-tools, Mailtools, Net and Pod modules do >> not show up as having a version. These are what I installed: >From: Jan Pieter Cornet <[EMAIL PROTECTED]> >This is a bug or anomaly in the ExtUtils::Installed module - it has > [SNIP] >So you can just ignore this. Thanks for the explanation. That was really bugging me, and I thot it was the source of some of my other issues with this installation. I've also figgered out that the perllocal.pod file is a roadmap to the add-on modules. I'm still having other issues, but I'll bring those up in a fresh message. Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] HELP! At end of my rope with MD/SA
I have been beating my head against the wall, trying to add
SpamAssassin v3.0.4 to my MIMEDefang v2.52 installation. This has gone
on for a solid week, and I am at the end of my rope. I need help, and I
hope the community can offer me some fresh ideas.
The System:
Solaris 8 (with MU #7 and 2005-Jun-05 patchkit) on Sun 4m
Perl v5.8.6 compiled with gcc v3.3.2
IO-Stringy v2.110
MIME-Base64 v3.05
MailTools v1.67
MIME-Tools v5.417
Digest-SHA1 v2.10
libnet v1.19
Mail-Audit v2.1
Time-HiRes v1.68
HTML-Tagset v3.04
HTML-Parser v3.45
Compress-Zlib v1.34
Archive-Zip v1.15
UNIX-Syslog v0.100
ClamAV (clamd) v0.85.1 and sendmail v8.13.4 are also installed
The Problem:
MIMEDefang v2.52 builds and installs fine. It detects
Mail::SpamAssassin and indicates its OK to use SA-related calls in
mimedefang-filter. The sa-mimedefang.conf file is installed in
/opt/mimedefang/conf
If I run MD with a filter that *optionally* adds SA (that is,
using
if ($Features{"SpamAssassin"})
constructions as the default filter does, MD works fine.
If I add
$Features{'SpamAssassin'} = 1;
to mimedefang-filter, so I can eliminate the "if $Features" logic and
simplify my -filter file, I get the following error:
Can't locate object method "new" via package "Mail::SpamAssassin"
(perhaps you forgot to load "Mail::SpamAssassin"?) at
/opt/mimedefang/bin/mimedefang.pl line 6177.
Compilation failed in require at /opt/mimedefang/bin/mimedefang.pl
line 4881.
I have been thru my Perl v5.8.6 install (in /opt/perl) from one end
to another, everything is world-readable, including the "site_lib"
hierarchy.
The contents of /opt/perl/bin, including all the SA executables, are
symbolically linked to /usr/bin, and again, all are
world-readable/world-executable (there's only 2 user accounts on this
machine, root and mine - its not an end-user server).
I can make more info available if needed, and any help is
appreciated. I really need to get this working.
Dirk
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] RE: HELP! At end of my rope with MD/SA
Summary: Adding SA v3.0.4 to an existing MD v2.52 install breaks MD
I wrote:
>> If I add
>>
>> $Features{'SpamAssassin'} = 1;
>>
>> to mimedefang-filter, so I can eliminate the "if $Features" logic and
>> simplify my -filter file, I get the following error:
>>
>> Can't locate object method "new" via package "Mail::SpamAssassin"
>> (perhaps you forgot to load "Mail::SpamAssassin"?) at
>> /opt/mimedefang/bin/mimedefang.pl line 6177.
>> Compilation failed in require at /opt/mimedefang/bin/mimedefang.pl
>> line 4881.
Gavin suggested some test:
[EMAIL PROTECTED] /usr/bin/mimedefang 5 $ which perl
/usr/bin/perl
[EMAIL PROTECTED] /usr/bin/mimedefang 6 $ /usr/bin/perl -v
This is perl, v5.8.6 built for sun4-solaris
[EMAIL PROTECTED] /usr/bin/mimedefang 10 SU # more ./bin/mimedefang.pl
#!/usr/bin/perl
[SNIP]
[EMAIL PROTECTED] /usr/bin/mimedefang 9 SU # perl -MMail::SpamAssassin -e
'print "installed\n"'
installed
[EMAIL PROTECTED] /usr/bin/mimedefang 16 $ perl ./bin/mimedefang.pl -features
MIMEDefang version 2.52
[SNIP]
SpamAssassin : yes
[SNIP]
Mail::SpamAssassin: Version 3.04
[SNIP]
The last command won't run unless I remove the "Features{'SpamAssassin'}" from
mimedefang-filter. If I leave that in, I get the same error as in my
first message.
Seems to me that MD is using the proper Perl location, that the Perl
installation includes SpamAssassin, and that MD "sees" SpamAssassin. As
you might imagine, given all this, I'm feeling a bit like Alice,
falling down the rabbit hole. I have no idea why SA breaks MD.
Gavin also said:
>Also check your environment and the environment of the user running
> mimedefang.pl
What's a good procedure to check this?
Dirk
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] RE: HELP! At end of my rope with MD/SA
Rob MacGregor asked:
>> The last command won't run unless I remove the
>> "Features{'SpamAssassin'}" from
>> mimedefang-filter. If I leave that in, I get the same error as in my
>> first message.
>
>What happens if you try the sample filter that's provided?
As long as the logic is "if {Features("SpamAssassin")}", everything
works. Whether that is by using the default supplied filter or whatever.
As soon as I try to require SA (so I can simplfy the filter logic), it
pukes.
>I've got MD 2.52 running with SA 3.0.4 quite happily here. Looks like
>you've got something oddball going on.
I agree, but I'm at a loss as to what is "oddball". MD claims (at
compile/install) that it sees SA just fine. As I showed in my previous
message, "mimedefang.pl -features" and perl -MMail::SpamAssassin -e
'print "installed\n"'" both insist that SA is present.
One thing that *might* be "oddball". I don't set environment
variables for MD - I pass it command-line parameters. So instead of
setting an environment variable "MX_EMBED_PERL", I just pass the "-E"
parameter to the multiplexor. Could this be an issue?
Dirk
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Perl Modules for MD install
>From: John Rudd <[EMAIL PROTECTED]> > >Not all of the modules listed on the Downloads page are current (and >one of them that is current says to use your version instead of the >CPAN version). > >Is it acceptable to use the CPAN current versions, or do we really need >to use the older versions you specify? > >-- > >From: "David F. Skoll" <[EMAIL PROTECTED]> > >The CPAN versions are fine. I should fix the MIMEDefang page. I recently installed MIMEDefang v2.52 on Solaris 8 with Perl v5.8.4. Here is a alost-complete list of the Perl modules I installed, most downloaded from CPAN: IO-Stringy 2.110 MIME-Base64 v3.05 MailTools v1.67 MIME-Tools v5.417 Digest-SHA1 v2.10 libnet v1.19 Mail-Audit v2.1 Time-HiRes v1.68 HTML-Tagset v3.04 HTML-Parser v3.45 Compress-Zlib v1.34 Archive-Zip v1.15 UNIX-Syslog v0.100 Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: mimedefang warningmessage in syslog
>-- >[EMAIL PROTECTED] wrote: > >> I'm a little bit confused why i suddenly recieves a new WARNING >> message in syslog, every time i restart mimedefang. > >On Solaris, you can ignore that message. Something in the Solaris C >library opens a descriptor when DNS lookups are initialized. It seems >to work fine, though. I can confirm this. I'm running MD v2.52 on Solaris 8 with Perl 5.8.6 and SA v3.03 and I see this message when MD starts. A Google search found a message on this topic - can't remember if it was this list or elsewhere - and the basic response was the same: it can be safely ignored on Solaris. Dirk ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] MDN != DSN (WAS: how to disable notify=success)
Folx, don't confuse Delivery Status Notification (RFC 1891, part of ESMTP and implemented on MTAs) with Mail Disposition Notification (RFC 3798, implemented by MUAs, not MTAs). "notify=success" is DSN and takes place during the ESMTP conversation, specifically the RCPT TO step. It does not involve a header (altho modern versions of sendmail, specifically, can convert the non-standard "Return-Receipt-To" header into a DSN request), and therefore MIMEDefang filters looking for headers such as "Disposition-Notification-To" or "Disposition-Notification-Options" will NOT affect DSN. Headers such as "Disposition-Notification-To" and "Disposition-Notification-Options" are associated with the MDN protocol, and not all MUAs implement it. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] RE: Don't call spamassassin for outbound e-mails
On Sat, 10 Dec 2005 [EMAIL PROTECTED] wrote:
>--
>From: "Ana Luiza Moura Weidlich" <[EMAIL PROTECTED]>
>
>I?d like to use SpamAssassin to check just my inbound e-mails. I use SA with
>MIMEDefang and Sendmail.
>How should I do configure mimedefang to don't call SA for outbound e-mails?
>--
Ana,
There's no handy "canned" way to do this with stock MIMEDefang,
at least not that I found. I modified mimedefang-filter to check
$RelayAddr against an array of my internal addresses, and then in
filter_end the call to SA is skipped if the host is internal. Here's the
relevant portions of my mimedefang-filter code.
Global variables:
###
# Declare an array of IP addresses we consider internal
# and a flag to use for program flow checks
###
@ourhosts=qw( xxx.yyy.zzz.1 xxx.yyy.zzz.2 xxx.yyy.zzz.3 );
$ourhost=0;
In filter_begin:
# Determine if we are dealing with our own hosts
for ( $indexhost=0 ; $indexhost < @ourhosts ; $indexhost++ )
{
if ( $RelayAddr eq $ourhosts[$indexhost] )
{
# This is our host - set a flag
$ourhost=1;
last;
}
}
In filter_end:
# Only bother with SpamAssassin if an E-Mail is *not* originating
# from inside our network
if ( ! $ourhost )
{
# Get size of message
$totalsize = -s "./INPUTMSG";
# Call SpamAssassin to perform SPAM checking, but only scan
# messages that are smaller than the limit defined above
if ( $totalsize < $SAScanSizeLimit )
{
# Call SpamAssassin
# hits = E-Mail SPAM score
# req = value of "required_hits" in sa-mimedefang.cf
# names = names of SPAM tests that it failed
# report = SA report
my($hits, $req, $names, $report) = spam_assassin_check();
}
}
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Requiring FQDN in HELO
I've noticed a lot of SPAM does not have an FQDN in the HELO. It'll have just "localhost" or even omit a hostname entirely. Obviously, if the HELO is an IP address in square brackets, that's fine. Is there any danger of rejecting "legitimate" E-Mail if I write my mimedefang-filter to: 1) Absent an IP address in square brackets, require a an alphanumeric string in the HELO 2) Reject a HELO where the alphanumeric string is not a FQDN (using a regex looking for at least one "." in the HELO string) The ultimate goal to allow filter_sender to reject any E-Mail where the HELO is a blank string (spaces) or something like "localhost" without any qualification. Are there any reasons that legit, reasonbly-standards-compliant senders would do those things? ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Requiring FQDN in HELO
Thanks for all the responses: >-- > >>Is there any danger of rejecting "legitimate" E-Mail if I write my >> mimedefang-filter to: >> >A number of MUAs, including Outlook, will AFAIK fall foul of that requirement. > >Rob MacGregor Well, LookOut! is a crappy client, and I don't think anyone about whom I am concerned is using it. Besides, in this case, the system in question is a relay and does not talk to any MUAs directly. >-- > >Frankly, I found a quite effect check was to look for the absense of square >brackets, around what otherwise try to pass themselves off as "IP >addresses". (ie: "123.45.67.89", rather than "[123.45.67.89]" at the HELO.) > >Ken I already do that, and yes, it blocks a significant amount of hostile traffic. >-- > >In addition, I believe rejecting email due to an invalid HELO/EHLO is a >rfc violation in of itself (MUST NOT even). That said, the only ones I >reject are the ratware ones that say they are me (my ip blocks or >localhost or my own FQDN). ;-) > >Jim I also already check for HELO/EHLO from my own IP block and hosted Domains. My question, in specific, is about *adding* a check for "localhost" as the sole HELO, and perhaps also something looking for an FQDN (not mine, obviously, since a previous check would exclude fraudulent use of my own FQDN). I'm aware of the fact that rejecting obviously bogus HELO/EHLO does technically violate the RFCs, and ordinarily I detest software that does such things. However, in this area, I'm of the opinion that the RFCs are a bit too loose. >-- > >From: Kenneth Porter <[EMAIL PROTECTED]>: > >You could still add SpamAssassin points for envelope violations. You can >either add some headers before passing the message to SA, or add the points >to what SA returns. (I found that SA does add points if the claimed name of >a "Received from" server doesn't match its reverse DNS.) I could, but then I still have to accept the message, run it thru MD *and* SA, and then judge it at the end of that process. In the mean time, the spammer thinks they have a sucker system - that is, they'll think I'm a good target to send more SPAM, since I accepted the message: as far as the spammer is concerned, a successfully transmitted message is a successful delivery, they don't concern themselves with return codes after the DATA step and they certainly do not care about bounces. My philosophy is that the sooner I can identify and drop an obviously fraudulent connection, the less of my resources - bandwidth, CPU, disk - the spammer can consume with their fraudulent traffic. Identifying a fraudulent connection at HELO/EHLO is much less "expensive" than accepting the message, running it thru MD and SA, and then deciding what I pretty much already know - its fraudulent. Does anyone have a regex they'd like to share to examine a HELO string and look for an FQDN? ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] ClamAV 0.88 Patch
On Fri, 20 Jan 2006 "David F. Skoll" <[EMAIL PROTECTED]> wrote: >> I have waited to upgrade my Calm to .88 to see if they come out with >> something like .88.1 > >I recommend upgrading to .88 with my patch. I've just stood up a Solaris 9 server with (all built from source) sendmail v8.13.5, SA 3.1.0, MD 2.54 and ClamAV 0.88 with David's patch. Its working fine. Dirk ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Limiting access to "everybody" alias
>-- > >From: Kenneth Porter <[EMAIL PROTECTED]> > >I'd like to provide an "all hands" alias for my office so that company >officers can send out announcements. MD seems like it would be a good place >to lock down this alias to keep others from abusing it. Does anyone have a >good recipe for implementing this kind of limitation? > >I have a similar requirement for my online game team, which plays numerous >games. I have an alias for each game that goes to the list of players >involved with that game, and I don't want spammers abusing these addresses. > >-- Its called an Internet Mailing List. I would suggest that, instead of re-inventing this functionality in MIMEDefang, you use either MajorDomo or Mailman. The former is probably easier to set up and like MIMEDefang it uses Perl, but it lacks a web-based interface and its administration can be cumbersome. Mailman has a web-based interface and a lot of features that MajorDomo lacks, but relies on Python (as opposed to Perl) and is harder to set up (IMHO, having done both). Of the two, I prefer Mailman (I used MajorDomo for 9 years, and promptly kicked it to the curb when I discovered Mailman). ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] RE: Installing MD on a Solaris 8 box?
On Mon, 27 Feb 2006 Fernando Gleiser wrote: >-- >From: Fernando Gleiser <[EMAIL PROTECTED]> > >I need to install MIMEDefang, SpamAssassin and ClamAV on a Solaris 8 box > >>From what I've seen, the gcc and perl versions are ancient, perl >is 5.005 and gcc is 2.95, so it seems I have to upgrade it. >sendmail is 8.11, I think I have to upgrade it too. > >Has anyone done it? are there any gotchas I should be aware of? I have installed MIMEDefang (versions 2.5x), SpamAssassin (versions 2.6x thru v3.0x) and ClamAV (versions 0.87.x thru v0.88) on Solaris v8 and v9 (both on SPARC hardware). Yes, it can be done. There is no GCC in a stock Solaris v8 environment, or any other C compiler, for that matter. If the system has one, it was added post-install. If you need to add one, or upgrade the existing one, I've found GCC v3.3.2 to work well on Solaris v8. You can download a pre-compiled GCC in Sun package format from http://www.sunfreeware.com The Perl in the stock Solaris v8 is Perl v5.000_03, I think. v5.00xxx for sure. You do NOT want to: 1) Try to use it for anything 2) Remove it You'll find that /usr/bin/perl is a link to /usr/perl5/bin/perl. Do NOT tamper with the contents of /usr/perl5 !!! Some core Solaris components rely on this version and location of Perl. Mess with it and you run the risk of choking your entire system. However, there's nothing wrong with putting a newer version of Perl elsewhere on the system and creating links in /usr/bin. The core components that rely on /usr/perl5 are hardcoded to look there, not in /usr/bin. So get Perl v5.8.x (I've used v5.8.6 and v5.8.8 with equal success) and install it (I put mine in /opt/perl and linked as needed to /usr/bin). The sendmail included with Solaris v8, even with the latest Recommended Patches, is horribly out-of-date. Get rid of it. The following commands will expunge it: # pkgrm SUNWsndmr # pkgrm SUNWsndmu Then get the latest code (v8.13.5 is latest as of this writing), build and install it (or get the pre-compiled binaries from the same place as the pre-compiled gcc). You want to remove Sun's ancient versions because if you don't, the next time you apply a Recommended Patches kit that contains a patch for either of those two package names, your sendmail will get clobbered. I learned this little bit the hard way. Note that there are some pre-requisites you may need to install before building sendmail - for example, Berkeley DB, or OpenSSL (if you plan on using SMTP-TLS). I'm mostly a build-from-scratch guy, so I dunno what the pre-built packages take. OK, so now you have a C compiler, a modern Perl version, and a current sendmail. Be sure to add all the additional Perl modules needed by MIMEDefang - these are readily available from http://www.cpan.org and are well-documented in the MD documentation. Sometimes you'll need to install one before another, as you'll find occasional dependencies. Next, build and install ClamAV and SpamAssassin before building and installing MIMEDefang, or MD won't detect them automatically. Once you have ClamAV and SA installed, build and install MD. Brandon Hutchinson has a great site chock full of Solaris-specific info, including an number of write-ups for sendmail on Solaris. See http://www.brandonhutchinson.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] RE: Installing MD on a Solaris 8 box?
On Sat, 4 Mar 2006 "Baker, Darryl" <[EMAIL PROTECTED]> wrote: >I would recommend uninstalling the Sun Sendmail packages before >installing another version. This avoids a Sun patch from overwriting >your newer version or any of your configuration. Do the same for Perl >and any other Sun supplied program you update. BAD advice, at least as far as the Solaris 8 default Perl installation goes. Quoting my earlier posting on this thread: --- Cut here --- The Perl in the stock Solaris v8 is Perl v5.000_03, I think. v5.00xxx for sure. You do NOT want to: 1) Try to use it for anything 2) Remove it You'll find that /usr/bin/perl is a link to /usr/perl5/bin/perl. Do NOT tamper with the contents of /usr/perl5 !!! Some core Solaris components rely on this version and location of Perl. Mess with it and you run the risk of choking your entire system. However, there's nothing wrong with putting a newer version of Perl elsewhere on the system and creating links in /usr/bin. The core components that rely on /usr/perl5 are hardcoded to look there, not in /usr/bin. So get Perl v5.8.x (I've used v5.8.6 and v5.8.8 with equal success) and install it (I put mine in /opt/perl and linked as needed to /usr/bin). --- Cut here --- ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Noting "may be forged" and IP-only HELO in filter_end
As I understand it, different MIMEDefang instances (slaves) may handle a given E-Mail as it progresses from "early" functions (e.g. filter_helo, filter_sender, filter_recipient) to the "later" functions (e.g. filter_begin, filter, filter_multipart, filter_end) that are all handed by one instance, I'm wondering if anyone has a low-cost mthods of passing the fact that a particular incoming E-Mail had an IP-only HELO (I flatly REJECT any HELO that is not an FQDN or that's otherwise obviously bogus - such as my own IP address or Domain Name), or detecting that sendmail thinks the HELO might be forged (as it notes in the "Received: from" header). I'd like to use the information in filter_end, but I don't have the HELO string (which I analyzed back in "filter_recipient" and would prefer not to "pay" to extract from the headers and analyze again) and I'm not sure how to detect the "may be forged" indication from sendmail, since I don't think that header is available in filter_end. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Noting "may be forged" and IP-only HELO in filter_end
On Sun, 12 Mar 2006 [EMAIL PROTECTED] wrote: >-- >From: John Rudd <[EMAIL PROTECTED]> > >For the IP-only HELO, or for HELO addresses you don't like, why not >reject it during filter_helo? That's when I do it (though, I don't >think I'm doing it for IP-only HELO's, I'm just doing it for obviously >stupid HELO's, like ones that claim to be from my own domain when the >IP addr isn't in my block, or from localhost when it's not localhost). Who said I was going to wait until filter_end to reject it? As I noted in my original query, I already reject the "stupid" HELOs long before filter, let alone filter_end. What I've noticed is that, often, what little SPAM leaks thru used an IP-only HELO. My purpose is to globally increase the SPAM scores of any foreign E-Mail where the mailserver HELO'd me IP-only, and also combine that bit of information (the fact that the HELO was IP-only) with other facts (e.g. a positive return from ClamAV) to see if I want to bit-bucket the E-Mail before I bother calling SpamAssassin. My philosophy is that the sooner I can ID and dump obviously garbage E-Mail, the less of my resources the SPAMmer/phisher/cracker gets to consume. >-- >From: "David F. Skoll" <[EMAIL PROTECTED]> > >> I'd like to use the [HELO] information in filter_end, but I don't >> have the HELO string > >Yes, you do. It's in the global variable $Helo. Ah. Thanks for pointing that out. >-- I'm still interested in finding out if anyone knows of a low-cost way to pick up on sendmail's determination of "may be forged" as it eventually shows in the "Received: from" header. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] RE: Syslog problems on Solaris 8? (Fernando Gleiser)
On Tue, 21 Mar 2006 [EMAIL PROTECTED] wrote:
>From: Fernando Gleiser <[EMAIL PROTECTED]>
>
>I've installed mimedefang-2.56 from source on a Solaris 8 system.
>Perl's version is 5.6.1 from sunfreeware.
>
>It seems to be working fine, except for one little detail: it doesn't
>log anything to syslog. the md_graphdefang_log_enable('mail', 1); line
>in mimedefan-filter is enabled and syslogd is runing, but in
>/var/log/syslog I only see sendmail's messages.
>
>I even tried manually setting "setlogsock('inet');" by hand on
>/usr/local/bin/mimedefang.pl and restarting mimedefang, but that didn't
>solve it.
>
>Any hints/pointers? I'm starting to run out of ideas.
I second the recommendation that you use Unix::Syslog instead of
Sys::Syslog. I used Unix::Syslog when I ran MD on Solaris 8 and
never had any problems. Also, note that the target logfile *must* exist
before syslogd starts, or nothing will be written to it, even if it is
subsequently created (unless you also SIGHUP the daemon after creating
the file). Unlike many Linuxes, the syslogd on Solaris 8 will not
complain about, or create, a missing file.
While its difficult to come by hard info, there is/was an undocumented
size limit on /etc/syslog.conf in Solaris 8 - too many lines, or too
many non-comment lines, or something like that, and the over-limit
lines get silently dropped (have no effect). So keep your syslogd.conf
short and concise. Finally, the stock syslogd in Solaris 8 does not
honor FACILITY.* constructs, only *.PRIORITY.
Dirk
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Per-recipient customization (David Eisner)
>Background: I have MIMEDefang running (with multiplexor and embedded
>Perl interpreter) on a Linux box that serves, by way of a mailertable,
>as an MX for another server. This second server runs Netware, hosts
>the actual mailboxes, and provides pop service.
Since you mention NetWare, is it a good idea to assume that the mail
environment is GroupWise? Modern GroupWise serves POP3 (as well as IMAP,
and SSL flavors of both, but POP3 is only at the GWIA), and as it
happens, I have a very similar arrangement at one place where I set up
the mailsystem (SLES 9 with sendmail v8.13 and MD 2.52 fronting
GroupWise v7).
>Whether or not you think it's a good idea, I need to give users the
>option of discarding messages with SpamAssassin scores above a certain
>threshold. Such messages should be discarded at the server running
>MIMEDefang, before they reach the user's MUA. Right now we tag them
>with the X-Spam-Score header in the usual way.
If your users understand that pros and cons (and preferably have
signed a written statement to that effect), I don't see an issue. I'll
note in passing that, if you mailsystem is GroupWise, then user Rules
that would discard based on the "X-Spam-Score" header are possible, and
would take effect upon initial delivery of the E-Mail to their mailbox.
Thus an appropriate Rule would discard (Trash) the E-Mail before the
user ever saw it.
>One approach I'm considering is a configuration file on the MX that
>would be a table of envelope recipient addresses (or recipient regex's)
>and score thresholds. If a recipient matches an address (or regex, if I
>go that route) in the config file, the threshold is compared to the
>reported score to determine whether to discard the message (for that
>user -- see below) or just tag it as we do now.
>
>What would be a good way to approach this? The first thing that comes
>to mind is putting the file in /etc/mail/ (say
>/etc/mail/mimedefang_user_prefs.cf), read it in filter_initialize(), and
>then use it in filter_end() somewhere after spam_assassin_check().
>
>Another issue: how to handle one message with multiple envelope
>recipients, not all of whom have the same policy. I need to RTFM and
>think about this a bit more, but would it be relatively easy to strip
>some recipients in filter_end(), and leave others, before the message is
>forwarded through the mailertable mechanism?
I wrote code in my MIMEDefang filter to do per-recipient rejection
based on the SA score. I'm not a Perl programmer by trade, and doubtless
my code will generate some giggles from anyone who sees just how
brute-force it is, but it does seem to work well.
The way it is presently coded, a purpose-written function checks a
static array of E-Mail addresses. One such check is made for each
Recipient listed in the SMTP envelope (@Recipients, not the "To:"
header). If the SA score for the E-Mail is over the limit defined for
the Recipient, then the Recipient is removed from the @Recipients array.
If, at the end of the process, there are no Recipients left, the entire
E-Mail is DISCARDed.
Here is my code in filter_end, just after the call to SA:
--- Cut here ---
[...]
# Enter SPAM limit checking code only if
# SPAM score is at least as high as the LOWEST
# limit in our list
if ( $hits >= $limitspamlow )
{
# Cycle thru list of addresses for which a
# specific SPAM score limit has been defined
# and delete the recipient from the E-Mail
# when the score exceeds the defined limit
# for that address
for ( $repindex=0 ; $repindex < @Recipients ; $repindex++ )
{
# Initialize SPAM limit variable to insure that every
# loop uses the proper number
$spamlimit=0;
$spamlimit = _check_limit($Recipients[$repindex]);
# If we found a limit, act on it
if ( $spamlimit )
{
# If SPAM score exceeds limit,
# bounce the message for that
# recipient, log, and decrement
# counter tracking total # of recipients
if ( $hits >= $spamlimit )
{
md_syslog('alert', "[$MsgID] filter_end:
deleted $Recipients[$repindex] - SPAM score $hits exceeded limit $spamlimit");
delete_recipient($Recipients[$repindex]);
$numrcpts--;
}
else
{
# md_syslog('alert', "[$MsgID] filter_end:
permitted an E-Mail to $Recipients[$repindex] because the SPAM score of $hits
did not exceed $spamlimit");
}
}
else
{
md_syslog('info
[Mimedefang] filter_recipient questions
I've noticed a lot of dictionary spamming of late, and I was thinking
of enhancing my filter_recipient to help stop it. Right now, I basically
use filter_recipient to look for a HELO claiming to be me, or for an
E-Mail headed to my "whitelist request" address.
What I'd like to add is something to check validity of local
recipients (using a mechanism other than md_check_against_smtp_server
for various political reasons that aren't important here), but I'm not
sure how the logic flow works.
My questions are:
1) Is filter_recipient called for each RCPT TO: (as would
appear to be the case), or at DATA?
2) The documentation states that if filter_recipient returns
DISCARD, the message is discarded for ALL Recipients. Is
this also true of REJECT (as would also appear to be
the case)?
3) Since it looks like filter_recipient can't be used to
selectively (on a per-Recipient basis, allowing to some
but not all) reject/discard a connection, can I have it
alter a given Recipient envelope address so I can look
for that "flag" in filter_begin and remove the
Recipient there?
My idea is something like (where "recipient_valid" is a function
I've written to check address validity, returning FALSE for a *valid*
address and TRUE for an *invalid* one):
[existing filter_recipient code...]
if ( recipient_invalid($recipient) )
{
$recipient = "[EMAIL PROTECTED]";
return ('CONTINUE', "OK");
}
[...existing filter_recipient code]
and then
[existing filter_begin code...]
[start loop to step thru @Recipients; $check is index...]
if ( $Recipients[$check] =~ "invalid" )
{
delete_recipient($Recipients[$repindex]);
}
[...end loop to step thru @Recipients]
[...some code to check if there are any valid Recipients left...]
if ( $no_valid )
{
return('REJECT', "Dictionary SPAM rejected");
}
[...existing filter_begin code]
Feedback? Sane? Insane?
Dirk
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: filter_recipient questions (Jan Pieter Cornet & David Skoll)
Thanks to David and Jan for replying:
On Fri, 28 Apr 2006 [EMAIL PROTECTED] wrote:
>--
>> 1) Is filter_recipient called for each RCPT TO: (as would
>> appear to be the case), or at DATA?
>
>At RCPT To:
And David noted the same thing. That was my reading of the docs, I
just wanted to be sure.
>> 2) The documentation states that if filter_recipient returns
>> DISCARD, the message is discarded for ALL Recipients. Is
>> this also true of REJECT (as would also appear to be
>> the case)?
>
>Nope, REJECT will reject that single recipient, not any other recipients.
>We do that all the time, works fine. Why do you think a REJECT here
>stops the entire email?
Because the documentation states that DISCARD affects all recipients,
but is silent on the subject of REJECT. Since no differentiation is
made, the "safe" conclusion is that REJECT and DISCARD have similar
results (rather than assuming that REJECT has a less-broad scope and
coding a filter that inadvertently REJECTs entire messages because of a
wrong assumption). At least if I was wrong, I would have been wrong on
the side of not inadvertently dumping entire E-Mails.
>Some MUAs will abort the entire transmission, when one of the RCPT TOs
>fail. That is to be construed as a feature. MTAs will do "the right
>thing" and continue with the email for the other recipients (if any).
The MTA in this case is sendmail v8.13, and the host does not talk to
any MUAs, only other MTAs.
>That won't work, just return('REJECT', "Recipient invalid");
I was hoping I could do that. Much simpler (altho it'll also involve
being nice enuf to the SPAMmers to give them a 5xx, and I really don't
like being nice to them.
>Ugh. You really do such stuff in production code? I hope nobody
>has the idea to start a JoinValidation project at your site to
>scrutinize SQL code, and creates an email address after the
>project name.
I'm not a Perl programmer, nor an SQL programmer for that matter. And
all projects at my site are initiated, managed, performed and reviewed
by me. And Harvey the Rabbit. Same thing with all E-Mail addresses. :-)
>You don't ever get here if all recipients are REJECTed ;)
Yep, that would be my preference, to REJECT in filter_recipient.
Dirk
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Non-routable addresses in HELO
I've noticed some SPAMmers recently starting to HELO using non-routable
IP addresses (mostly 10.x.x.x or 192.168.x.x)
I'm thinking of filtering for this, and I came up with this code (which
would be placed AFTER the check for an IP-based HELO in square brackets -
so any IP-based HELO missing the brackets has already been rejected).
I'd appreciate any feedback anyone would like to offer on this code
snippet:
# Check for a HELO that is a non-routable address and therefore invalid
if (($helo =~ /(^|\[)10\.d{1,3}\.d{1,3}\.d{1,3}\]$/i) ||
($helo =~ /(^|\[)192\.168\.d{1,3}\.d{1,3}\]$/i))
{
md_syslog('alert',"$MsgID: Fraudulent HELO $helo by Host
$hostip");
return('REJECT', "FRAUDULENT HELO/EHLO: $hostip is not $helo");
}
Obviously, if I have sending hosts on my network that really did have
non-routable addresses, this would be a possible problem (altho the simple
solution is for them to not HELO with their IP, but use their hostname).
And yes, the code does omit the 172.16-31.x.x range - haven't seen them
yet, altho I imagine it's just a matter of time.
Dirk
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Summary of non-routable addresses in HELO
On Mon, 10 Jul 2006, [EMAIL PROTECTED] wrote:
--
From: Steffen Kaiser <[EMAIL PROTECTED]>
It makes no sense to optionally allow [ left, but enforce ] on the right
side. Digits don't have no case at all.
As with the case portion of the RegEx, the flaw with the bracket was
probably a code typo. Actually, by the point at which the code would
reside, an IP-based HELO lacking square brackets would have already been
REJECTed. Therefore, the test needs to allow for the square brackets.
Would would be the proper RegEx?
The better solution would be:
If you trust them -> exempt them from the check at all!
That's a bit of a digression. Yes, the first checks I perform are to
see if the relay address is one of my own hosts, and if it is, I cease
further checking. But that wasn't what I was asking about.
--
From: Kayne Kruse <[EMAIL PROTECTED]>
If your seeing drive by spammers, I honestly would be looking at
implementing greylisting instead. Most of my spam experience has shown
that a vast majority is coming from IP addresses that do not get used
that often.
I agree that a lot of SPAM is sent courtesy of 'botted Windoze boxes
and that the same IP rarely gets used twice. Which leads me to politely
disagree about greylisting.
I'm not saying that greylisting has no value or should never be used.
But my personal anti-SPAM philosophy is to reject SPAM as early and often
as possible. The sooner I identify a connection as obviously bogus, the
sooner I can drop it, and the less of my resources (bandwidth, CPU, disk,
etc) the spammer gets to waste.
Greylisting means I have to have the code to implement it (CPU, RAM)
and the back-end database to maintain the greylisting info (disk, CPU). If
a spammer HELOs with an IP address that is obviously bogus, why waste my
resources greylisting it? Drop the idiot and be done with it.
--
From: Jim McCullars <[EMAIL PROTECTED]>
I just reject when someone sends an IP address as a HELO, and it is not
their actual IP address. In filter_sender():
if ($helo =~ /^\d+\.\d+\.\d+\.\d+$/) { # looks like an IP
if ($helo ne $ip) {
return('REJECT', "IP address $ip doesn't match helo string $helo");
}
}
Thanks, Jim! That's exactly the sort of thing I was looking for. I'm
going to work on implementing that!
Dirk
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Question about MD v2.57 dependencies
I'm looking at the Downloads page for MIMEDefang v2.57, specifically at the list of required Perl modules. I see that the page says to use MIME-tools v5.420. I'm currently running MIMEDefang v2.54 with MIME-tools v5.419. I'd like to upgrade to MD v2.57. Do I need to upgrade MIME-tools also, or is v5.419 sufficient? All my other Perl modules are at the required level, or above. Dirk ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Question about sendmail/MD interaction
I was asked recently if using FEATURE(`delay_checks') in sendmail.mc affected when MD was passed data by the sendmail MILTER interface. I don't think that it does, but I wanted to be sure. So, does that FEATURE change how MD interacts with sendmail? Dirk ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] RegEx for HELO evaluation
Since MIMEDefang v2.57 would require some minor filter code mods
anyway, I'm looking at re-writing my mimedefang-filter file to take
advantage of some features I've not used before. Along with that, I'd
taking a fresh look at some of the things I already do, such as filtering
based on HELO, and incorporating some ideas I've seen on this list.
I'm thinking of using this RegEx to sort HELO into "IP address,
with or without square brackets" or "everything else":
/^(\[?)(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})(\]?)$/
As I understand that, a matching string will be broken up into $1,
$2 and $3, while a non-matching string won't be broken up.
Here's the program logic I'm considering in filter_helo:
if ( $helo =~ /^(\[?)(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})(\]?)$/ )
{
# HELO was an IP
if ( $2 eq $helo )
{
# HELO was not surrounded by square brackets
return('REJECT', "INVALID HELO - missing square
brackets");
}
if ( $2 ne $hostip )
{
# IP HELO doesn't match actual IP
return('REJECT', "FRAUDULENT HELO - $helo is not
$hostip");
}
# Other HELO validity checks
}
else
{
# HELO was not an IP
# Various HELO validity checks
}
If anyone would like to offer feedback on these ideas, I'd
appreciate it.
Dirk
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Global variables in filter_helo
Is $MsgID (or $QueueID) set in filter_helo? The current documentation is vague on this point, stating that they are set in filter_sender and filter_recipient, but not filter_relay. No mention of filter_helo. Dirk ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Upgrading sendmail - recompile MD?
MIMEDefang v2.57 on Solaris 9 with sendmail v8.13.5 I'm upgrading sendmail to v8.13.7. Do I need to recompile/reinstall MIMEDefang since it was compiled against the older libmilter? Dirk ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] MIMEDefang and header-adding MILTERs
I'm thinking about meshing MIMEDefang (v2.57, with sendmail 8.13.7) with a MILTER that adds message headers, such as SnertSoft's milter-ns (http://www.snertsoft.com/sendmail/milter-ns) and I have a question. Specifically, will such a header added by milter-ns be available to me in MIMEDefang? The reason I ask is that there are some headers that are not available - for instance, the "Received: from" header of the latest hop. Would I be correct to assume that if the header is available, it's only available in filter_begin() and later? Dirk ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Inline attachments
On Sat, 30 Sep 2006, [EMAIL PROTECTED] wrote:
From: "Paul Murphy" <[EMAIL PROTECTED]>
I'm forced to use a braindead mail system (Novell Groupwise) which
appears to be having problems handling multiple inline attachments. An
example is attached.
I've enabled the filter option:
$Stupidity{"NoMultipleInlines"} = 1;
I've implemented and managed a number of GroupWise systems over the
past 10 years, and I've not seen this issue in *modern* GroupWise. You
didn't specify the VERSION of GroupWise, so I'll assume you have GroupWise
v7.0.1, the latest.
While the GroupWise Internet Agent (GWIA) has some definite problems
adhering to some of the RFCs, those affect what it *sends* more than what
it receives. I've fronted GWIA with a sendmail/MD combination and never
seen an issue handling multiple inlines like you say.
I suspect that either you have a really old version of GroupWise, or
you the real problem is the software generating the E-Mails you're
modifying.
Dirk
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Inline attachments
On Sun, 1 Oct 2006, [EMAIL PROTECTED] wrote: From: "Paul Murphy" <[EMAIL PROTECTED]> It is GWIA 7.0 - the incoming messages are ending up in the GWPROB directory, and are reported as bad messages. If I remove one of the inline attachments and re-submit the message, it is delivered correctly. OK, the latest code is v7.0.1. You might be tripping over a known bug, fixed in the current code. Try applying Support Pack 1. At first I suspected an issue with the mail content rather than with GWIA, but one of the cases is a newsletter from dabs.com which I also receive at home via Sendmail/MIMEDefang and Exchange. Interesting. Have you tried performing an action_rebuild on inbound mail and seeing if that makes a difference? Dirk ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] RE: Re: Inline attachments
On Mon, 2 Oct 2006, [EMAIL PROTECTED] wrote:
From: "Paul Murphy" <[EMAIL PROTECTED]>
OK, the latest code is v7.0.1. You might be tripping over a known bug,
fixed in the current code. Try applying Support Pack 1.
That could indeed be the issue - from the Readme:
14.9 Internet Agent Fixes
- The Internet Agent can correctly process Internet domain names
that contain dashes (-).
Maybe I'm being overly critical, but any Internet mail system which barfs on
domain names which contain a hyphen is pretty poor, as is the testing regime
which allowed this to be released...
Yes, I think you ARE being overly critical. How many code regressions
have had to be patched recently in both sendmail and MIMEDefang? Were
those products tested before release? Do you consider their developers
retarded or their testing regimes grossly deficient? I don't.
In 10 years of dealing with GroupWise, since v4.1, I've never seen it
have a problem handling a "-" in a Domain Name. Doesn't mean the problem
didn't exist or that you didn't get bitten, but it's the first time I've
heard of that specific issue.
Obviously, in the major code overhaul between v6.5 and v7.0, this
particular bug crept in. A programmer goofed, and a test case was either
flawed or missing. Happens to the best of products, and I think you're
holding Novell to an unreasonable standard based on a single litmus test.
Personally, as a _collaboration_package_, I like GroupWise. It's not
chained to a single platform or Directory Service, its web interface is
browser-agnostic, its got a pretty good feature-set for the price, and
it's not the high-overhead management pain that Exchange is.
That said, the GWIA is probably the weakest component Agent. I've said
that and more to the developers, face-to-face. Frankly, I'd like to see
them take the SMTP-to-LIN ("LIN" is the internal GroupWise message format)
translation code and make it into a sendmail MAILER program, leveraging
sendmail's adaptability and offering a chance to get rid of GWIA entirely
(unless it's used for IMAP, POP or iCal). They could take the LIN-to-SMTP
translation code and put it into the GroupWise MTA and have it drop the
outgoing message directly into a sendmail queue (since GroupWise Agents
run quite well on Linux).
Who knows, maybe they'll do it. But I'll bet quite a chunk of change
that Redmond would *never* do anything like that with Exchange. Try
running Exchange without being *forced* to use AD for user authentication,
try using something other than IE for the web interface (sorta works, but
crippled), try using something other than IIS as the web server, and try
running any Exchange Server component on anything other than Windoze (if
you succeed, try getting support for it). GroupWise gives you choices in
all those areas.
Interesting. Have you tried performing an action_rebuild
on inbound mail and seeing if that makes a difference?
No, but I'll give it a try on e-mail from the problem domains.
Given that you've identified a known issue that's fixed in the latest
release, I doubt action_rebuild will solve the particular problem you
started with. However, I freqently front my GroupWise systems with
sendmail/MIMEDefang - I get better anti-spam, and I only have to run
anti-virus in GroupWise System Domains that host Post Offices - I
don't have to bother with it at the GWIA's Domain. Again, GWIA is probably
the weakest Agent, and doing an action_rebuild on inbound mail will
probably completely eliminate "problem" messages.
Dirk
P.S. No, I *don't* work for Novell, never have. Just setting the record
straight based on my experience.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] filter_helo is not useless
On Wed, 8 Nov 2006, David F. Skoll wrote: Actually, I have a better idea: If I completely remove filter_helo, will anyone morn its passing? Less code == better, and filter_helo is next to useless. No, please don't do that. If people are unhappy with the exact way that filter_helo works, then they can code their checks into filter_sender or filter_recipient and not use it. I use filter_helo and am quite happy with it. I successfully reject obviously fraudulent HELOs at filter_helo. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] More on filter_helo
I don't have any problems with filter_helo. When it returns a REJECT, the SMTP conversation does not seem to progress any further. I'm using sendmail v8.13.8, MIMEDefang v2.57 and Perl v8.5.6. Perhaps the problem described originally is not really with filter_helo. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] The campaign to save filter_helo
On Thu, 9 Nov 2006, "David F. Skoll" <[EMAIL PROTECTED]> wrote:
Dirk the Daring wrote:
I use filter_helo and am quite happy with it. I successfully reject
obviously fraudulent HELOs at filter_helo.
At least, you *think* you do.
If you test it, you'll discover they're only rejected at MAIL FROM: time.
No, I'm fairly sure about this.
When I re-wrote my filter to take advantage of filter_helo, I also
inserted quite a few logging statements. Mainly to insure that my filter
did what I wanted it to do.
My examination of my logs quite clearly shows that when filter_helo
ended with a return('REJECT'), the connection progressed no further. I
have plenty of examples of this.
Also, after some analysis, I found I was able to reject some 50% of
foreign (not on my network) SMTP connections by the end of filter_helo.
Between sendmail's GREETPAUSE, RATECONTROL and CONNCONTROL; and using
filter_helo to detect obviously fraudulent HELOs, I dropped half the
spammers that much sooner.
I've already removed filter_helo from the svn version of MIMEDefang;
I appreciate all the work you do, and I've always been very happy with
MIMEDefang. I'm constantly referring people looking for a better anti-SPAM
solution to the RP website.
I really wish you'd reconsider removal of filter_helo. My personal
anti-SPAM philosophy is "Reject early, reject often" and filter_helo helps
me do that.
you can just move your test unchanged into filter_sender.
That can be done and will work, but it allows spammers to waste that
much more of my mail relay's CPU and my network's bandwidth. If I know
they're fraudulent at HELO, why let them lie to me again at MAIL FROM ?
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] filter_helo saved
On Thu, 9 Nov 2006, "David F. Skoll" <[EMAIL PROTECTED]> wrote: I have reconsidered and reinstated filter_helo. Thank you very much, David. I really appreciate your work on MIMEDefang. Dirk ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] sendmail and filter_helo interaction
Jim McCullars and I have been discussing filter_helo offlist, and
David's observation (supported by Jim's experimentation) that if
filter_helo returns a REJECT, the connection is not immediately rejected,
but rather is rejected after MAIL FROM.
It happens that I have been using a heavily-logged filter, and examined
some test connections that Jim made to my mailserver. Some interesting
results came out of that. I'm using sendmail v8.13.8 and MIMEDefang v2.57
on Solaris 9 with Perl v5.8.6.
It is true that even if filter_helo returns REJECT, the connection is
not immediately dropped. The sending host can still issue another command,
such as MAIL FROM.
However, it is also true that if the sending host does issue another
command, like MAIL FROM, that there is no corresponding MILTER call.
MIMEDefang never sees a call to filter_sender if filter_helo returns a
REJECT.
So it *appears* like the connection is maintained, but it also seems
that the SMTP conversation *effectively ends* if filter_helo returns
REJECT. The connecting host can issue another command, but it will be
ignored.
I've theorized that if the connecting host issues a RSET followed by
another (valid) HELO, the connection can proceed and be successful. This
might be why the connection is not immediately dropped. Also, I use
FEATURE(`delay_checks'), which may have something to do with it.
Something else also came out of the experiments. If a connecting host
violates GREETPAUSE (sends before presentation of the banner), its HELO is
still passed via MILTER call to MIMEDefang.
However, if RATECONTROL is tripped, there is no MILTER call. Presumbly,
this is true of CONNCONTROL.
Finally, I got asked about my filter_helo code. My current filter has
a *lot* of logging statements, because I've been experimenting and need
to meter its function. I'm also not a Perl hacker, so I doubt my code
is the most-efficient way to write this. Here it is...feel free to
use/adapt the code as may suit your needs, or ignore my code and write
your own:
# Some global variables used by the filter* functions
###
# Declare a hash of
# - Key: IP addresses we consider internal
# - Value: Flag as to if host is exempt from AV scans (0=No, 1=Yes)
###
%OurHosts=( "127.0.0.1", 0,
"192.168.2.2", 0,
"10.2.3.4", 0 );
###
# Declare a hash of
# - Key: Domain Names we host
# - Value: A flag as to if the Domain should be
# receiving E-Mail (0=No, 1=Yes)
###
%OurDomains=( "mydomain.tld", 1,
"otherdomain.tld", 1,
"notadomain.tld", 0 );
[..other code..]
#***
# %PROCEDURE: filter_helo
# %ARGUMENTS:
# IP address of remote host; hostname of remote host; HELO string
# presented by remote host
# %RETURNS:
# 2-5 element array (see documentation)
# %DESCRIPTION:
# Called after SMTP connection has been established and sending host has
# given a HELO statement, but not MAIL FROM: or RCPT TO:
#***
sub filter_helo ()
{
# Read the parameters passed to the function
my($hostip, $hostname, $helo) = @_;
# Local string for Domain name processing
my($domainstring);
# Local variable for string indexing
my($subindex)=0;
# Search the list of our hosts using the $hostip argument
if ( exists($OurHosts{$hostip}) )
{
# Recognize our internal host
md_syslog('info', "Internal Host $hostip HELO $helo");
# Don't look at it further
return('CONTINUE', 'ok');
}
else
{
# Foreign host
md_syslog('info', "Foreign Host $hostip HELO $helo");
}
# Check if the HELO is an IP address
if ($helo =~ /^(\[?)(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})(\]?)$/ )
{
# HELO looks like an IP - the comparison will split the string
# into 3 variables; $1 will have [ or be undefined, $2
will
# have the IP address without any brackets, $3 will have
# ] or be undefined ($1 and $3 are undefined if HELO
lacked
# square brackets)
md_syslog('info', "IP HELO $helo");
# Check #0
# The IP address portion should *not* be identical to the
# original HELO string - if it is, the original HELO
lacked
# brackets and therefore is invalid (this is "safer" than
# trying to evaluate $1 and $3 directly, as they may be
# undefined, or hav
[Mimedefang] HELO checks (WAS: sendmail and filter_helo interaction)
On Fri, 10 Nov 2006, Richard Laager <[EMAIL PROTECTED]> wrote:
# Check #3
# HELO should not contain "localhost"
How effective is this for you? Do you run into false positives?
It's effective in my situation because the servers that run MIMEDefang
are purely mail relays into/out of the network. Authorized E-Mail clients
(MUSa) authenticate to other, "interior" servers, so there are no purely
client connections. Everything connecting to the relays is an MTA.
Even a misconfigured internal MTA won't be tripped up because internal
relays are exempted from all checks HELO thru RCPT TO. I don't even start
to look at internal relays until after DATA.
There is no reason for a foreign (not on my network) MTA to HELO with
"localhost" anywhere in its HELO string. If they do so, they're either
fraudulent, grossly misconfigured or the admin is RFC Ignorant.
If they're fraudulent, why do I want to talk to them? Or allow them to
waste more of my resources?
If they're grossly misconfigured, then I'm not interested in finding
out what other misconfigurations they have. One of them might be dangerous
to me.
If the admin is RFC Ignorant, well, the error message has the
information they need to become clueful.
# Check #4
# If the HELO is an FQDN, the index and rindex of "." will not
be the same
# This catches the spammer using domain.tld (which will slip
# by Check #2)
I check that the HELO must have a ".", but I haven't gone any further
than that. Does this work well for you? Any false positives?
Not sure what you mean by "false positives". How would you define a
"false positive"?
On Fri, 10 Nov 2006, John Rudd <[EMAIL PROTECTED]> wrote:
Dirk the Daring wrote:
# Check #4
# If the HELO is an FQDN, the index and rindex of "." will not be the
same
# This catches the spammer using domain.tld (which will slip
# by Check #2)
if ( index($helo, ".") == rindex($helo, ".") )
{
# Reject connection - invalid HELO
md_syslog('alert', "Non-FQDN HELO $helo by Host $hostip");
return('REJECT', "INVALID HELO/EHLO: $helo is not FQDN");
}
As I wrote previously, my entire filter is heavily logged. My
analysis of those logs indicates that only about 50% of foreign
mailhosts connecting to my network get past HELO. Based on the
I-think-reasonable assumption that no "legitimate" mail server would be
tripped up by GREETPAUSE, RATECONTROL, CONNCONTROL or the tests I have
in filter_helo, my conclusion is that those 50% are spammers, and I'm
effectively stopping them by the end of HELO.
Given that I don't think check #4 is valid, I'm not sure I believe your
claim. For one, depending on the configuration I'm using, you might end
up rejecting my email, because my mail server's hostname is the
registered domain name (rudd.cc) ... and I'm not a spammer.
Check #4 is quite valid - see below.
As for my numbers, I've done some statistical analysis on my log files
- as I said, my current filter file is heavily logged as I experiment with
different approaches.
One logging feature is a log entry for each connection from a foreign
host (made in filter_relay). I can then track that connection and see how
far it gets. My analysis is that only about 50% of foreign connections
make it past HELO. Since my checks are primarily aimed at obvious fraud, I
conclude that the checks are stopping 50% of the spammers (since
"legitimate" MTAs operating in accordance with RFCs are not troubled).
(I don't recall any prohibition on a host's name being just its
registered domain, domain.tld)
Actually, the RFCs clearly state that acceptable HELOs are the
hostname/FQDN or the IP address.
Specifically, RFC 821, 4.1.1, stated:
The argument field [of the HELO command] contains the host name
of the sender-SMTP.
That's "host name", not "domain name".
And since RFC 2821 supercedes 821, it's text is even more important;
and 4.1.1.1 states:
The argument field [of the HELO or EHLO command] contains the
fully-qualified domain name of the SMTP client if one is
available. In situations in which the SMTP client system does not
have a meaningful domain name (e.g., when its address is
dynamically allocated and no reverse mapping record is available),
the client SHOULD send an address literal
Again, that's "fully-qualified domain name"..."rudd.cc" is not a
fully-qualified name.
I'm also curious w
Re: [Mimedefang] Score Clamav Results
On Tue, 19 May 2009, mimedefang-requ...@lists.roaringpenguin.com wrote:
--
Message: 1
From: "Jeff Grossman"
I am starting to use some third party clamav virus databases and would
like to score the results instead of just delete the e-mail which contains
a hit. I am not a very good Perl programmer. Does anybody have any
examples of scoring those results based on the signature name? If so,
would you be willing to share them with me?
Cut Here
sub filter_begin
{
my($entity) = @_;
# ...blah blah... #
# Scan for viruses using ClamAV (clamd)
my($code, $category, $action) = message_contains_virus_clamd();
# Look to see if virus was found
if ($category eq 'virus')
{
# Check to see if it is a specific virus
# $VirusName is a global variable in MIMEDefang
# and was populated by the call to
# message_contains_virus_clamd()
if ($VirusName eq 'Signature-Name-Here')
{
# Do Whatever
}
}
# ...blah blah... #
}
Cut Here
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
