Re: POP3 Cluster
Karsten W Rohrbach [EMAIL PROTECTED] writes: sorry for not elaborating the setup. sure thing, i am talking about symmetrix/connectrix setups, where the fs gets exported as nfs. other setups are out of discussion because of concurrent access to the same fs (and if gfs would be stable on *bsd systems, emc symmetrix would not be an option anymore at all because of the hardware cost and tco). Ahh, okay, I'm up to speed now. Sorry about that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: §K¶OÀ°§A¥IADSL¤Î56K
audit [EMAIL PROTECTED] writes: -BEGIN PGP SIGNED MESSAGE- Am I the only one that this is bugging? According to the headers, someone at the University of Illinois needs to check their machines out. The University of Illinois is where this mailing list is hosted. Received: from 61-216-68-78.hinet-ip.hinet.net (HELO TmpStr) (61.216.68.78) by muncher.math.uic.edu with SMTP; 8 May 2001 22:12:33 - The spammer is sending mail directly from the above dialup account. hinet.net is the place to complain to. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: POP3 Cluster
Karsten W Rohrbach [EMAIL PROTECTED] writes: Steve Kennedy([EMAIL PROTECTED])@2001.05.05 19:08:32 +: You could also use EMC storage as a back-end, not cheap but very flexible and reliable. emc is good as long as it runs. if some pice fails those boxes are gonna fsck forever... Huh? What are you talking about? About the only drawback to EMC is that it's insanely expensive. And I really mean it when I say insane. It's incredibly reliable, though; dual-redundant systems from end to end, at least in the Symmetrix. (The Clarion products are very different and not really the same sort of storage.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: POP3 Cluster
Karsten W Rohrbach [EMAIL PROTECTED] writes: emc uses a bsd based filesystem implementation. No, it doesn't; an EMC Symmetrix doesn't have a file system at the disk level. Are you talking about the partitioning? if one bus fails nothing goes wrong, but if you got unrecoverable data errors on a controller or other bad components, the filesystem gets damaged. Yes, with any disk subsystem if you have undetectable controller errors, bad things happen. due to it's nature, being a ufs/ffs, EMC Symmetrix do not use UFS/FFS unless the host you're connecting to the disk chooses to format the disks that way. If you don't want to deal with UFS, use a logging file system. i personally prefer the netapps (although the filesystems are somewhat limited in size compared to emc or ibm) A NetApp is a completely different sort of machine than an EMC. A NetApp exports files over protocol rather than as a simple SCSI device. Maybe you're talking about EMC's Clarion stuff, which is different, or some of their newer experimental SAN stuff? We've been using EMC disk here for quite some time and I don't recognize anything in your descriptions even remotely like what we're running. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Is qmail best reserved for mailing list server purposes only?
q question [EMAIL PROTECTED] writes: One of the reasons I was interested in qmail was the security aspect of it. I've been impressed that noone has won the reward that is available from Dan Bernstein. This is probably the most negative comment I have seen about qmail while surfing for info: That's because the ORBS folks made completely false statements, were called on it, and don't like being wrong. http://www.orbs.org/otherresources.html Qmail admins: Qmail's current version is secure by default, but earlier versions were insecure. False. Most admins know enough to follow the instructions for securing it before putting qmail into service, however it usually drops ORBS test messages checking for UUCP pathing vulnerabilities - ! pathing - into the admin mailbox. Rather, it tries to bounce them and the bounce bounces as undeliverable. The solution is for ORBS to stop probing systems from which no spam has ever been sent and for which there is no reason to suspect a lack of security. As ! is a standard network addressing indicator, False. Qmail is extremely network unfriendly and generates denial of service attacks on other mailservers in its enthusiasm to deliver as many messages as possible in a short period of time. False. qmail's default configuration is incapable of doing that except possibly to a pathetically undersized e-mail server that would have problems with all sorts of normal deliveries. For this reason it is best reserved for mailing list server purposes only. Do you all agree with this opinion that qmail is best reserved for mailing list server purposes only? No. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: The new RFC's.
Grant [EMAIL PROTECTED] writes: I admit I don't know anything about RFC's and the apparent latest versions for SMTP. What will this mean for qmail. Are there any significant changes in the way it works? Both RFC 2821 and RFC 2822 were tasked with documenting existing practice and cleaning up some historical warts, not with introducing new features (new features were specifically stated to be out of scope). As such, there are no major changes from widespread practice in either, and they are likely to have little effect on qmail. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Ban These Exchange Server Users
Robert Mudryk [EMAIL PROTECTED] writes: If you noticed, all the Virii Reject Messages are from Exchange Servers... QMAIL anti-Virus Scanning like qmail-scanner says [This message was _not_ sent to the originator, as they appear to be a mailing-list or other automated Email message] I know you all are so against it... but don't you think it's time to re-consider installing a scanner on Mailing Lists? No, I think it's time to kick everyone running one of those broken scanners that mails the mailing list off of the mailing list. I could see this as a Denial of Service Attack against a mailing list.. bombing it with viruses to watch all the subscribers reject all the viruses Good reason to remove every person using such a scanner from the mailing list. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Where is tai64nfrac
Jost Krieger [EMAIL PROTECTED] writes:
On Thu, Apr 12, 2001 at 04:17:47PM +0100, [EMAIL PROTECTED] wrote:
For instance at:
http://sunsite.dk/qmail/tai64nfrac
or
http://qmail.sst.com.br/tai64nfrac
AFAIK, (this version) of tai64nfrac is broken, because
printf("%lu.%lu ", seconds, nanoseconds);
suppresses leading zeroes in the fractional part.
There is (finally) a fixed version of my C implementation of tai64nfrac on
ftp://ftp.eyrie.org/pub/software/misc/tai64nfrac.c.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFCs?
David Benfell [EMAIL PROTECTED] writes: So, I give up. I'm guessing other MTA's have at least as many real, documented issues with RFC compliance as qmail. And I only see a couple things that might be important. Am I wrong? What's the deal? There are some RFCs that Dan has chosen not to implement in qmail, and the few complaints about RFC compliance that I've seen backed up with actual data have been about that. The primary ones that I've seen mentioned are DSNs and SMTP AUTH. I understand the reasons for both of these, mind, and am not arguing that qmail should necessarily implement them. Not implementing those extensions certainly doesn't make qmail a non-RFC-compliant e-mail system, just one that doesn't implement some optional features. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: [OT] pine and Maildir (was: Maildir versus malibox)
Peter Cavender [EMAIL PROTECTED] writes: PINE may be limited, but it sure is useful as a quick and dirty console-base MUA. I figured out how to use in in about 3 minutes without having to RTFM. If you've ever had to deal with the code, dirty is definitely an accurate description. But as I said, if I am missing some great GPL MUA, pray tell... mutt is pretty popular and is what we now recommend over Pine for anyone willing to change. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: More on MAPS RSS
Kris Kelley [EMAIL PROTECTED] writes: Forgive me for opening this can of worms again, but I have something that proves that the MAPS RSS *is* listing servers that it suspects are open relays, even when they aren't. Have you reported this to RSS? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: secrets and lies
Al [EMAIL PROTECTED] writes: Two things come to mind the first is the Artistic under which Perl is released The Artistic License was explicitly designed to be part of a dual-licensing arrangement. It's not strong enough to stand on its own; the language hasn't been hammered out nearly well enough. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: secrets and lies
Mate Wierdl [EMAIL PROTECTED] writes: I am reading this book by B. Schneier, in particular, the section `Cracking and hacking contests'. He thinks that contests (like offering $1000 for finding a security hole in a product) are bad for four main reasons, the first reason being that the contests are usually unfair since the author of the software decides what he/she considers a "hole". He's not alone in that opinion; I think that opinion has a lot of merit, although I wouldn't go so far as to say that such contests are *bad*. But I don't think they actually prove anything. He also thinks that even having a software out and used for a few years without incidence does not imply that it is secure. He says, the best way to evaluate the security of a product is to have it audited by security experts. It's worth bearing in mind, when evaluating this opinion, that Bruce Schneier is a security expert that people hire to perform such security audits. He has a point, but it's also unsurprising that he's in favor of the work that he personally does. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: secrets and lies
Adam McKenna [EMAIL PROTECTED] writes: OK, I stand corrected. But you have to realize that this is the same argument put forward by many people pushing closed source solutions over open source ones (that it has been analyzed by "experts"), and invariably many security holes are found anyway. Cases in point, most major closed-source firewall software, MS's shoddy PPTP implementation, etc. I believe that Bruce Schneier, like most (although not all) security and cryptography experts, is pretty strongly opposed to closed-source solutions to security problems due to precisely the sorts of things that you're talking about. I think his point is more that just having the source available doesn't automatically mean that the software has been audited. Having the source be closed is obviously worse, but open source isn't a sufficient condition. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: secrets and lies
Bennett Todd [EMAIL PROTECTED] writes: Could be, people use words as they wish. But if you'll take a visit to URL:http://www.opensource.org/, you'll find that the term was very specifically drafted by a group of people with an agenda, and they've produced a branding service based on an Open Source Definition, which definitely excludes weirdo licenses like djb's. Unlike Open Source, the phrase "free software" strongly predates the Free Software Foundation and they've made no attempt at branding it; rather, they pursue branding the GNU General Public License (GPL), which is stricter than (but compatible with) the Open Source Definition. RMS tries to "brand" the term free software just as much as the Open Source folks try to "brand" the term open source; neither of them have any kind of trademark or service mark on the term (the one on Open Source wasn't pursued) and both of them have been known to argue at great length over the precise meaning of the terms with people who they feel are using them incorrectly. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC822 compliant?
briank [EMAIL PROTECTED] writes: Thanks for the response. I'm still a bit confused, though: If I attempt to inject a piece of mail with a valid, RFC822-compliant address, and qmail rejects it due to some sort of internal formatting it does, does this not defeat the purpose of having an Internet standard to begin with? No, because the purpose of RFC 822 isn't to determine a user interface. It's to establish a protocol for *computers* to talk to each other. As soon as you're dealing with user input, you're outside its scope. That being said, it would somewhat surprise me if qmail-inject with a sane configuration would reject or mishandle any RFC 822 compliant address. BTW, this isn't flamebait (comment for Felix). I'm just trying to figure out why qmail is unable to correctly resolve an address in the format someone@domain Do you mean "someone@domain" as the complete address with no dots on the right-hand side? Bear in mind that RFC 822 contains *no* address canonicalization provisions; if you're expecting your local domain to be appended to the RHS, you're outside the scope. Under RFC 822, the above address indicates that one should deliver the mail to the MX record for "domain." (and as a general rule, TLDs don't have MX records, although it is technically legal). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC822 compliant?
Louis Theran [EMAIL PROTECTED] writes: If you make defaultdomain the empty string, then you get: box@host - box@host. and if the host's name really is ``host.'', there's no problem. Well, yes, there is, because box@host. is an invalid mailbox per RFC 822. Trailing periods are not permitted. (My guess is that djb would call an empty defaultdomain an unsupported configuration.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC822 compliant?
Bruno Wolff [EMAIL PROTECTED] writes: He probably means a domain with no dots. For example: discuss@opennic That's a dumb idea. Anyway, qmail's behavior for such domain names is documented in qmail-header(5): All host names should be fully qualified. qmail-inject appends the default domain name to any name without dots: djb@silverton - [EMAIL PROTECTED] So qmail-inject currently cannot handle mail to such domains. This is arguably a flaw in the interface. qmail itself can handle such mail without any difficulties at the protocol level, as I think could be established by using the qmail-queue interface directly. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: [OT]Help trying to understand rfc822!
martin langhoff [EMAIL PROTECTED] writes: I'm sending mail from a perl script and I have one var (or config setting) for the 'To:' field. This script uses Net::SMTP to deliver its load directly into a sendmail box. I assume that Net::SMTP is breaking this up into multiple separate MAIL TO commands at the protocol level? Now if I insert 2 addresses, like '[EMAIL PROTECTED], [EMAIL PROTECTED]', and there's a qmail at scim.net everything's allright. Now some hosts don't like this: I'm having problems because relay.sion.com rejects my 'To: [EMAIL PROTECTED] [EMAIL PROTECTED]'. Addresses should be separated by commas; your second example doesn't have a comma. Reading RFC822 (at http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html) I can see the appendix A, in the item A.1.5., it looks like it should be valid. In fact at A.3.3. there's an example that looks very much like mine... I'll find a workaround in the meantime, but, am I wrong to think its allright to have a comma-delimited To: field? Comma-delimited To: headers are fine. You can't send a comma-delimited address in the MAIL TO command, but Net::SMTP may do the right thing there. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC822 compliant?
briank [EMAIL PROTECTED] writes: So you're basically saying that qmail can pretty much mung up an e-mail address any way it likes because it's...qmail! No, qmail-inject can munge up an e-mail address any way it likes because the behavior of the program your MUA runs is not govered by any standard whatsoever. I think you missed the fact that RFC 822 is an *Internet* standard and hence specifies what's sent *between* systems. It says absolutely nothing about what happens *on* a system, or what canonicalization processes user interface software may apply to headers. You'll find that sendmail does all sorts of bizarre things with locally injected mail. It doesn't violate RFC 822 by doing so either. Please become more familiar with the nature and scope of IETF standards before using them as an arguing point. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: people are definately starting to harvest emailadresses on this list...
markd [EMAIL PROTECTED] writes: Indeed this is an excellent strategy - if done properly. The problem is, a lot of people don't have the ability to capture all addresses in a domain - and of course user-random@domain is trivially defeated by a competent slicer and dicer if user@domain is valid. There's a simple solution to that. Use user@domain as another spam trap and have your *real* address that you give out to people who you want to have a stable address be user-something@domain and be careful about revealing that something. :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Spam elimination solution based on References header
Felix von Leitner [EMAIL PROTECTED] writes: Spam traps like this rely on you keeping it to yourself. If enough people start using this, spammers will adjust like they now post from domains that exist and put "Re:" in the subject. This spam trap, unlike most of them, require that spammers keep an additional piece of information around in addition to the e-mail address, information that they cannot construct mechanically (provided that you construct the regex carefully and different people use MTAs with different message ID construction patterns, the latter generally being the case). That's a *huge* loss for the spammers; unless tons of people start doing this (and even in that case), they just can't handle that complexity. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: SPAM - Help!
Jack McKinney [EMAIL PROTECTED] writes: Big Brother tells me that Greg White wrote: I am a spammer. I own spamming.pissant.luser.domain. I send mail from spamming.pissant.luser.domain, but I forge envelopes and From: to say that I'm (for example) ibm.com, to beat pattern-matching spam checks, and maybe fool some users that that's really where I'm from. Don't bounces go to ibm.com? How are we, (in the example), as ibm.com, to prevent these bounces from coming to us? Not to mention all the email to [EMAIL PROTECTED], complaining about the spam... Am I missing something? Maybe. If the email is rejected AFTER being accepted by your mail server, then your mail server will bounce it based on the headers. It has absolutely nothing to do with what the victim's mail server does (in this case, ibm.com). It has to do with what the mail servers of the people receiving the spam do. ibm.com has *absolutely no control* over whether or not they receive bounces; there's nothing they can change about their e-mail configuration to avoid them. They'll get bounces from all the sites that accept mail first and then generate bounces. Such as, say, qmail by default, or the entirety of AOL. For example, I want to spam using [EMAIL PROTECTED] as the return address. I find an open relay at mail.irelay.com, so I connect to it and drop off a few hundred thousand copies of my message with my fake from address. You are on my spam list, and your server is rejecting mail via ORBS, which has contacted irelay.com to complain already, and irelay.com is unwilling or ignorant. My message does this: 1. My machine to mail.irelay.com over smtp. accepted. 2. mail.irelay.com contacts your mail server and tries to deliver the message. Your SMTP port rejects it because it comes from an open relay. 3. mail.irelay.com bounces the message to [EMAIL PROTECTED] If this address does not exist, then microsoft.com bounces the message back to mail.irelay.com. Yup. So if you're running microsoft.com's mail servers, you're screwed. You just have to swallow the bounces and hope that someone will close the damn relay and stop the spammer. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: SpamKiller - a /interesting/ product
Peter van Dijk [EMAIL PROTECTED] writes: The phrase 'proverbial IQ of an amoeba' (hope I translated *that* correctly) is one my dad has used at times, and I have the feeling that it's a quite common one. Generally the amoeba is proverbial, not the IQ (but I can see an argument either way). :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Where can I find CYCLOG?
Steve Fulton [EMAIL PROTECTED] writes: I am having trouble finding CYCLOG... I've searched Freshmeat.net and come up empty. If it comes with a particular package, which package? And if (on the odd chance) I have already installed that package, where would I find CYCLOG on the average system? Thanks. It's been replaced by multilog, which is part of Dan's daemontools package. See http://cr.yp.to/daemontools.html. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: No Transport Provider Available
Mark Walsh [EMAIL PROTECTED] writes: What are other people using for EMAil on Win9x systems? Anything else except Netscape? Eudora is the one we support. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: [OT] Achieving Time-Synch at mailserver
Peter van Dijk [EMAIL PROTECTED] writes: But when does xntpd send out requests then? It seems to only do so every once in a while, and if I'm not dialed in at that time, it fails. Most of what clock synchronization software does, though, is to figure out how much your clock drifts naturally and then just keep adjusting for that drift. It only needs occasional external data to correct it's idea of the internal drift, not constant data. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: [OT] Achieving Time-Synch at mailserver
Daniel Augusto Fernandes [EMAIL PROTECTED] writes: I've been using NTP for a long time with success! How does clockspeed compare to NTP? Is there any tai time server? xntpd does two things (well, three, actually). It contacts remote time servers periodically to correct its notion of time, and it determines the "natural drift" of your system clock and constantly corrects for it. It can also provide the time to remote machines that are querying it. clockspeed separates these different functions. You first take a few measurements to establish your clock drift, and then you run a daemon that just adjusts for that known drift and doesn't continue to poll other time servers and adjust. You can periodically take another measurement and see if the drift has changed. Personally, I've looked at the TAI library with interest but I've never seen a good reason to move away from xntpd for time synchronization. It works fairly well, I find it convenient to have xntpd take care of handling changing system clock drift for me (and I have a few machines that don't have consistent clock drift), and I like being able to use any convenient server as a server for ntpdate in a pinch. I understand the xntpd stratum setup and we have a fairly nice setup of multiple stratums here. The clockspeed approach has the advantage of working fine for a system that's only rarely connected to the network, but to me a computer without network connectivity is almost worthless except for playing games (for which clock synchronization doesn't really matter). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: su to alias on RH
Mate Wierdl [EMAIL PROTECTED] writes: I do not understand this comment at all. Under RH 5.2, after doing su - alias the output of whoami was `alias'. Now it is still root. Why do I need a valid shell to be able to do this? I don't know if Red Hat is weird, but under most operating systems if you su to a user, you get that user's shell. If you set the shell to /bin/true, it will then immediately exit, leaving you back as root again. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: linuxpeople thread
Please don't post hundreds of lines of directory listings of the qmail source. [EMAIL PROTECTED] writes: /compile qmail-local.c qmail-local.c:1: sys/types.h: No such file or directory qmail-local.c:2: sys/stat.h: No such file or directory There's something seriously wrong with your system include files; both of those files should be in /usr/include. This is *not* a problem with your kernel sources as another person said (if it were, sys/types.h would be found and linux/types.h would be missing); it's a problem at an even earlier level than that. Your system's development environment is either corrupted or only partially installed at a very fundamental level. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: linuxpeople thread
linuxpeople [EMAIL PROTECTED] writes: I can re-install the entire machine with red hat 6.0 then upgrade every package again, but I don't see the need its a fresh 112 meg install with the various applications upgraded as needed to meet security issues that have arisen as of late. My Linux box says that /usr/include/sys/types.h is part of glibc-devel. Do you have that package installed? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: linuxpeople thread
Frank Tegtmeyer [EMAIL PROTECTED] writes: I suggest that everyone who feels that linuxpeople is stupid should ignore him NOW. Everyone who thinks there is any hope he will get his system up should support him by private mail NOW. While in general I agree with the sentiment of your message, I intend to keep helping people with qmail installation problems on the qmail mailing list, as I think that's what it's for. If Dan disagrees with me, it's his list and he can tell me to stop, but other people not liking to deal with people with a very beginning knowledge of Linux isn't sufficient reason for me to stop helping them. The first time I installed Red Hat, I too found it extremely unintuitive that the package named glibc-devel is *not* for developing glibc, like it sounds, but is instead needed if you intend to compile anything at all ever. I've since then gotten used to the -devel naming convention, but I still find it somewhat odd and I'm happy to help someone else out who had the same misunderstanding that I had and did the same thing that I did the first time I installed Red Hat (namely not install that package and then wonder where all my include files went). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: C API for queueing messages
Jay Balakrishna [EMAIL PROTECTED] writes: We are trying to find out what is the most efficient way of queueing the message in qmail from our C Programs. So, would like to know if there are any C API's that are available for queuing messages. Basically I am looking for library routines that act as the native submission interface(API) for qmail. You're going to need to write your own library, probably as wrappers around pipe opens to qmail-queue. ftp://ftp.eyrie.org/pub/software/majordomo/mjinject may be a decent starting point; it's in Perl, but should be possible to convert to C. The queue sub is the one that does what you're trying to do. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: qmail + freebsd = reboot
Tim Hunter [EMAIL PROTECTED] writes: BSD is not my choice of OSes but a sig 11 in linux is commonly a memory error, almost always a hardware error. It's also quite frequently a symptom of an overheated CPU, particularly if it occurs randomly and is difficult to reproduce. If you're overclocking, that's the first place that I'd look. See http://www.bitwizard.nl/sig11/. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: New Installation
Ramzi S Abdallah [EMAIL PROTECTED] writes: What patches I needs to have a secure and stable installation of qmail. None. I've been running qmail for years now and I've yet to install a single patch. I use qmail 1.03 straight out of the box. You need patches if you need particular features that stock qmail doesn't provide, such as LDAP support or authenticated SMTP, but for straightforward mail service you don't need any of them. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Timezone
Alexander Pennace [EMAIL PROTECTED] writes: On Sat, Sep 09, 2000 at 08:12:41PM +0200, Thomas Zehetbauer wrote: I have been alarmed by a posting on linux-kernel that there are several mail applications and MTA's that emit incorrect date/timestamp values. I sent a test message using qmail-inject and found that timestamps are generated using UTC but the correct timezone specification (UTC/GMT/+) is missing. Instead the pseudo suffix - is used which to my limited knowledge means that the system has no knowledge about it's timezone. Because mutt is emitting correct timestamps I do not suspect a misconfiguration of my system. This is a very frequently asked question. http://qmail.faqts.com/ No, that isn't the question he's asking. That's an answer to the question "why doesn't qmail use the local time zone," which isn't the problem. Thomas, the difference between + and - is that the former indicates that the originating machine is physically in the Greenwich time zone, whereas the latter indicates that the machine may be in any actual time zone but the time was generated in UTC for some reason. - is therefore the correct time zone for what qmail is doing; + would incorrectly imply that all qmail servers were running on machines in England. For more details, see: http://www.ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-08.txt | The form "+" SHOULD be used to indicate a time zone at Universal | Time. Though "-" also indicates Universal Time, it is used to | indicate that the time was generated on a system that may be in a local | time zone other than Universal Time and therefore indicates that the | date-time contains no information about the local time zone. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Open relay test.
Sean C Truman [EMAIL PROTECTED] writes: I agree the ORBS test are dumb and don't really pertain to 95% of the mail servers out there. But if you are in the ORBS database then some mail is going to be rejected. Except that ORBS doesn't actually add people who "fail" that test but don't relay the mail. So it's not true that your tester is using the same tests as ORBS is. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Timezone
David Dyer-Bennet [EMAIL PROTECTED] writes: In my years of working with computers, networks, and email, I don't think I've *ever* seen an MUA that performs this theoretically desirable function. Gnus does, of course. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: [OT]Mail::* Perl modules to validate email address (RFC822)
martin langhoff [EMAIL PROTECTED] writes: I'm trying to validate an email address as per RFC822, and, even though I've seen a lot of quick'n'dirty regexps to do so, I'd like to use actually RFC compliant code, known to work. Right now I'm perusing the Mail::* modules (docs and code), just grabbed from CPAN, looking for validating code, and finding none whatsoever. Has anyone experience with this modules? Doesn't Mail::RFC822 have validation code? I thought it did. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Russ' rblsmtpd test robots.
Ben Beuchler [EMAIL PROTECTED] writes: I just implemented rblsmtpd using the MAPS DUL. I sent a message off to Russ' testing bot and received the following reply: MAPS has recently dropped the TXT entries from their zones due to zone size problems; perhaps that's the problem? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: tai64n -- why?
David Dyer-Bennet [EMAIL PROTECTED] writes: Yes, when I first looked at it. As is often the case with Dan, I just disagree. It's not straight text in the sense I mean; it's not human readable. Of all the strange choices Dan's made that I've encountered in working with qmail, this is the first one that I fail completely to understand. All the others, I see the tradeoffs and I see why he chose as he did, even if I might have chosen otherwise. This one makes zero sense. It's non-functional. It doesn't connect to the way I work. syslog timestamps are amazingly annoying to try to parse. TAI64 is trivial to parse. This is a significant improvement. ISO date/time format would also have been easy to parse, and I would have been slightly happier with that, but TAI64 is definitely a *huge* improvement over syslog if you want to do anything at all automated with the logs. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Now redhat's mailling lists have been removed to mailman and postfix
Irwan Hadi [EMAIL PROTECTED] writes: , PayPal/Confinity, Red Hat's mailing lists, Hypermart.net, Casema, ^^ Rediffmail.co.in, Topica, MyNet.com.tr, FSmail.net, and vuurwerk.nl. at www.qmail.org/top.html should be removed right ? It can be replaced with all of the Perl development mailing lists, all of which are using ezmlm-idx. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: multilog patterns
Ben Beuchler [EMAIL PROTECTED] writes: I'm trying to use multilog's pattern matching to not log the non-stop health checks from our load balancers. This is the command line I'm using: exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t \ s1000 \ -*216.243.128.254* \ -*slb01* \ /var/log/qmail/smtpd And here's the log entries I'm trying to filter out: @400039824fe91baaa634 tcpserver: pid 9376 from 216.243.128.254 @400039824fe91c11535c tcpserver: ok 9376 mail.bitstream.net:216.243.128.140:25 slb01.bitstream.net:216.243.128.254::1035 multilog filter patterns don't work like filename globs. You want: '-* * * * * *:216.243.128.254' instead. (There are several other ways of writing it too.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: multilog patterns
Russ Allbery [EMAIL PROTECTED] writes: Ben Beuchler [EMAIL PROTECTED] writes: I'm trying to use multilog's pattern matching to not log the non-stop health checks from our load balancers. This is the command line I'm using: exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t \ s1000 \ -*216.243.128.254* \ -*slb01* \ /var/log/qmail/smtpd And here's the log entries I'm trying to filter out: @400039824fe91baaa634 tcpserver: pid 9376 from 216.243.128.254 @400039824fe91c11535c tcpserver: ok 9376 mail.bitstream.net:216.243.128.140:25 slb01.bitstream.net:216.243.128.254::1035 multilog filter patterns don't work like filename globs. You want: '-* * * * * *:216.243.128.254' Sorry, '-* * * * * *:216.243.128.254*' -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Philip, Tim (CNBC Asia) [EMAIL PROTECTED] writes: Thanks for all the interest in my original posting to this list. My question was:- "Is it possible to stop qmail from generating multiple bounce messages when mail with a forged sender address is received for multiple bad (non-local) mailboxes?" I guess the simple answer is, NO. (Is this correct?) Not quite. The answer is that qmail doesn't do this under normal circumstances. It only does this if you're accepting mail that you're not sure is valid and then forwarding it to another system for delivery; if that happens, the single message with multiple recipients ends up being split apart into multiple messages. I bet you could find ways of doing exactly the same thing to sendmail. I really don't think this is a problem peculiar to qmail. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Peter van Dijk [EMAIL PROTECTED] writes: On Mon, Jul 24, 2000 at 02:03:32PM +0800, Philip, Tim (CNBC Asia) wrote: PS I don't want to get involved in the ORBS debate [although it is most probably a bit late ;-)], but one of the original orbs probe messages in my mail logs had the following line:- Received: from unknown (HELO relaytest.orbs.vuurwerk.nl) (unknown) Does this mean that vuurwerk.nl is part of orbs and postings from people at vuurwerk.nl shouldn't be viewed as the comments of an innocent mail administrator?!! Our company hosts the relaytester because some of our techies believe the ORBS-project is worth supporting. All opinions I post are mine, possibly but not necessarily shared by zero or more of my co-workers. For what it's worth, while I strongly disagree with the position (see my other messages), I *can* understand why people may feel that the existing blacklists are insufficient and something like ORBS is needed. And I've yet to hear anything from anyone @vuurwerk.nl to make me feel about them the way that I feel about orbs.org; they don't seem to get involved in things like the recent business with AboveNet. So in answer to the original question, I'd expect at least some folks at vuurwerk.nl to have a bias, but I've yet to see anything from them that didn't seem reasonable to some degree. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Ricardo Cerqueira [EMAIL PROTECTED] writes: Wrong. You can perform zone transfers on MAPS' nameservers :-) That'll give you the entire list. Without signing the document? That sounds like a bug, since they say on the web page that they didn't intend to allow that without someone signing. Have you mentioned that to them? (More to the point, though, can you get the RSS? That would be closer to what ORBS is doing; getting the RBL gives you a bunch of networks and a bunch of sites that aren't open relays and isn't nearly as directly useful.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Peter van Dijk [EMAIL PROTECTED] writes: www.orbs.org/database.html ORBS only provides dumps consisting of hosts over 30 days old. From RSS, tho, a current list is easily obtained as Alan outlines there. That claims a straight-forward zone transfer works. Grr. Okay, off to mail the RSS folks; I think that's a bad idea. I know that you can "brute force" a zone transfer by just querying every IP address, but this is also very detectable by the operator of the list, and I'd *hope* that they'd block off sites that were doing that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Ricardo Cerqueira [EMAIL PROTECTED] writes: On Mon, Jul 24, 2000 at 12:12:32PM +0100, Ricardo Cerqueira wrote: and now, it refuses the query :-) I hate replying to myself, but it still works. Must have been a momentary failure. I've mailed them and made the same arguments that I was making here. I still find the ORBS approach a lot more blatant about helping spammers, given that they offer a neat file download (most spammers have no clue as to how to do a zone transfer), but I don't think either of them should be offering the data in that form. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
David Dyer-Bennet [EMAIL PROTECTED] writes: I don't mind ORBS publishing the list of known open relays, and I don't mind ORBS accepting open-relay reports based on scans (or even running their own). I find RSS not adequate and RBL badly inadequate (though I continue to use it to help them be the big stick you describe, a goal I definitely support and which I have seen work well). Fair enough. I'd like to use ORBS, but in fact I find the politics intolerable and the arbitrary behavior too risky. I don't know the details of the alleged "spamming" -- it sounds like they're bulk-mailing stuff to the admins of open relays? That too, yeah, although I can see some justification for that. I'm not all that overly comfortable with it *when they don't have a spam in hand*; if they have a spam in hand, I think it's entirely and completely reasonable to contact the server, but when it's never been spammed through, it's mildly more borderline in my mind. But no, I was talking specifically about their probes. Several of their probes use both mangled return paths and mangled recipients that look like their local. Any mail setup where the SMTP listener doesn't know what accounts are valid (not only qmail, but also any number of different firewall or secondary MX setups) is going to generate internal double-bounces from that that end up in the postmaster mailbox. ORBS is aware that they're dumping mail into the postmaster mailbox. If they only did a test when they had evidence that the system was open, I can accept that. I can even accept retesting open relays. But when the system doesn't relay and has never relayed, constantly *retesting* it and dumping that mail in the postmaster's mailbox seems wrong. Sure, it's not that much spam, but when you have a number of hosts with mail setups like that, it starts slowly adding up. And of course, their answer to it is to just press delete. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
David Dyer-Bennet [EMAIL PROTECTED] writes: And either ORBS is blowing *amazing* clouds of smoke or MAPS is really putting the boot in in their private way, in ways I can't approve of. ORBS is blowing *amazing* clouds of smoke. Either that, or Alan Brown has literally no clue whatsoever how Internet routing works. This is one of the things that's rather annoying those of us who have heard a lot of the story from various sides. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Eric Cox [EMAIL PROTECTED] writes: I can't comment on this latest battle of wills between MAPS and ORBS, because I know nothing of BGP routing. Short version: ORBS's upstream ISP is intentionally asking AboveNet to advertise a netblock that includes ORBS despite AboveNet making it clear precisely what will happen when they do that. AboveNet is just obeying their contract with their customer, essentially. ORBS's upstream is trying to solve the problems they're creating themselves by not dealing with this some other way by advertising separate routes to ORBS space, which should work fine, except that they can't seem to do it competently. The contention that AboveNet is somehow intentionally attracting ORBS traffic is hogwash; they're advertising what their customer is asking them to advertise and have made very public precisely what their internal blocks are. The even more outrageous claim is that AboveNet is somehow making the separate routes flap, which from all the available independent evidence appears to be nothing more than either a pure lie or complete ignorance. ORBS has plenty to complain about with their immediate upstream, and in fact the list of addresses on their web page to complain at (said web page otherwise being full of horribly distorted misinformation) includes a bunch of people at their immediate upstream. But they're all bundled under the category of MAPS people, when of course they have nothing to do with MAPS at all, or AboveNet either for that matter. And, of course, there's the minor point that I'm pretty sure AboveNet has been blocking ORBS since long before they bought MIBH and aquired Vixie as a VP. But in the last one, when ORBS listed in the RBL, ORBS was totally in the right. I saw grown men, (admins!) trying to defend the position that by ORBS sending up to 16 messages through their servers a few times a _year_, ORBS was abusing the email system. You're aware that some machines *which didn't relay* were being tested by ORBS as frequently as once a *day*, aren't you? Or are you just going by Alan Brown's account of what he does, which tends to be a little... sanitized? You're also aware that ORBS continues to spam the postmasters of machines which have never relayed in their entire existence? You're also aware that ORBS provides a service to spammers, providing a downloadable database of open relays and essentially inviting spammers to please use them? That, all by itself, is entirely and completely within the domain of spam support services and should get them put directly on the RBL. I think it's actually rather inconsistent of the RBL that they're *not* on it for doing that, although I can understand the political reasons for not doing so given that Alan Brown seems to have an endless capacity for duping people like yourself who aren't looking at what's actually going on and are buying his stories hook, line, and sinker. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Eric Cox [EMAIL PROTECTED] writes: Russ Allbery wrote: You're aware that some machines *which didn't relay* were being tested by ORBS as frequently as once a *day*, aren't you? Or are you just going by Alan Brown's account of what he does, which tends to be a little... sanitized? Once a day? Doesn't the test take almost a week? It did in my case. It takes however long Alan decides to make it take. The rules change arbitrarily depending on who the target is and what mood he's in, and they're not reflected on the web pages. And no, I don't believe anything unless I test it myself. During the last bruhaha, I reported my own mailer as an open relay, so I could have it tested. After it was tested, I reported it again, to which ORBS responded that it had been tested recently, and could not be tested again for 30/60/90 days (I don't remember which). You haven't annoyed Alan. It seems to me that if ORBS is testing every day, there's some kind of problem. Why not try to work with them to get the problem fixed, instead of declaring "nuke the site from orbit" immediately? Because of the sheer number of these sorts of "problems" that have occurred, generally denied to have ever existed. It's all anecdotal, I realize. But I don't hear these things about RSS or about the RBL. You're also aware that ORBS continues to spam the postmasters of machines which have never relayed in their entire existence? Wasn't aware of that. I get spam from them on a regular basis. Sure, it's a lot less in volume than the spam I get from other sources... at least right now. But I've made them aware that it's unwanted, those machines have *never* relayed, and it continues. It's unsolicited, and it's sent in bulk. It's spam. And it does nothing to stop spam. You're also aware that ORBS provides a service to spammers, providing a downloadable database of open relays and essentially inviting spammers to please use them? All of which are blocked by ORBS. Ah, I see, so extortion is a good way to fight spam? RBL provides a similar list of spam-friendly domains, all of which are blocked by RBL. You cannot do more than check a single IP address and get a yes or no response without having a signed agreement with the RBL team. At the moment, I don't believe they even allow you to download their whole list at all since they're reworking the agreement. ORBS, in stark contrast, makes the entire list available as a convenient download on their web site, suitable for being fed into spamming software. Seems to me that part of the goal here is to force people into using ORBS by increasing the spam of everyone who doesn't, or at least it sure gives that impression. Hardly. You've got it completely backwards. I'm looking at my own spam numbers (that's what going on), and seeing that ORBS is helping much more than MAPS. MAPS is a bunch of separate black-lists. ORBS is not comparable to the RBL; their goals are completely different. The purpose of ORBS is to filter spam. The purpose of the RBL is not to filter spam. The purpose of the RBL is to be a sufficiently large stick that it will scare people away from spamming in the first place, and it's quite effective at being that. ORBS is more directly comparable to the RSS. RSS requires evidence that a relay is actually being spammed through before it lists them, and RSS doesn't scan people's networks. ORBS doesn't care if the relay has ever been abused, and ORBS actively scans. Because of that, ORBS is more effective at blocking spam. ORBS is also more effective at blocking things that aren't spam. The false positive rate and the politics I have to accept by using ORBS are too much to ask, as far as I'm concerned. Whatever happened to helping other people make their services better, rather than declaring all-out war on them and trying to destroy them? Why don't you ask Alan that? Maybe he should stop picking fights. We're misplacing all of the anger that we have for spammers onto ORBS simply because a few test messages find their way in just like spam, and declaring war without even thinking it through. No, sir, I think you should speak for yourself. I'm not misplacing any anger. I'm angry at ORBS because they're abusing the Internet in precisely the same way that spammers do, supposedly for a good cause (which spammers also claim) and in the process they're making fighting spam *harder* because people who want to put a stop to abuse of their resources are confused with fanatics like Alan Brown. I've tried very hard to give ORBS the benefit of the doubt, but particularly with this latest all-out attack against AboveNet I'm seeing a lot more in common between ORBS and the spammers than between ORBS and the legitimate users of the Internet. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Eric Cox [EMAIL PROTECTED] writes: Some would argue that MAPS abused their position when they listed ORBS - they do have a competing service, do they not? And ORBS is both spamming and operating a spam support service under the definition of that service. Suppose you run a security consulting service and as part of that service you publish vulnerabilities in commonly used products, as well as provide a network scanner. Now suppose you find a security vulnerability in someone else's network scanner. Do you publish that vulnerability? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Michael T Babcock [EMAIL PROTECTED] writes: If, however, you admit that it causes problems for sendmail installations, and you admit that a lot of sites use sendmail, then you'll probably agree that defining "good netizen" would include "limiting outgoing connections to a particular MX" ... to some reasonable number (heck, you can detect what the foreign MTA is when you connect usually ... ) This is all nice and good in theory, but you should be aware that you're going down a rathole with this particular discussion. The only person who's going to be able to modify this behavior of qmail and make it stick is Dan, Dan has heard all of these arguments before, and so far he doesn't seem to be buying it. You're rather far from making any *new* arguments here, regardless of whether any of the rest of us find them persuasive or not. If you really want to have separate queues and streaming of mail through a single connection per peer rather than qmail's behavior, you may seriously want to consider using Postfix instead of qmail. I personally prefer qmail, but trying to use a software package against the express design intention of its primary author is rather like banging one's head repeatedly against a brick wall. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Michael T Babcock [EMAIL PROTECTED] writes: Considering the number of useful patches that aren't part of the qmail distribution that the average qmail admin seems to be using, I disagree. I disagree with the contention that the *average* qmail admin is using any patches at all, if by average you mean the mode, and possibly even the median. I'm running qmail on a half-dozen different machines and I've never used a third-party patch to qmail for anything. I've never needed to. If your qmail installation is dependent on patches not written by Dan, I will echo my same recommendation: Seriously consider using another MTA. My opinion as a system administrator is that attempting to use and support packages plus third-party patches not blessed by the package maintainer is a recipe for disaster. With all due respect to the qmail-ldap people, for example, I'd be much more confident in Postfix's LDAP support because it's part of the main distribution. I'd make an exception for ezmlm-idx, given that Dan has all but blessed it as a good third-party product to use for people doing more than non-trivial mailing lists, but last I'd heard, he was rather annoyed at the qmail patches, not welcoming them. That means that he's likely to be willing to break them without giving them a second thought in later releases, whereas he may work closer with the ezmlm-idx folks if he releases a new version of ezmlm. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: orbs.org accuses qmail of mailbomb relaying!
Petr Novotny [EMAIL PROTECTED] writes: Please stop that. When was the last time you saw a crashed mailserver due to getting too many mails? And what was the software? It happens with sendmail all the time, which is most of what people are running. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Maildir support for emacs vm
Dave Sill [EMAIL PROTECTED] writes: Mutt is a fine mailer. Really. I use it at home and occasionally at work, but its MIME support doesn't compare to VM's: it can't display in-line images or HTML/rich-text because it's character-based. And current Gnus is another quantum leap ahead of VM. (I don't even mind HTML e-mail as much any more; w3 mode does a nice job of it. And it does an excellent job handling inline images, and a fantastic job of handling multiple character sets.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Announcing qmail-autoresponder version 0.90
Bruce Guenter [EMAIL PROTECTED] writes: On Fri, Jul 14, 2000 at 06:28:44PM -0700, Russ Allbery wrote: I consider it to be an absolute requirement for any autoresponder to not reply to a message that isn't addressed to the recipient it is acting on behalf of. And that's part of why it's rate limited. Rate limiting will indeed cover up a multitude of sins, but it's still possible even with a rate-limited autoresponder to generate responses to mailing list traffic. Another significant ameliorating factor in your implementation, though, is... By default, it will only reply to a particular sender address once an hour, no matter how many are sent. H. Ezmlm uses a different recipient address each time (but ezmlm will also add both a "Precedence: bulk" and a "Delivered-To: mailing list ..." header). ...that it sounds like you're sending your replies to the envelope sender, and therefore it's somewhat less likely they would end up on the mailing list. There are various schools of thought on this topic. My experience is that sending the autoreply to the From/Reply-To address is generally what people expect and that sending it to the envelope sender can often be confusing or unsuccessful. But using the envelope sender is certainly cleaner from an implementation standpoint, and helps avoid a few of the problems of mailing lists, at least for mailing lists managed by software. I understand the argument you're making, and it's valid to a degree. If you want to contribute a simple GPL-able RFC822 parser, I'll make it a feature of my autoresponder. That's not the main problem. That's a tractable technical problem, even if annoying. The real problem is that unless you're willing to let your autoresponder generate significantly fewer responses than the person would expect, you have to deal with alternate forms of their address. For example, there are literally hundreds of rra@*.stanford.edu address forms that all deliver to [EMAIL PROTECTED], and unfortunately in some cases a not insignificant number of them are in use for various things or due to various historical reasons. You're correct that I overstated my feelings somewhat, and determining whether a given e-mail address was addressed directly to the recipient in the To or Cc header is not a fully solveable problem. The rather ugly hack that I'm currently using is: my @addressees = ($addressees =~ /(?:^|\G|\s)(\S+)\@\S+\.\S+\s/g); (and then applying some canonicalization to deal with removing the leading bracket, supporting varient forms that our LDAP database supports, and removing the "sub-address" parts). This fails to recognize all sorts of weird addressing forms that are fairly uncommon in practice. This is reasonable for my purposes since the algorithm "fails closed"; if it can't find the recipient, it doesn't send an autoreply. More worrisome is the fact that it only considers the username portion, in part to deal with the address varient problem mentioned above (and because that was the historical behavior of the autoresponder that I was rewriting to use LDAP instead of our old method of handling vacation). In practice, though, that seems to work reasonably well. This is certainly not a substitute for rate limiting or for watching for list headers and not replying to those messages. (My autoresponder also refuses to reply to any message coming from an envelope sender ending in -request or containing any of the words daemon, postmaster, mailer-daemon, mailer, root, or majordomo.) In combination with those other checks, though, the additional check makes me feel a lot better about releasing the autoresponder on an unsuspecting Internet. Autoresponses to mailing list traffic are a personal annoyance of mine; every time I, for example, send mail to the CVS mailing list, I get three or four vacation messages and I'm extremely tired of it. Given how much it annoys me personally, I wanted to be reasonably certain that I wouldn't be the cause of someone else being similarly annoyed. Or list-id, or mailing-list, or x-mailing-list, or x-ml-name. I should actually add a test for ezmlm to check if a "Delivered-To:" line starts with "mailing list ". I believe ezmlm always adds Mailing-List and Precedence; given that, I don't see a reason for adding another rule. (Precedence has been an informal standard for many years now, and no reasonably maintained mailing list management package really has much excuse for not using it, IMO.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Announcing qmail-autoresponder version 0.90
Bruno Wolff [EMAIL PROTECTED] writes: Reflectors are something sendmail has. You can have system wide aliases that just deliver the message to more addresses. The alias can actually point to file. For these kinds of messages, the tests you are using won't see the mail as list mail. If you don't mind not responding to bcc'd messages, checking for the recipient's address(es) in the headers is a very good way to detect mass mailings. I consider it to be an absolute requirement for any autoresponder to not reply to a message that isn't addressed to the recipient it is acting on behalf of. Anything else is just begging for the sort of exponential autoresponder meltdown that's happened on some mailing lists in the past (most notably faq-maintainers). Making this kind of test does add some complications. You need to have a list of addresses for the current recipient. You have to worry about equivalent addresses that are too numerous to list manually (typically this would be case insignificance and extension addresses). Yup. Very annoying, but necessary. Otherwise, you'll end up sending autoreplies to mailing list traffic, which is an absolute no-no even if the mailing list isn't "properly" tagging messages with a Precedence header. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: want to leave
Petr Novotny [EMAIL PROTECTED] writes: That's a really easy way to unsubscribe: From your .qmail file, bounce every message you receive from the list. ezmlm will unsubscribe you automatically, and pretty fast. Takes 20 days, actually, I believe. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Any reason not to run supervise?
Petr Novotny [EMAIL PROTECTED] writes: "It eats up space in process table." As in "sendmail is superior to qmail because it doesn't eat up space in process table". (Overheard this just an hour ago...) I've encountered this some too; it's an interesting psychological effect that I think slows the adoption of qmail a bit. Because qmail is so modular and actually exposes its internal interfaces to the degree of having separate binaries running, people think that it's considerably more complicated than sendmail (I keep hearing this). This is, of course, really not true; sendmail does way more inside that big monolithic black box. But because it hides all the complexity, it scores some marketing points. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: big-* patches and FD_SET()
Uwe Ohse [EMAIL PROTECTED] writes: On Wed, Jun 14, 2000 at 11:58:20AM +0200, Toens Bueker wrote: How can I increase this 'hidden limit'? You can try what is described in /usr/include/sys/select.h, but i don't know whether this will do something good: The C library might know too much about the 1024 internally. Raising the limit in this fashion is supported and should work correctly for Solaris 7 or later, IIRC. It's a Solaris-specific hack, though. (Solaris, being a SysV derivative, really wants you to convert your software to use poll instead of select.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Suggestion for mailing list manager?
Ben Beuchler [EMAIL PROTECTED] writes: On Tue, Jun 06, 2000 at 11:13:51PM -0400, John R Levine wrote: * Majordomo 2: looks swell but is in perpetual alpha, dunno about VERP I've never liked majordomo... But that's just personal opinion. Majordomo 2 is a completely different program than Majordomo 1; it's arguable whether it should even have the same name. * ezmlm: no digests, no web, no MIME What you want is ezmlm-idx, a fully supported patch for ezmlm that does all that you want except the web stuff. And for that there is ezweb. I *think* that's what it is called... Anyway. Very spiffy. Very fast. All sorts of crunch, peanutty goodness. Agreed there, actually. If you're already running qmail, I think ezmlm-idx is best of breed. * GNU Mailman: looks superswell, but I'd rather not have to learn python WHAT'S WRONG WITH LEARNING PYTHON It's annoying? :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Does someone knows what is this about?
Bruno Wolff [EMAIL PROTECTED] writes: I think I will be able to use them again as I only want to block inputs and outputs, since the ORBS seems to catch sites faster than the RSS. That's because RSS requires evidence that the relay is actually being abused, whereas ORBS will list any machine that's open regardless of whether it's being abused or not (by design). I disagree with ORBS on a lot of things, but it's good that this particular choice is available to people. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: DRAFT RFD - comp.mail.qmail - Comments Sought (Was: qmail advocacy questions)
Magnus Bodin [EMAIL PROTECTED] writes: Isn't the general shift nowadays (since 1994 and forward) from news to mailinglists just because of the big problem with spam-address-collectors on usenet? If that's the case, you're all already doomed; this mailing list has been gated to two or three different newsgroups for years now. I've noticed because my messages to it keep showing up in Deja. That's common for most large mailing lists. In my personal experience, Usenet is slightly more of a harvesting risk than large and well-known mailing lists but it isn't *that* significant. Pretty much everything pales in comparison to web harvesting now, actually. (And of late, I get a reasonable amount of Chinese spam and almost no other spam; I'm down to averaging around five pieces of spam a day and I do essentially no filtering. But .edu addresses seem to have a very different spam pattern than .com addresses.) I'm a huge fan of Usenet for a lot of things, and an advocate of Usenet, but it's also my experience that technical fora tend to start as either newsgroups or mailing lists and generally don't move well from one to another. You couldn't turn, say, comp.unix.programmer into a mailing list without losing a lot of the strong points of the group, and similarly I don't think this mailing list would convert to a newsgroup well. And I don't think there's enough qmail discussion to really warrant both this mailing list and a Big Eight newsgroup. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: DRAFT RFD - comp.mail.qmail - Comments Sought
Guillermo Villasana Cardoza [EMAIL PROTECTED] writes: I know this is not a qmail question... but I've been trying to get my hands on an news server address as I have none from where to see any newsgroups. Would someone please ... give me one :) if it is not much trouble http://www.newsguy.com/ will let you purchase basic Usenet access using your own ISP for Internet access for some fairly low price (something like $30 a year). You can also use http://www.deja.com/ for free, but the interface sucks. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: DRAFT RFD - comp.mail.qmail - Comments Sought (Was: qmail advocacy questions)
Darren Wyn Rees [EMAIL PROTECTED] writes: On Tue, May 30, 2000 at 10:18:39PM -0700, Russ Allbery wrote: I'm not sure this is a good idea, mostly because I don't see the distinction between the newsgroup and this mailing list ^^^ Funnily enough, I don't see much of a distinction between comp.mail.mutt and [EMAIL PROTECTED] Maybe it's a "usenet thing". What do you think ? Not reading those, I'm not sure. Usenet tends to attract more basic questions from beginners, at least at first, and mailing lists tend to have slightly more in-depth discussions, at least for most of the technical topics I'm aware of where I read both the newsgroups and the mailing list (comp.lang.perl.* vs. perl5-porters is a great example). If we were swamped by basic questions that might have better been dealt with in Usenet, I could see the point of that sort of distinction, but it really doesn't feel to me like that's currently the case here. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Qpopper 2.53 remote problem, user can gain gid=mail (fwd)
John Gonzalez/netMDC admin [EMAIL PROTECTED] writes: Qpopper works fine for us, there is also a server-mode directive to change this default behavior to be more like a regular pop server, it will NOT copy the file and cause chunking on the HD. We use qpopper currently in a high-volume environment, but I definitely wouldn't describe it as "fine." We have a bunch of local patches to try to reduce the amount of completely pointless work that it does by default (or even the slightly non-pointless but still very time consuming stuff, like updating Status headers, which isn't necessary in our particular environment), and it's still a total hog. We're looking at switching to Cyrus instead for a variety of reasons, including better support for Kerberos, a better on-disk storage format, integration with IMAP (which we're starting to need), a better way of managing users, and in general a cleaner and seemingly more reliable package. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: A Good Book On Qmail
Rodney Edwards [EMAIL PROTECTED] writes: Qmail ezmlm is now getting so popular that someone has to get their arse in gear and get a book to print. The Idea is a certain winner so com'on O'reilly, Que, or Sam's if your listening in get your finger out guys where drowning out here. I don't believe that publisher interest is the hold-up. To publish a book, someone has to write it first, and one would hope that the people doing so would actually know a decent amount about qmail. :) Those people are somewhat rare; qmail hasn't been around for that long yet. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: i-love-you-letter - Claus Farber.
dsr [EMAIL PROTECTED] writes: Claus has been attaching a signature to his messages which looks like an attachment to a borken mail reader, but not to any compliant mail reader. This isn't an entirely fair characterization, in my opinion. He's adding a signature which looks roughly like a uuencoded section, although would fail a detailed regex check. Many people, myself included, are using mail readers that have an *option* to scan the body for uuencoded segments and "convert" them on display to attachments, treating them the same as MIME attachments, for convenience in dealing with legacy encoded messages. Claus's signature also fools Gnus to the degree of showing up as an attachment. I think this is harmless; I just ignore it. Sure, it could use a more detailed check (like making sure each line except the second to the last starts with M), but that would also make it slower, and I really don't mind the false positives. (And I do mind having the body scanning be slower.) In other words, it's possible for Claus's signature to show up as an attachment in a non-borken mail reader; it's just not a big deal. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: DRAFT RFD - comp.mail.qmail - Comments Sought (Was: qmail advocacy questions)
Darren Wyn Rees [EMAIL PROTECTED] writes: Below, I've quoted a DRAFT RFD proposal for comp.mail.qmail. I'm not sure this is a good idea, mostly because I don't see the distinction between the newsgroup and this mailing list and I also don't expect the people using the mailing list to really want to move to a newsgroup. Without the core of people on this mailing list that know qmail very well and answer most of the questions, the newsgroup is unlikely to be all that useful, and I haven't heard much indication that those people would really prefer a newsgroup. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Qpopper 2.53 remote problem, user can gain gid=mail (fwd)
John Gonzalez/netMDC admin [EMAIL PROTECTED] writes: Unknown. The advisory specifically mentions 2.53 -- i can tell you this. 2.53 _was_ safe from the PREVIOUS exploits (ie. the ones that worked on the 2.51, etc) but this appears to be a new exploit in a different function of the program. 2.53 appears to be vulnerable. Also, the advisory suggests upgrading to 3.1b1 (which i did) and says that it's a safe version (for now, anyway) The 3.x series has been having *tons* of security problems, including stuff that was previously fixed in 2.x. I really don't trust it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: securing pop3 sessions
Russell Nelson [EMAIL PROTECTED] writes: Len Budney writes: I'm afraid the best way is also the only way, and it doesn't exist. You cannot use POP3 without sending passwords in the clear. Doesn't anybody implement APOP?? Even better, there are innumerable different authentication mechanisms possible once you use SASL, including ones considerably better than APOP, and POP3 definitely supports SASL. You can definitely use POP3 without cleartext passwords. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: The current status of IETF drafts concerning bare linefeeds
Pavel Kankovsky [EMAIL PROTECTED] writes: (*) If yes, what extra functionality was provided? (Apparently, it was not an ability to transfer non-English plaintexts because you do not know how to interpret bytes you receive without MIME (or MIME-like) metadata.) It was, in fact, an ability to transfer non-English plaintext and your contention is wrong in a lot of circumstances. There is a *lot* of mail in the world, not written in English, sent between two people who are both using the same language and encoding, which isn't marked with MIME metadata but nonetheless is interpreted just fine by the affected parties. This is particularly common with mail internal to organizations. This is an ongoing argument; I've seen plenty of examples both in Europe and in Asia where unlabelled 8-bit content, while not the best way of doing things, is very common and doesn't cause problems. Anyway, that's also a bit apart from what Dan was talking about, as I would assume that Dan was talking about the 8BITMIME SMTP extension, not the MIME conventions for body labelling. The former is even less necessary than the latter. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Setting up qmail for university
Suresh Kumar R [EMAIL PROTECTED] writes: 1. I dont want all students having a valid nis account to have an email address. The email addresses facility should be for a subset of the NIS data base. How can it be done? I assume that the qmail server should be a nis client/server and there is no other way. Read qmail-users; you can either explicitly list the users that should receive mail or list the exceptions who shouldn't. Note that when running qmail-pw2u, you'll want to replace /etc/passwd with ypcat passwd | or the like. 2. Should the nis server and qmail be running on the same machine physically? Probably not. It's generally a good rule of thumb to run one major service per machine if you can. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: I want to leave this list
Troy Frericks [EMAIL PROTECTED] writes: OK, so they are stupid. Now, let's help them out so they don't have to waste bandwidth and everybody's time. Lets send them several messages each day with something in the body that all mail clients can read that tells them how to unsubscribe. Let's not. It breaks MIME structured bodies, which are often useful for particular purposes. It breaks some signed posts. It's useless information for 99% of the recipients. And I'm really sick of seeing mailing list posts accumulate more and more worthless junk to the point that it's practically more unwanted bytes in my mailbox than spam is. It's rather simple to skip over the messages from the completely lost people; footers that any intelligent person doesn't need are both intrusive and ugly. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: multiple auto-reply messgs...(simple??)
Marcelo J Iturbe [EMAIL PROTECTED] writes: Maybe I am going around this all wrong. I am having troubles creating the auto-reply scripts. The script is in PERL and I am trying to capture the message. I tried to do a print on ARGV and ENV but both arrays are empty. How do I grab the email message? The full incoming message is available on stdin. See the qmail-command man page for the details. I would also like to modify the subject line of the message before it gets sent to the "common" pop account. You can't do this without creating a new mail message and resending it to the common POP account address. You also shouldn't need to; I presume that the purpose is to support filtering, which you can just as easily do based on the To and Cc headers (or even the Delivered-To header). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: How do you do it?
Steve Wolfe [EMAIL PROTECTED] writes: I wish I could go on about the things that people said to me, the things I said to people, and the things I heard other techs say - but it would be a novel. Technical support is definitely a unique learning experience No kidding. Taught me the importance of having a chatserver, IRC channel, or *something* like that real time where you can bitch about stuff with other people without having to stop what you're doing. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: accustamp|tailocal|matchup
Kins Orekhov [EMAIL PROTECTED] writes: Yes, I have tried that and it didn't work for me. Comments for tai64nfrac says: Expects the input stream to be a sequence of lines beginning with @ (1), a timestamp in external TAI64N format, and a space. Replaces the @ and the timestamp with fractional seconds since epoch (1970-01-01 00:00:00 UTC). (2) The output time format is expected by qmailanalog (3). (1) - lines in my logs beginning with: 1999-11-24 17:43:07.542160 status: local 0/10 remote 0/20 This is not what tai64nfrac expects (at least, no @ at the beginning). You've already run tai64nlocal on your log file. tai64nfrac doesn't expect that (because I don't do that; I just run tai64nlocal when I need to, since it's fast enough). (2) - looks like tai64nfrac supposed to replace with the same time format as I already have (see (1) ) No, that's just documentation of what the epoch is. tai64nfrac does produce the output you're expecting. Can someone educate me about those time formats (TAI64/TAI64N, fractional, etc.) I'm really confused about them. qmail-analog expects seconds and fractional seconds since epoch. For documentation of TAI64, TAI64N, and related subjects, see http://cr.yp.to/proto/utctai.html. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: temporary failure warning message
Kai MacTane [EMAIL PROTECTED] writes: In the case of a failure to deliver, the user will not get *any* warning about it until queuelifetime has passed. I think that the option to have qmail (or a plug-in or add-on program) deliver a message back to the user stating that the message hasn't gone through yet, after an admin-configurable length of time (presumably somewhere from 4-24 hours), would be a useful thing. Our users constantly reply to such messages saying "please stop trying to deliver that message." *sigh* Once we switch away from sendmail, I'm strongly inclined to turn them off. I'd also significantly reduce the queue lifetime; honestly, if the message can't be delivered in two or three days, most e-mail users these days seem to have already concluded it will never get there and get really confused when it comes through. Our mail server that just sends out bounce messages already has a queue lifetime of just one day, but that's a special case (a very large number of those messages will just double-bounce and get silently discarded). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: temporary failure warning message
Racer X [EMAIL PROTECTED] writes: From: "Brian Johnson" [EMAIL PROTECTED] this was my point earlier, you can't always count on getting an error message if there is an error, because there's _always_ a chance that the message will be lost without a trace. so if you do make errors Not if you have a halfway decent MTA. Writing bulletproof software is not impossible. There are only so many states the message can be in. Yeah, but just because a bounce message was generated doesn't mean that the user gets it. I've seen a depressing quantity of users that put all sorts of random trash in their envelope sender and never see any of their bounces. Ideally, I'd track down the double-bounces and get the user to fix their configuration so that they see further bounces, but there really isn't enough time in the day for any significant user base. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Recipient MTA is rejecting bounces
Yusuf Goolamabbas [EMAIL PROTECTED] writes: Hi, I have a qmail-1.03 machine saw in my queue a few bounces in them. Also, looking at my logs I saw the following message @40003905243f24daf1b4 delivery 34: deferral: Connected_to_204.68.180.50_but_sender_was_rejected./Remote_host_said:_451_#@[]..._unresolvable_host_name_[],_see_RFC_1123,_sections_5.2.2_and_5.2.18./ A bounce message bounced. When this happens, qmail generates a double-bounce and tries to send it to the local postmaster address. It uses the completely invalid envelope sender "#@[]" to ensure that double-bounces can't then bounce again and generate mail loops. You apparently are forwarding postmaster mail to another system which is doing resolveable name checks on envelope senders, and doesn't like qmail's special double-bounce sender. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Recipient MTA is rejecting bounces
Yusuf Goolamabbas [EMAIL PROTECTED] writes: That is true, However I changed the forwarding to another system which doesn't do resolveable name checks and yet the messages are continuing to go the old system. (I changed /var/qmail/alias/.qmail-postmaster) and restarted qmail. Is this appropiate ? You didn't actually need to restart qmail. The problem that you're seeing is probably just that previous messages are already in the queue and qmail's already read the older .qmail file and figured out what addresses to send them to. It'll keep trying until they bounce, but all new messages should now be going to the new machine. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: temporary failure warning message
Rogerio Brito [EMAIL PROTECTED] writes: So, three days may be a little short. Or should this mean that secondary MXs, once fought against begin to become a necessary condition? I use secondary MXes for all of my e-mail precisely because I want control over the queuing if a system goes down. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Little Qmail problem with 'HELO'
tonnage [EMAIL PROTECTED] writes: Does anyone know how to either hardcode the HELO msg's or have it take the host name from the "From:" field in an email? See the man page for qmail-remote: CONTROL FILES helohost Current host name, for use solely in saying hello to the remote SMTP server. Default: me, if that is supplied; otherwise qmail-remote refuses to run. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Qmail failing ORBS test :-(
Mark Tippetts [EMAIL PROTECTED] writes: One of my mail servers was put in ORBS today. I can't use ORBS myself, but I value what they're doing, and I consider the problem that got me there a real one. The test we failed involves a header in the format "rcpt to:foo!bar". qmail-send grabs this address and appends the address in .../control/envnoathost, resulting in [EMAIL PROTECTED]. This is then delivered in the normal way, using MX records, to the primary hub for the lynxus.com domain, which runs sendmail. Sendmail does it's thing with the UUCP addressing, and I wind up in ORBS. Sounds like your problem is with your sendmail box. Why don't you turn off !-addressing on your sendmail system? That would seem to neatly solve the problem. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: VERP RFC
John White [EMAIL PROTECTED] writes: On Wed, Apr 12, 2000 at 12:07:09AM -0700, Russ Allbery wrote: None. By the time the message reaches the SMTP level, VERP has already been done. VERP is not an SMTP feature. *cough* Actually, you can use the user-@domain-@[] format when talking to qmail-smtpd, and the VERP expansion will be handled. Er Huh. I could have sworn that qmail rejected that, but apparently it doesn't. My apologies for the incorrect information. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: HTML mail and this list...
Peter Green [EMAIL PROTECTED] writes: On Wed, Apr 12, 2000 at 04:25:54PM -0400, Peter Green wrote: This is something I don't understand. I use mutt, and HTML mail appears totally sane in my reader. It's also treated exactly like text when it comes to quoting. :/ I take this back. If an e-mail is *all* HTML, then mutt (by default) is SOL. Ever since Gnus added the ability to render HTML using w3-mode, these discussions tend to surprise me becaues I don't even notice the original was in HTML. :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: qmail and tripwire...
John W Lemons [EMAIL PROTECTED] writes: I just added /var/qmail to my tripwire policy, and of course, lots of files change frequently. Any suggestions on a policy for this server? perhaps just include /var/qmail/bin and /var/qmail/control? Any others? Here's what I use: /var/qmail R-2 /var/qmail/bin/qmail-queue R /var/qmail/control/badmailfrom L-i !/var/qmail/queue That checks all the man pages, which is probably unnecessary (although it is possible to do shell escapes from inside *roff, so...). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Defending qmail's odd file system to the great unwashed
Ben Beuchler [EMAIL PROTECTED] writes: While pushing for the implementation of qmail at work, the other admins tend to attack rather inconsequential stuff, like it's somewhat odd file structure ( /var/qmail/bin? Who puts executables in /var??? ). I do, all the time; I install INN in /var. :) I like the fact that that is the only thing they can find to disagree with, but can anyone share the logic behind it? I'm sure it must be irrefutable, considering the source, but I can't seem to track down an explanation anywhere... I would assume it has something to do with the twin goals of putting the mail queue in /var like it normally is and keeping all of qmail together in the same place. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: A very simple question
Paul Schinder [EMAIL PROTECTED] writes: I get around 200 messages a day myself, but very little of that gets saved. I find filtering with maildrop, using courier-imap and Eudora or mutt as clients to be a good solution for that kind of volume. Sounds to me like you're saving a lot, and you might want to look into saving into a database for long term storage. Or more to the point, just make more aggressive use of IMAP's built-in capabilities to have multiple different folders. Each one should be a separate directory, and then you won't have lots of messages in the same directory. I have somewhere in the range of a couple hundred incoming folders (actually nnml groups in Gnus), one for each mailing list, role address, or personal mailbox I have, and only keep in those inboxes things that I actively need to respond to; other stuff gets moved off to long-term storage mailboxes. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Qmail Relay Question; A Newbie Speaks
iv0 [EMAIL PROTECTED] writes: 1) you dump the output: 21 /dev/null In the interest of random correction... this is a common shell output redirection mistake. The above does not send stdout and stderr to /dev/null; it sends stdout to /dev/null and stderr to wherever stdout was going before it was redirected. The reason why is that redirections are parsed from left to right, and 21 *dups* file descriptor 1 and sends 2 there. So later changes to the disposition of file descriptor 1 have no effect on 2. Observe: $ echo "this goes to stderr" 2 this goes to stderr $ ( echo "this goes to stderr" 2 ) /dev/null 21 $ ( echo "this goes to stderr" 2 ) 21 /dev/null this goes to stderr Order is significant in Bourne shell I/O redirection. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Bounce Loops?
Adam McKenna [EMAIL PROTECTED] writes: No. If you installed qmail correctly, you would have created an account called mailer-daemon, which is required to be RFC compliant. I believe the only required e-mail account is postmaster. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Tried dnsname - fails!
Petr Novotny [EMAIL PROTECTED] writes: got dnscache-0.92 from cr.yp.to, compiled, run ./dnsname 204.71.191.17 The result is dnsname hogging 100% of CPU (the same way tcpserver does). This means two things: 1. I can temporarily solve the problem with tcpserver for SMTP service by disabling reverse lookups. 2. There's some bug in the DNS library. (run against a local dnscache) windlord:~ dnsname 204.71.191.17 dnsname: fatal: unable to find host name for 204.71.191.17: temporary failure (run against a local BIND cache) windlord:~ dig 204.71.191.17 @171.64.7.77 ; DiG 2.2 204.71.191.17 @171.64.7.77 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; 204.71.191.17, type = A, class = IN ;; ...truncated ;; Total query time: 7 msec ;; FROM: windlord.stanford.edu to SERVER: 171.64.7.77 ;; WHEN: Tue Mar 14 06:25:33 2000 ;; MSG SIZE sent: 31 rcvd: 31 I'm not seeing the runaway problem that you are, but reverse DNS for that IP address definitely does not appear to be working. Excerpts from dnstrace: 1 name.iad.gblx.net 209.130.187.10 name.iad.gblx.net 3600 A 204.152.166.155 1 name.iad.gblx.net 206.165.6.10 iad.gblx.net cache NS name.roc.frontiernet.net iad.gblx.net cache NS name.phx.frontiernet.net name.iad.gblx.net 3600 A 204.152.166.155 12 17.191.71.204.in-addr.arpa 209.130.187.10 ALERT: lame server; refers to . 12 17.191.71.204.in-addr.arpa 206.165.6.10 ALERT: resolution took more than 1 second ALERT: lame server; refers to . -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: qmailanalog examples
Andrés [EMAIL PROTECTED] writes: (I wish that D. J. Bernstein, the programmer of qmailanalog, reads this mailing list so he improves the documentation) I'm betting from the state of qmailanalog that it's going to become obsolete with the next release of qmail. I wouldn't advise putting too much effort into it because of that. It's just a hunch, though. I think Dan was working on the next release of qmail and got distracted by the annoyance that is the state of DNS libraries, and as soon as he gets a stable release of his DNS tools out we're likely to see more activity on the qmail front again. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Slightly OT: Bcc - who is repsonsible
Timothy L Mayo [EMAIL PROTECTED] writes: The Bcc header should be removed by the MUA prior to sending. Anything else means it is NOT a Bcc! Every Unix mail client I'm aware of that uses /usr/lib/sendmail or the equivalent as the mail sending interface passes Bcc to it and expects it to deal with it. qmail-header(5) says: Every message must contain at least one To or Cc or Bcc. qmail-inject deletes any Bcc field. So it's not quite true that *all* MUAs must concern themselves with this. Of course, the original question probably concerned an MUA that thought it could speak SMTP to a mail server when it actually wasn't speaking SMTP at all (it probably also expects unqualified addresses to work). The solution may be to run ofmipd for such clients, from the mess822 package. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: SMTP in distributed DOS
Pavel Kankovsky [EMAIL PROTECTED] writes: The error message is quite long. In fact, it is probably longer than most email addresses, even with additional "rcpt to:". If you send an empty message to many bogus recipients (limited only by the amount of virtual memory available to qmail-remote), you can get 100% amplification easily (compared to your own network traffic). 100% amplification isn't particularly interesting. Most of the existing DoS attacks give you an order of magnitude of amplification or more. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: SMTP in distributed DOS
Dirk Harms-Merbitz [EMAIL PROTECTED] writes: Neither bouncing messages nor return receipts make sense for ordinary messages. I disagree. 1) Hacker uses a tool to root compromise a few thousand home computers. At which point they launch a smurf attack, which is considerably less traceable and less preventable than what you're proposing. Once that problem is solved, then I'll worry about this. 4) Amplification is very high. You send 100 bytes to generate a 2000 byte error message. That's 2000%. Even worse, how do you ever trace this back or make it stop? Received points you directly at the compromised hosts, making this inherently inferior from the cracker's standpoint than any attack which can be performed with forged source addresses. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: qmail-inject and attchments
Russell Nelson [EMAIL PROTECTED] writes: Russ Allbery writes: TAG [EMAIL PROTECTED] writes: Is there a way of specifying a subject and attaching files using qmail-inject from the command line - the man page is not helpful in this respect?? No. qmail-inject doesn't know enough about the message structure to be able to do that. But there are certainly packages that can do this; I believe Mutt is one of them. I think he's looking for /var/qmail/bin/mailsubj. It doesn't "attach files" unless you consider the following an attachment method :) uuencode "file-you-wanted" | \ mailsubj "this is the file you wanted" [EMAIL PROTECTED] Given that he wants to attach a file, I believe he's looking for Mutt, which can do real file attachments from the command line IIRC. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
