rcpthosts, relaying, and tcp-env 7.6
n, and it appears to be working fine. >2. qmail doesn't want to be insecure out of the box, so it doesn't allow >relaying. What you want is to set up relaying for the relevant external >boxes that you want to use mail.baldmonkey.org as their smarthost. That's what I think I'm doing by adding that odd line to /etc/hosts_allow. I'm referencing question 5.4 in the FAQ, which seems to address my problem. I think that the problem might be that I don't have hosts_options enabled in my tcp-wrappers. I'm running a 7.6 RedHat RPM, and I don't know if hosts_options is enabled or not. I'm assuming that it is not, based on the docs in the source distribution. Unfortunately. I can't get version 7.5 to compile, and I can't find version 8. This is the error that I get after running 'make linux' on the 7.6 dist: -DBROKEN_SO_LINGER -Dvsyslog=myvsyslog -DALWAYS_HOSTNAME -c diag.c cc -O -DFACILITY=LOG_MAIL-DHOSTS_ACCESS -DPARANOID -DGETPEERNAME_BUG -DBROKEN_FGETS -DLIBC_ CALLS_STRTOK -DDAEMON_UMASK=022 -DREAL_DAEMON_DIR=\"/usr/sbin\" -DPROCESS_OPTIONS -DSEVERITY=LOG_ INFO -DRFC931_TIMEOUT=10 -DHOSTS_DENY=\"/etc/hosts.deny\" -DHOSTS_ALLOW=\"/etc/hosts.allow\" -DBROKEN_SO_LINGER -Dvsyslog=myvsyslog -DALWAYS_HOSTNAME -c percent_m.c percent_m.c:17: conflicting types for `sys_errlist' /usr/include/stdio.h:553: previous declaration of `sys_errlist' make[1]: *** [percent_m.o] Error 1 make[1]: Leaving directory `/usr/local/src/tcp_wrappers_7.6' make: *** [linux] Error 2 That's everything. I again apologize for the length of the post, but I wanted to include every snippet of information that I have so far. I've just subscribed to the list, so if anyone who replies could be so kind as to cc me so I don't miss any messages, I'd appreciate it. Many thanks, Todd Finney
Asking again: rcpthosts, relaying, and tcp-env 7.6
oes not include a POP3 or IMAP daemon. Tell qmail to use mailboxes instead of maildirs and use any daemon, or let qmail use maildirs and get a POP3 or IMAP daemon that understands them. I'm running the qmail-pop3d daemon, and it appears to be working fine. 2. qmail doesn't want to be insecure out of the box, so it doesn't allow relaying. What you want is to set up relaying for the relevant external boxes that you want to use mail.baldmonkey.org as their smarthost. That's what I think I'm doing by adding that odd line to /etc/hosts_allow. I'm referencing question 5.4 in the FAQ, which seems to address my problem. I think that the problem might be that I don't have hosts_options enabled in my tcp-wrappers. I'm running a 7.6 RedHat RPM, and I don't know if hosts_options is enabled or not. I'm assuming that it is not, based on the docs in the source distribution. Unfortunately. I can't get version 7.5 to compile, and I can't find version 8. This is the error that I get after running 'make linux' on the 7.6 dist: -DBROKEN_SO_LINGER -Dvsyslog=myvsyslog -DALWAYS_HOSTNAME -c diag.c cc -O -DFACILITY=LOG_MAIL-DHOSTS_ACCESS -DPARANOID -DGETPEERNAME_BUG -DBROKEN_FGETS -DLIBC_ CALLS_STRTOK -DDAEMON_UMASK=022 -DREAL_DAEMON_DIR=\"/usr/sbin\" -DPROCESS_OPTIONS -DSEVERITY=LOG_ INFO -DRFC931_TIMEOUT=10 -DHOSTS_DENY=\"/etc/hosts.deny\" -DHOSTS_ALLOW=\"/etc/hosts.allow\" -DBROKEN_SO_LINGER -Dvsyslog=myvsyslog -DALWAYS_HOSTNAME -c percent_m.c percent_m.c:17: conflicting types for `sys_errlist' /usr/include/stdio.h:553: previous declaration of `sys_errlist' make[1]: *** [percent_m.o] Error 1 make[1]: Leaving directory `/usr/local/src/tcp_wrappers_7.6' make: *** [linux] Error 2 That's everything. I again apologize for the length of the post, but I wanted to include every snippet of information that I have so far. I've just subscribed to the list, so if anyone who replies could be so kind as to cc me so I don't miss any messages, I'd appreciate it. Many thanks, Todd Finney
Re: Asking again: rcpthosts, relaying, and tcp-env 7.6
I'd like to thank those on the list who pointed me in the right direction, notably away from tcp-env and over to tcpwrappers. Half an hour later, it works like a charm. thanks again, Todd
Re: Startup works from shell but not from /etc/rc.d/qmail
At 11:06 PM 8/7/00, you wrote: >At 02:17 PM 8/8/2000 +1200, you wrote: > >What kind of pid is considered ``wrong''? I thought all > programs that > >backgrounded themselves, did so by forking a child and > exiting the > >parent. > >Wrong for the purposes of the /etc/rc.d/init.d scripts; >i.e., for the "status", "stop", and "restart" commands. Couldn't you just do something like this in the rc script to get the correct pid every time? `ps -C qmail-send | sed 's/^.\([0-9]*\).*/\1/' | tr -d [:space:]` [Note: There is probably a better way to do this. Suggestions are welcome.] cheers, Todd
Re: Startup works from shell but not from /etc/rc.d/qmail
At 02:05 AM 8/8/00, you wrote: >On Tue, Aug 08, 2000 at 01:24:48AM -0400, Todd Finney >wrote: >! Couldn't you just do something like this in the rc >script >! to get the correct pid every time? >! >! `ps -C qmail-send | sed 's/^.\([0-9]*\).*/\1/' | tr -d > >! [:space:]` > >I think you probably meant ``^.*'' instead of ``^.''. eh, close enough for jazz. >! [Note: There is probably a better way to do >! this. Suggestions are welcome.] > >If I remember correctly, this does pretty much the same >thing as >``pidof'', except I think the latter is faster. Excellent. You previously mentioned pidof, but said that it wouldn't work. I didn't test that statement. >Even faster, I believe, is to simply write qmail-send's >pid to >/var/run/qmail.pid, as suggested in my previous post; then >you don't >even have to search through all the processes, as ``ps'' >and ``pidof'' >have to. I don't know which one would be faster. Speed really isn't an issue in this case though, is it? You only need to get the pid when you run the rc script, and that is (hopefully) not a regular occurrence. Also, the time it takes to scan the process list is probably trivial when compared with the time it takes to restart qmail-send. If the qmail-rcfile file is already set up to look for the qmail pid, changing where it looks for it is a simple search and replace. You have to change the file anyway if you're implementing the qmail.pid solution, and pidof saves you the trouble of adding the (admittedly minor) pid recording function. pidof, a win by 44 characters? cheers, Todd
Re: Startup works from shell but not from /etc/rc.d/qmail
On 9 Aug 2000, Chris, the Young One wrote: >On Tue, Aug 08, 2000 at 03:57:20AM -0400, Todd Finney wrote: >! I don't know which one would be faster. Speed really isn't >! an issue in this case though, is it? > >I love efficiency wherever I find it (though a good friend calls me >``the king of procrastination'', so I guess I don't practise what I >preach). So, to me, whether it's an issue here is not an issue. :-) Doing 50% more work to have a seldom-run and small-footprint process run 10% faster is not efficient. >! You have to change the file anyway if >! you're implementing the qmail.pid solution, and pidof saves >! you the trouble of adding the (admittedly minor) pid >! recording function. > >But no, we don't have to change /etc/rc.d/init.d/qmail. As mentioned >in a previous message, Ellen is using a script file that backgrounds >/var/qmail/rc; my solution only involves changing that script. Go back and read the messages again. Ellen didn't need to correct pid for the startup script. She needed it for qmail-rcfile, which is different. If you're changing the location of the pid - be it from nothing to /var/run/qmail.pid or from nothing to /sbin/pidof qmail-send, you need to update the qmail-rcfile to reflect this change. Using pidof removes the need to record the pid to a file, which saves you about 44 characters. > >! pidof, a win by 44 characters? > >You know you're a geek when you start counting how many characters a >command takes up. :-) (That's a compliment, in case you take it the >other way.) Thank you. cheers, Todd
Re: Relaying stopped. How to remove SPAMMER status?
At 06:55 PM 8/15/00, Aaron L. Meehan wrote: >Quoting Tim Jones ([EMAIL PROTECTED]): > > Well, I've successfully installed and configured QMail > on my homebrewed > > Linux server. As such, the rampant SPAM relay that my > system allowed > > over the past month has been stopped. > >Fascinating. qmail is relay-proof by default, so you >almost have to >purposefully mess up, unless doing something really dumb >like >allowing percent hack or something, to allow it to >relay. Then, >having messed up and knew it, you let it be a "rampant >spam relay" for >a month? I hope I'm not reading that correctly--perhaps >it was rampant >for a month and you just happened to not notice and only >did *today*. > >Excuse me, but administrators of spam relays get me worked >up. >Especially qmail relays! Ugh. I think that you're reading him incorrectly. I believe that he meant to say that he had been using some other mail package, and the relaying was happening. He has now switched to qmail and the relaying has, of course, stopped. Todd
Re: NAKEDWIFE.EXE Virus - Filter available
At 10:21 PM 3/9/01, Kari Suomela wrote: >Friday March 09 2001 13:30, Erwin Hoffmann wrote to Chrisanthy >Carlane: > > EH> Take care that you deleted any potential control characters in > the > EH> last line. > >How about posting the scripts compressed on the site? That way funny >browsers won't destroy them. :) Why not just download it in a way that doesn't catch the characters? lynx --dump http://www.fehcom.de/qmail/checkattach >>checkattach or, use DJB's previously mentioned utility. Todd
filtering with perl
I've been thrashing at this for a couple of hours, and I'm starting to
wonder if I'm even on the right track.
The short question:
I'd like to strip a few headers from messages sent to a particular
address, for the purpose of setting up a anonymous remailer for a
mailing list. I have a small perl script that I think should do this,
but it isn't working. Is this possible without qmail-filter? It
seems like it should be, but I'm starting to doubt it.
The longer question:
I have set up the appropriate .qmail file, which points to a file
inside DIR called anonymizer. Inside that file is:
|/usr/local/bin/ezmlm/anonymizer.pl
|/usr/local/bin/ezmlm/ezmlm-send '/home/list/test'
anonymizer.pl, in its barest form, is this:
#!/usr/bin/perl
my $from = 'From: [EMAIL PROTECTED]';
my $list = 'To: [EMAIL PROTECTED]';
while (<>) {
s/From:\s.+$/$from/o;
s/To:\s.+$/$list/o;
}
exit 0;
I have confirmed that the messages are actually hitting the script by
changing the exit code to 100 and catching the bounce.
The script works as expected from the command line:
[alias@sonata alias]$ /usr/local/bin/ezmlm/anonymizer.pl
here
here
From: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
However, messages sent to that test-anonymizer@ address come through
with neither header altered.
Can someone put me on the right track?
thanks,
Todd
Re: filtering with perl
Thanks, that appears to do the trick. I tried doing that with
qmail-inject, and it didn't work.
I surprised that I can't just modify the stream. I thought that was
the whole point of program delivery. Doing it this way precludes
checking the message with ezmlm-reject, but I suppose that's not too
big a deal.
thanks again,
Todd
At 05:38 AM 3/22/01, Kirill Miazine wrote:
>You first submit a message to the perl prog, it does its stuff and
>happily exits without doing something with the content
>What if you open a pipe from the program to
>/usr/local/bin/ezmlm/ezmlm-send '/home/list/test'?
>
>something like
>
>#!/usr/bin/perl
>my $from = 'From: [EMAIL PROTECTED]';
>my $list = 'To: [EMAIL PROTECTED]';
>open PIPE, '|/usr/local/bin/ezmlm/ezmlm-send /home/list/test';
>while (<>) {
> s/From:\s.+$/$from/io;
> s/To:\s.+$/$list/io;
> print PIPE $_;
>}
>close PIPE;
Virus propagation in action
Wow. I expect my users to not know any better when it comes to virii and attachments. That's the purpose of anti-virus software, filtering, and the other sundry defenses. Consider yourself technical enough to administer a mail server? Then you should know better. Chris, Johan, David, RC, for your reading pleasure: http://vil.mcafee.com/dispVirus.asp?virus_k=98881&; cheers, Todd
Re: It's not my list but ... (AV Bots)
At 09:54 AM 4/24/01, Brett Randall wrote:
>Or simply strip the attachments to any messages... That'd be my ideal
>choice. Keep the list relatively text-only (HTML to some degree), have
>no virii problems and keep total bandwidth usage down. Overheads are
>obvious, but at least for each e-mail to the list, the attachment
>would just have to be stripped when it arrived (a relatively simple
>Perl script could do it, or a compiled C program if you're after
>efficiency).
On an ezmlm list, stripping MIME attachments is as simple as saying
'Hey, don't let any MIME attachments through'. Stripping uuencoded
attachments is equally simple - you just add
|/usr/bin/uudecode -o /dev/stdout >/dev/null 2>&1 && { echo
"Attachments Prohibi
ted"; exit 100; }; exit 0
to DIR/editor.
I'm not sure what kind of overhead this generates, but we host several
lists that all have volumes equal to or greater than this list, and
I've never noticed a problem.
Setting a maximum message size helps also. That's probably not a good
idea on a tech list, though, as messages including debugging
information can be rather long sometimes.
The real answer, of course, is "lose Outlook, and stop double-clicking
things", but I suppose we're ignoring that for the purposes of this
discussion.
Todd
Re: It's not my list but ... (AV Bots)
At 03:44 PM 4/24/01, Frank Tegtmeyer wrote: >Todd Finney <[EMAIL PROTECTED]> writes: > > > On an ezmlm list, stripping MIME attachments is as simple as ... > >To be exact: that's only possible with ezmlm-idx. Yes, my bad. Todd
Re: Filter incoming messages for one particualr user
At 05:08 PM 5/2/01, Charles Cazabon wrote: >Sean Brown <[EMAIL PROTECTED]> wrote: > >if the sender > > is any other address besides [EMAIL PROTECTED], mailuser will > silently > > throw the message away. If the message is from > [EMAIL PROTECTED], it > > completes the instructions in mailuser's .qmail file (which right > now > > forwards to three other addresses). > >Use a .qmail file; have the first instruction a program delivery (|) >which >checks the contents of the SENDER environment variable (the envelope >sender >address), and exits appropriately to control whether the remainder of >the >.qmail file (containing an instruction for storing in a Maildir or >mbox file) >is executed. You can use iftocc, from the mess822 package, to do this. I just used it for the first time yesterday, tres cool. http://cr.yp.to/mess822.html Todd
Re: Filter incoming messages for one particualr user
At 05:33 PM 5/2/01, Markus Stumpf wrote: >On Wed, May 02, 2001 at 05:15:33PM -0400, Todd Finney wrote: > > You can use iftocc, from the mess822 package, to do this. > >No, you can not. >The original poster wanted to check the *sender* not the recipient. Bah. That makes me 0-2 for the past month. I'll shut my pie-hole now. Todd
Re: unauthorized relay :-(
At 08:55 PM 5/17/01, Roger Walker wrote: > My admin mailbox has been filling up with bounces from > aol.com - >obvious SPAM that appears to have originated from my qmail system >(running >ucspi-tcp-0.88 and daemontools-0.70. Here's my rather simple config >for >tcpserver: > >127.0.0.1:allow,RELAYCLIENT="" >206.75.255.:allow,RELAYCLIENT="" >10.:allow,RELAYCLIENT="" >:allow > > The first line is for localhost, the second for my class 'C', > the >third for private network stuff behind a firewall and through a VPN. I >presume the last is to allow anyone to connect to allow them to send >to my >hosted domains. Doesn't that last allow line cause an open relay? http://cr.yp.to/ucspi-tcp/tcprules.html "The instructions in a rule must begin with either allow or deny. deny tells tcpserver to drop the connection without running anything. For example, the rule :deny tells tcpserver to drop all connections that aren't handled by more specific rules." The fact that your local domains appear in the control files is what allows the host to receive mail for the domains, not tcpserver. Todd
Re: unauthorized relay :-(
At 04:47 AM 5/18/01, Henning Brauer wrote: >On Thu, May 17, 2001 at 08:47:46PM -0400, Todd Finney wrote: > > At 08:55 PM 5/17/01, Roger Walker wrote: > > >:allow > > Doesn't that last allow line cause an open relay? > >NO! The last :allow is needed for other Mailservers delivering mail to >your >domains listed in rcpthosts. Unless RELAYCLIENT is set qmail does not >relay >to foreign domains. No need to shout there, Henning. Please note the question mark at the end of my sentence; I wasn't sure. If you must use caps, please save them for the idiots that can't figure out how to unsubscribe. cheers, Todd
injecting qmail-queue
Before I go into detail about the problem I'm having, I'll describe
what I'm trying to do, to make sure that I'm even on the right track.
We host a number of lists running under ezmlm-idx. I want to send an
announcement out to all of the lists every month. I first tried to do
this with a list of lists, but ezmlm doesn't care for that approach,
because the list name doesn't wind up in the To: or Cc: headers.
I'd rather not have things depend on the announcement process user
being a subscriber or in DIR/allow, which I think precludes the use of
qmail-inject. So, I'm attempting to do it with qmail-queue.
I created my message file, message.txt, and my envelope file
envelope.txt. AFAIK, they're in the correct format.
Looking back through the list, I saw Peter Green's example from a few
months ago, and came up with this:
#!/usr/bin/perl -w
use strict;
$|++;
my $mailprog = '/var/qmail/bin/qmail-queue';
my $message = './list_monthly_announcement.txt';
my $envelope = './list_monthly_announcement_recipients.txt';
open MSG,"$message" or die "Failed to open message file $!";
open ENV,"$envelope" or die "Failed to open envelope $!";
open \*STDIN, "<&MSG";
open \*STDOUT, "<&ENV";
my $rc = exec( $mailprog );
if ($rc) {
die "$rc something happened";
}
This does nothing useful (nothing in the log, no message sent),
although I'm at a loss to explain why. I saw references to calling a
pipe() to do this properly, but I can't find an example. Does one
exist?
thanks,
Todd
Re: injecting qmail-queue (asking again)
Asking again because, well, I'm still stumped.
>Date: Sat, 19 May 2001 20:20:19 -0400
>To: [EMAIL PROTECTED]
>From: Todd Finney <[EMAIL PROTECTED]>
>Subject: injecting qmail-queue
>
>Before I go into detail about the problem I'm having, I'll describe
>what I'm trying to do, to make sure that I'm even on the right track.
>
>We host a number of lists running under ezmlm-idx. I want to send an
>announcement out to all of the lists every month. I first tried to
>do this with a list of lists, but ezmlm doesn't care for that
>approach, because the list name doesn't wind up in the To: or Cc:
>headers.
>
>I'd rather not have things depend on the announcement process user
>being a subscriber or in DIR/allow, which I think precludes the use of
>qmail-inject. So, I'm attempting to do it with qmail-queue.
>
>I created my message file, message.txt, and my envelope file
>envelope.txt. AFAIK, they're in the correct format.
>
>Looking back through the list, I saw Peter Green's example from a few
>months ago, and came up with this:
>
>#!/usr/bin/perl -w
>use strict;
>$|++;
>
>my $mailprog = '/var/qmail/bin/qmail-queue';
>my $message = './list_monthly_announcement.txt';
>my $envelope = './list_monthly_announcement_recipients.txt';
>
>open MSG,"$message" or die "Failed to open message file $!";
>open ENV,"$envelope" or die "Failed to open envelope $!";
>
>open \*STDIN, "<&MSG";
>open \*STDOUT, "<&ENV";
>
>my $rc = exec( $mailprog );
>
>if ($rc) {
> die "$rc something happened";
>}
>
>This does nothing useful (nothing in the log, no message sent),
>although I'm at a loss to explain why. I saw references to calling a
>pipe() to do this properly, but I can't find an example. Does one
>exist?
>
>thanks,
>Todd
>
>
>
Re: injecting qmail-queue (asking again)
At 11:32 PM 5/21/01, peter green wrote: >Todd, this would do just as well (or better) on the ezmlm list, since >a >couple of the possible solutions use ezmlm-* rather than qmail-queue. I thought about that, but it isn't really an ezmlm question anymore. There doesn't seem to be an example on using qmail-queue anywhere. It seems to me that there probably should be. >* Todd Finney <[EMAIL PROTECTED]> [010521 23:12]: > > >We host a number of lists running under ezmlm-idx. I want to send > an > > >announcement out to all of the lists every month. I first tried > to > > >do this with a list of lists, but ezmlm doesn't care for that > > >approach, because the list name doesn't wind up in the To: or Cc: > > >headers. > >So make ezmlm-reject omit that behavior. `man ezmlm-reject` And give up the spam protection that this provides? No thanks :). > > >I'd rather not have things depend on the announcement process user > > > >being a subscriber or in DIR/allow, which I think precludes the > use of > > >qmail-inject. So, I'm attempting to do it with qmail-queue. > >Eek, why not invoke ezmlm-send for each list? `man ezmlm-send` No need >to >mess with qmail-queue, I don't think. Yea, that sounds nice, but there isn't an example of using that outside of a .qmail file, either. I'd think that tfinney]$ cat ./list_monthly_announcement.txt | /usr/local/bin/ezmlm/ezmlm-send /home/list/test/ would work, but no dice. Anyway, that _is_ an ezmlm problem, and isn't our problem here. > > >I created my message file, message.txt, and my envelope file > > >envelope.txt. AFAIK, they're in the correct format. > >If you are asking for help, it would probably be best if you were >complete >in your setup. Don't assume something is in the right format: prove it >by >posting it. (Or put it up on the web and link to it.) > >This may or may not actually help in this scenario, but you are >*asking* to >get reamed by any number of people for mentioning the files but >refusing to >post them. FYI. I didn't refuse to post anything. :) Please don't say that I did. I didn't include the envelope file because it seemed secondary to the problem. If I can't figure out how to get qmail-queue to take input, what difference would it make what I'm feeding it? I tried three different formats. I believe the first is correct, but I saw a few mentioning of the other two, and tried them. I saw no difference in running the script with any of them. F [EMAIL PROTECTED]\0 T [EMAIL PROTECTED]\0 \0\0 "F" [EMAIL PROTECTED]\0 "T" [EMAIL PROTECTED]\0 \0\0 "F"[EMAIL PROTECTED]\0 "T"[EMAIL PROTECTED]\0 \0\0 > > >#!/usr/bin/perl -w > > >use strict; > > >$|++; > > > > > >my $mailprog = '/var/qmail/bin/qmail-queue'; > > >my $message = './list_monthly_announcement.txt'; > > >my $envelope = './list_monthly_announcement_recipients.txt'; > >Again, here's where it would be REALLY helpful to see this text file. See above. > > >open \*STDIN, "<&MSG"; > > >open \*STDOUT, "<&ENV"; > >Er, off the top of my head, you want to reverse that wokka, since >STDOUT is >an output stream. Like: > > open \*STDIN, "<&MSG"; > open \*STDOUT, ">&ENV"; > >Ah yes, looking at `man perlopentut` would seem to indicate that >format is >right. > >Anyway, it seems to be a lot of overkill. Just iterate over your lists >and >invoke ezmlm-send for each one. Done. Thanks, I'll look into that, but I think a little more explicit documentation on qmail-queue would be helpful. If I figure this out, I'll post an example to the list, so that we don't have to have this conversation again. cheers, Todd
Re: Oops,I guess Sendmail wasn't secure after all...
At 12:25 PM 6/2/01, Mark Delany wrote: >On Sat, Jun 02, 2001 at 05:20:01PM +0200, Boris allegedly wrote: > > Well, there is no button with a text like "press me here" -) > for > > the public. > >Of course there is, silly. > >Now, what do you think most script kiddies do? They don't scour the >code for exploits as you imply with "there is no button". They simply >download the hard work of one or two people and install the pre-built >button. It's trivial. So, "press me here" is as far away as a >download. You're not seriously suggesting this is a serious secruity >barrier are you? This is a very, very good point. We have unfortunately reached a stage where the crackers don't need to actually _know_ anything anymore. They download a port scanner and a root kit, and can compromise your machine without having any real understanding of what's going on. You not only have to protect yourself from the skilled, determined cracker, but also from the unskilled, casual cracker. The former is far more difficult than the latter, but fortunately the really talented black hats have better things to do than hit 99% of the machines out there. We had a machine compromised by an exploit in the wu-ftpd package a couple of years ago. Fortunately, I happened to be on the machine when it occurred, and was able to monitor the cracker's activities and shut him down before he was able to cause any real damage. Based upon the things he typed, he had no idea what he was doing: cd /etc/init. cd /etc/init.d ls cd etc ls ls init* ls rc* cd rc.local ls ls -al rc.* cd init.d And yet, in the space of 5-10 minutes, he was able to break in and install three trojans. Sendmail can be secure, if you really know what you're doing and stay on top of the patches that come out (every three days or so). I don't have that kind of time, so I'd rather have a mail server that is secure out of the box. We've been gradually migrating our domains from sendmail to qmail over the last ~year; I've had to patch sendmail at least twice, qmail hasn't needed anything since install. I can deal with (sometimes) sketchy documentation and the hassle of installing 12 different things to get the results I want - that's still easier than restoring a machine that's been compromised. Todd
Re: xinetd
At 10:05 AM 6/5/01, Charles Cazabon wrote: >David Means <[EMAIL PROTECTED]> wrote: > > > If it's empty, then I'm a relayer, which is a no-no. Without > tcpserver, I > > can't (or haven't figured out how with Xinetd) to populate the > required env > > vars, hence my clients can't send email via qmail-smtpd to domains > not > > listed in rcpthosts, right? > >Correct. It can apparently be done with xinetd, but I don't use it. I have a machine running xinetd in the corner here. David, check out man xinetd.conf. Look for the 'env' and 'passenv' directives. There's also an example (look for 'service rstatd') on how to use it. Todd
Re: qmailanalog usage
Why not let logrotated handle your log rotation, daily if you so desire, and call qmailanalog from a postrotate block on maillog.2? We have a similar setup here, but we're rotating weekly. There's a little perl script that calls qmailanalog and sends its output to a dated file (mail-report-mm-dd-ccyy.txt). About an hour later, another script comes along and adds a pointer to the new file to the reports index. It's only been in place for a few weeks, but it seems to be working fine. That actually reminds me of another question I've been thinking about. Now that I have these nifty statistics, I'd like to know how to interpret them. Sure, I know what 'delivery attempts' means, but what's a good number for that? How high is too high when it comes to average qtime? Is there a document somewhere that outlines that? Perhaps it's not even relevant - after all, the qmailanalog report seems to say more about the servers I'm sending to than my server. cheers, Todd At 08:23 PM 6/25/01, Mark Douglas wrote: >I'm trying to figure out how I should get the stats I want out of >qmailanalog, along with some other things I'd like to do. My main >issue is, if I wanted to do a daily log rotation, would it be feasible >to do the following (using multilog): Set my logfile size to 100MB; at >end of day, have a cron job run that copies the "current" file to >another, dated file; echo > /var/log/qmail/current to empty out the >log file and start fresh. I realize it's not pretty, but the real >issue is, would it cause problems? > >Thanks, > >Mark Douglas - Architecture >Sympatico-Lycos Inc. >All your base are belong to us! Make your time!
virus warnings
I can deal with everything being under /var/. I can deal with the endless questions on subjects covered extensively in the documentation. I can even deal with the venom that seems to ooze from this list with startling regularity. But, please, in the name of all that is good and holy, take three fucking seconds and configure your AV software to *NOT* send the warnings to the list. It's a waste of everyone's time and bandwidth. Most of us (hopefully) don't need the warning, and those that do probably don't deserve to be warned. Just my $0.02. cheers, Todd
Re: Mail Forwarding Service
At 02:44 AM 7/28/01, Philip Mak wrote: >On Sat, 28 Jul 2001, Adrian Ho wrote: > > > Why use a program delivery when you can use .qmail forward > directives? > > "man dot-qmail" for details, and create the necessary .qmail files > > (probably .qmail-youralias in the same directory you put your > domain's > > .qmail-default). > >Well, there's over 10,000 e-mail addresses that would have to be >forwarded. Wouldn't I have to create a .qmail- file for everyone >in >the MySQL database (would there be a filesystem efficiency issue when >I >have 10,000 files in the directory?) That depends on your filesystem. I've just learned of ReiserFS, isn't this the kind of thing that it's good at? >, and also keep these files synchronized with inserts, updates and >deletes done to the MySQL database? How often do you expect it to change, and what triggers the change? Write a cron job that updates the .qmail files periodically with the information in the database. Better yet, update the .qmail file at the same time you update the database. >I figure that it's cleaner, programming-wise, to just lookup the MySQL >database at the time a message is received rather than having to worry >about synchronization. But this lookup script has increased the load >average of the server above 10. There is at least one mysql/qmail integration package floating around, have you looked at any of those? You're going to have a very hard time making this tiny and fast, which is what it needs to be. For every message, you're firing up the perl interpeter, connecting to the database, parsing a statement, executing, and cleaning up the whole mess. All of these things are expensive. You might be able to improve things be writing a daemon (in perl if you'd like) that spins in the background and takes connections from the various .qmail files. That will at least eliminate the once-per-message startup, and you could probably get it to share database handles. That's a lot of work, and a lot of shit to break. cheers, Todd
[OT] tcpserver machine, running amanda?
I'd like to complete the removal of inetd from a server, and run everything under tcpserver. Amanda looks like it needs a UDP connection though, which tcpserver's name seems to indicate it doesn't support. Dan mentions netcat on the ucspi-tcp page, is that the current SOP for doing this? The amanda archives don't have much information on either method that I can find, and the qmail list hasn't talked about it since 97. In that message G2S is mentioned, but it's still in beta four years later. thanks, Todd
