RBL-type header checking
I've written a filter in Python that scans for Received: lines and checks IP addresses found therein against a configurable list of RBL type services. It is in beta stages and definately under development, but it is very functional (doesn't crash for me anymore). http://www.fibrespeed.net/code/spamcheck.tar.gz It uses threads to look up multiple IPs simultaneously and adds a configurable header after applicable Received: lines in the form: X-SPAM-service: notice from TXT This allows the user to delete or re-file messages based on these headers instead of just having the mail deleted by their ISP. Its GPL'd and I'd appreciate any constructive feedback you might have as well as patches from the Python gurus out there. -- Michael T. Babcock CTO, FibreSpeed
Re: RBL-type header checking
http://www.fibrespeed.net/code/spamcheck.tar.gz 404 Thanks ... http://www.fibrespeed.net/~mbabcock/code/spamcheck.tar.gz -- Michael T. Babcock CTO, FibreSpeed
Re: Inter7 introduces new software: vQregister
How inefficient do you think PHP is? What do you consider to be so much faster, native code running as a CGI? Have you benchmarked the two programs? - Original Message - Not everyone has a single box devoted to Apache with PHP modules. In fact, many people run a large amount of time consuming processes. Efficiency is always a factor, when it can be taken into account. Web based products should always be concerned with efficiency.
Re: qmail-pop3d not working?
On some systems, it can be helpful to do a grep -i pop /etc/services to find out what the nomenclature is as well. FYI (to the original poster), that POP3 you misspelt (un*x is usually case sensitive) is just looked up in a file like /etc/services and the port substituted in. - Original Message - It means change the POP3 to pop3 and try the command again. If you get the same error, try pop-3. If none of those work, substitute 110 instead. It's not necessary to include the quotes.
Re: qmail-pop3d not working?
4. Oh, and you haven't told us whether you followed instructions exactly when setting up qmail-pop3d/run. Do the instructions really say to use POP3 in uppercase? The page he referenced at http://www.faqts.com/knowledge_base/view.phtml/aid/8225/fid/223 does indeed have POP3 in uppercase. Dave Sill may wish to update that with a comment or two.
multilog: unable to lock directory
One of the 6 supervised services on one of my gateways stopped responding (tinydns) yesterday afternoon. On the screen was "unable to lock directory /var/log/tinydns:", so I did an "svc -t /service/tinydns/log" and it worked fine. Since the line that generates that log output exits 111, how would terminating the supervise process help? Thanks.
Re: Tcpserver
Robin S. Socha wrote: * Sumith [EMAIL PROTECTED] [010327 04:16]: Side note: would you *PLEASE* turn off HTML in your mail and fix your line width - you're wasting other people's resources and make your messages unnecessarily hard to read. http://learn.to/edit_messages Further side note: To improve the s/n ratio around here, would you cease responding to people whose comments you don't like, whose editors tweak you the wrong way or who have funny haircuts? Your "side notes" have been going on for _years_ on this list and they aren't terribly profitable from the looks of the archives.
recordio, but not the whole message
I would like to be able to stop recordio after a certain number of lines and/or after the first empty line (end of headers) to be able to record the headers of all messages in the logs, but not the bodies, and more importantly, not the attachments. Is there any way I could pipe the output from recordio through another program in the midst of my /service/smtp/run script's series of pipes, or should I write an external script / program to handle it?
Re: qmail-pop3d bug
Peter van Dijk wrote: Not if it's calculated as the file is written to the Maildir. True, but that hurts writing performance. Have you tested this? It doesn't seem that qmail has ever been CPU bound -- and if the CPU has spare cycles while writing, then counting lines and adding bytes for CR/LF won't hurt writing performance at all. -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Being verbose in error messages
Just an FYI to the group, this is what we've come up with for one of our clients' configurations of qmail-notify. qmail-notify notifies senders that their E-mail did not reach the intended recipient within a certain amount of time and optionally CC's the network administrator (which it is configured to do in this case): -x- Your message has been received by %s but has been undeliverable to the listed recipients for at least %s. The mail system will continue to attempt to deliver your message to these recipients for a total of %s. Your network administrator is aware of this situation. This message is for your information; you do not need to resend your message at this time. If the message below is time-critical, consider faxing or calling the intended recipient. You will be notified again only if this message ultimately fails to reach one or more of the recipients. Recipient(s): -x- This _may_ finally be verbose enough to keep the users from E-mailing their mail administrator with "Julie didn't get my E-mail yet!" -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Re: recordio / logging problem
Daniel Kelley wrote: this sends all recordio output to the terminal, not through syslog. following a couple of examples on this list, i inserted 21 directly after qmail-smtpd, but that generates 'Ambiguous Ouptut Redirect'. This is probably just a stupid shell thing (i'm using csh on linux), but i don't understand it. | splogger instead of | splogger will redirect stdout and stderr. -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Re: What is so sad... Re: OK I give up!!!
Sean C Truman wrote: I can download Redhat for free and so can you. They sell support for the product so they can have funding to continue the development. Just as OpenBSD sells t-shirts and CD's to help fund the project. only difference is that OpenBSD hasn't started selling support yet. We actually download it before installing it on clients machines, then inform them of their options for support from us as well as from RedHat. OpenBSD may not sell support, but I know several companies that do. I hope those companies donate some of that profit back to OpenBSD either as cash or by hiring developers. -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Slowing down for Exchange servers
I have a client who does a lot of business with a company that's using an MS Exchange server. Their server tends to crash when my client "hammers" them with E-mails. Is there any way to set the maximum remote concurrency on a per-host basis, or a patch to allow this? echo "2" MAXREMOTE/mx.blah.com echo "500" MAXREMOTE/mx.cr.yp.to ?? -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Re: Selective relaying -Nonstandard style, tough one. Anyone got any ideas? A challenge!
Orie wrote: I am hoping to set up a Qmail (my favorite) smtp gateway (our mail is already routing out one, exchange's sucks) that can somehow allow relaying based on "FROM" (Aka from [EMAIL PROTECTED]) or allow the relay based on a keyword in the message. Or perhaps someone has a better idea? Why not use AUTH SMTP patches? If your E-mail clients support authenticated SMTP (many do), then you don't need to add those clients to a relay list at all. See http://www.qmail.org/
Re: Possible problem with qmail-qmtpc patch
On Sun, 14 Jan 2001 20:25:44 +0100, Jurjen Oskam wrote: On Sun, 14 Jan 2001 13:39:01 -0500 (EST), Russell Nelson [EMAIL PROTECTED] wrote: That's a misconfiguration. I'd rather that the email bounced than it got delivered via SMTP silently. It could be that someone unaware of ... delivered via qmtpd but it is failing to run for some reason. If we fall back to smtp, they'll never know that it's failing unless they're watching their qmail logs carefully. But isn't that a bit in contradiction with the concept of backup MX'es? If the goal is to deliver E-mail securely and quickly, falling back to (a presumed functional) SMTP server fits the bill. If the goal is to use QMTP "just because its there", then Russ' comments make more sense. -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Re: some strange logs.
"Jagadish.N" wrote: I want to generate mail statistics from my Qmail server. It should give me bytes of messages passed and number of smtp if possible pop connections attempted. I don't use multilog. Log messages are dumped to the screen and not to syslog. Can any one tell me howto generate statistics and enable logging in Qmail I hope you're willing to start using multilog since that's the (best?) way to store your logs for stats parsing. Have you looked at the qmail stats program (name?) that uses matchup zoverall, etc. for an overview of your stats? -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Re: secrets and lies
Paul Jarc wrote: So when a lot of people download the files, they don't know what the licensing is and have to ask on the list(s) True, but not relevant to the question of what is legal. The question is what the author permits the user to do -- this is what a license is about. Since the author gives no implicit license, we all come down to IANAL legal battles over what is implied by his other writings. A license would clear (most of) this up -- that's the issue. He wrote it all -- its all DJB's theories -- they may be right or wrong, but he's not a lawyer so its not even really worth trusting his theories at all. Have you even read rights.html? Many times unfortunately. When talking about what might be the correct interpretation of the law, it says "Some people think ..." and "Other people ...". It doesn't say "I think". He re-iterates specific thoughts in the form of hearsay. The overall picture of the file is his theory on implied rights of the user of software. Since he does not quote case law (which would be valid in the USA or Canada at least) or other legal documents, the majority of that file constitues DJB's theories. Are you saying that these are simply false statements, and that no one actually holds the views that Dan says some do? That's not necessary for what I said originally, and you know it -- so its not worth a flame-war, is it? Even if so, why does it matter? He says "I promise I won't sue you for copyright violation for downloading documents from my server." Like I said -- where's the disclaimer from his employer if he's ever used university time to write that software? Would you be more satisfied with something like "I hereby waive my right to sue ..."? It still wouldn't be a contract. He could still go back and edit it. You'd still need others' copies to support your claim that you got it legally. In fact, there's no guarantee that any document would form a legally binding contract as contracts must be accepted by both parties in many (most?) countries and "click" style licensing has proven not binding in some countries. This is a point the GPL (just an example) makes by reminding the user that they can either accept the license as given, or ignore it, but if they choose to ignore it, they get no rights whatsoever to modification or redistribution. There's also no statement that he wrote any of his software on the University's time. More appropriately, there's no statement that he didn't. He could publish a statement (by himself, or by University officials) that he in fact is the copyright holder, but why would you trust such an explicit statement over the implicit one, since that statement could be false anyway? Because then I could show my good faith that the statement was true, which makes a legal case in my favor -- depending on an assumption considering the lack of such a statement is strange. If I really cared, I'd want a signed document from the University. Otherwise, the present situation is as good as any other. The present situation is clearly not as good as a well-written license and disclaimer. -- Michael T. Babcock, C.T.O. FibreSpeed http://www.fibrespeed.net/~mbabcock
Re: secrets and lies
Paul Jarc wrote: ... I don't see ambiguity in them [dist.html or softwarelaw.html or rights.html] ... Are you not as analytical as those who criticise the situation? -- Michael T. Babcock, C.T.O. FibreSpeed http://www.fibrespeed.net/~mbabcock
Re: secrets and lies
Paul Jarc wrote: "Michael T. Babcock" [EMAIL PROTECTED] writes: Since the author gives no implicit license, we all come down to IANAL legal battles over what is implied by his other writings. A license would clear (most of) this up -- that's the issue. A license has the potential to be just as ill-worded, confusing, or extremely technical as anything else. A clearly worded, easily supportable legal document would be good, regardless of whether it were a license. As DJB has said ... 'so?' How does that make this argument any different? Nobody asked for a poorly worded license ... ;-) Right. So a non-contractual license wouldn't necessarily be better than a non-contractual, non-license legal statement. Yes, it would be -- because (as I understand it) you have the right to waive your rights -- such as by putting something into the public domain (as Dan has done with libtai). A license gives rights to others -- Dan's current documents talk about the rights he thinks you have under the law as it is. The present documents are as good as a license *for some purposes*. For other purposes, such as packaging, we'd want irrevocable permission to redistribute. But this permission need not take the form of a license, and a license need not grant that permission. The ideas are compatible, and often come together, but they're orthogonal. I'll agree that a disclaimer might be beneficial in either case for good-faith purposes; I don't know enough to support or refute that. -- Michael T. Babcock, C.T.O. FibreSpeed http://www.fibrespeed.net/~mbabcock
Re: secrets and lies
Just like many others, IANAL, but ... Paul Jarc wrote: "Pavel Kankovsky" [EMAIL PROTECTED] writes: But there are ABSOLUTELY no references to dist.html or softwarelaw.html in the source tarballs. So what? So when a lot of people download the files, they don't know what the licensing is and have to ask on the list(s) -- if he refered to those URLs at least (in all distributions) and/or included text versions (is it really that hard?), people would know what they're getting. I see no theories of his there. The only part there he attributes to himself is: He wrote it all -- its all DJB's theories -- they may be right or wrong, but he's not a lawyer so its not even really worth trusting his theories at all. which makes it clear to me that downloading, e.g., qmail-1.03.tar.gz won't get me in trouble. No, because there's no statement about whether the University he works at thinks that they own the Copyright on software he may have worked on while being paid by them -- he doesn't include a waiver statement by them either. In fact, the only thing that's very clear from his documents on Copyright is that he either doesn't like licenses, or he is afraid to use one because it won't hold up in court and he'll lose the control he likes having. Both those reasons are valid to me, btw. -- Michael T. Babcock, C.T.O. FibreSpeed http://www.fibrespeed.net/~mbabcock
Re: secrets and lies
Paul Jarc wrote: It's the same situation as with, say, Emacs. The GPL doesn't give you permission to get a copy of Emacs; it only specifies what you can do once you have. The nearest I could find to explicit permission to download it is "By FTP we provide source code for all GNU software, free of charge." at URL:http://www.gnu.org/software/software.html#HowToGetSoftware, and that covers only the GNU site itself, not mirrors. I think rights.html is clearer. For a lot of people, being able to obtain said software isn't the problem -- its the right to use it in the ways they wish to do so in the long term. That's what licenses are about. The fact that GNU software happens to be mirrored all over the globe pretty much eliminates the obtaining factor ... especially since anyone who has a copy has full rights to redistribution under the GPL. -- Michael T. Babcock, C.T.O. FibreSpeed http://www.fibrespeed.net/~mbabcock
Re: secrets and lies
Raul Miller wrote: On Fri, Nov 17, 2000 at 10:43:50PM -0500, Al wrote: Don't care. What I care about is what the words mean in an actual language. In this case English. Oh? And what does "OSI Certified Open Source Software" mean in an actual language, in this case English? OSI == "Open Source Initiative" I believe ... http://www.opensource.org/osd.html I do not recognize OSI as a standards body Sounds like a personal issue. But I'm interested in how you assign meaning to "OSI Certified Open Source Software" given your refusal to recognize something that you're willing to talk about. I don't understand that either ;-). -- Michael T. Babcock, C.T.O. FibreSpeed http://www.fibrespeed.net/~mbabcock
Re: secrets and lies
Charles Cazabon wrote: However, as far as qmail goes: all the crackers in the world have had access to the qmail source code and design documentation for years, and none have yet found an exploitable security hole. You could consider that a fairly thorough audit-by-fire. There is no proof any were trying either. -- Michael T. Babcock, C.T.O. FibreSpeed http://www.fibrespeed.net/~mbabcock
Re: secrets and lies
Adam McKenna wrote: On Tue, Nov 14, 2000 at 09:11:32PM +0100, Matthias Andree wrote: Mr. Schneier is respected for his expertise and cryptography, and just because he states that head money for bugs is no good, does not make him an M S type weenie. You're right, Bruce Scheiner is a god, and I'm really sorry for disagreeing with him. No, no ... this is a djb list -- HE is god, and Bruce is just respected ;-). -- Michael T. Babcock, C.T.O. FibreSpeed http://www.fibrespeed.net/~mbabcock
Re: secrets and lies
Bennett Todd wrote: 2000-11-14-16:37:06 Lipscomb, Al: "Free Software" as promoted by the Free Software Foundation (FSF) is a different thing. I belive that the DJB software is Open Source, but not free. 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. I must disagree with you here -- the FSF does indeed spend time and effort to make sure that the term "Free Software" brings the FSF to peoples' minds. Feel free to read the recent discussion between a 3D library programmer and RMS (last week's slashdot articles?) -- RMS spends much time pointing out that he will talk about "free software" but not "open source" because "open source" is one thing and "free software" is what the FSF is about.-- Michael T. Babcock, C.T.O. FibreSpeed http://www.fibrespeed.net/~mbabcock
Re: Postfix: This release introduces DSN style notification of bounced or delayed mail, as per RFC 1894.
On Mon, Sep 25, 2000 at 09:34:27AM +0200, Olivier M. wrote: As seen on freshmeat.net this morning... [ed. (Postfix now uses notifications as per RFC 1894) -- because of long Subject: ] Any chance so see such improvments to qmail comming? Depends on whether you actually consider this an "improvement" as opposed to an invasion of privacy. Please explain why you feel that RFC 1894 describes an invasion of privacy (or, to be fair, a potential one). Part of 1894 is to try and track failed deliveries on mailing lists (in a less efficient way than Dan's solution, mind you). A major part of the goals of 1894 from my reading of it is to allow the reporting of potential error conditions from different mailing infrastructures operating on the other side of SMTP gateways (which there are a lot of).
Re: Postfix: This release introduces DSN style notification of bounced or delayed mail, as per RFC 1894.
Read http://www.faqs.org/rfcs/rfc1894.html (honestly, read the first few pages at least). Basically it tries to solve issues that VERP does not. It doesn't solve the bouncing issue as well as VERP, but it tries to establish a standard way to communicate between MTAs and MUAs about whether a message has been successful and, if it was not, why and according to which MTA. Peter van Dijk wrote: On Mon, Sep 25, 2000 at 09:34:27AM +0200, Olivier M. wrote: As seen on freshmeat.net this morning... Any chance so see such improvments to qmail comming? No, because DSN is not an improvement. It's a bug. It is a misdesigned fix for a problem that can be solved much better with VERP. What is DSN, anyway? Can someone explain?
Re: Postfix: This release introduces DSN style notification of bounced or delayed mail, as per RFC 1894.
On Mon, Sep 25, 2000 at 12:30:03PM -0400, Michael T. Babcock wrote: Read http://www.faqs.org/rfcs/rfc1894.html (honestly, read the first few pages at least). The right way to support this, in qmail, would be to write a small little program you can drop into your .qmail file, to report successful delivery. Part of the point seems to be having a standardised notification system, which, if its functional, is a good idea. About a third of the way down the RFC they have a nice ASCII drawing of what happens if you have a mail system running behind a gateway and how the message notifications are handled if the necessary hosts support DSN. It seems somewhat bulky (lots of long fields -- looks a lot like a message header), but (fairly) functional. I'd like to see some of it implemented just to be able to say that qmail continues to adhere to the useful RFCs ...
Re: Postfix: This release introduces DSN style notification of bounced or delayed mail, as per RFC 1894.
On Mon, Sep 25, 2000 at 12:30:03PM -0400, Michael T. Babcock wrote: Read http://www.faqs.org/rfcs/rfc1894.html (honestly, read the first few pages at least). The right way to support this, in qmail, would be to write a small little program you can drop into your .qmail file, to report successful delivery. Part of the point seems to be having a standardised notification system, which, if its functional, is a good idea. About a third of the way down the RFC they have a nice ASCII drawing of what happens if you have a mail system running behind a gateway and how the message notifications are handled if the necessary hosts support DSN. It seems somewhat bulky (lots of long fields -- looks a lot like a message header), but (fairly) functional. I'd like to see some of it implemented just to be able to say that qmail continues to adhere to the useful RFCs ...
Received: based SPAM blocking
I want to run the IP addresses from the Received: lines in a message header through something like rblsmtpd to block spam that was relayed to me. So I got all ready to set up my system-wide filters when I realised that DJB didn't split rblsmtpd up into smaller pieces (joke) ... so I wondered if anyone else thought it would be beneficial to have one program that did the lookups against the RBL, etc., and have rblsmtpd run it to do those lookups, as well as other programs that wanted to. Instead of: Connection - rblsmtpd (do lookup) - send back brief SMTP message. Have: Connection - rblsmtpd - send back brief SMTP message. | rblcheck(?) (do lookup) This way, other filters could call rblcheck (better name?) as well. Just wondering if I've missed the boat on why this would be a bad idea, or if it just hasn't been done yet. Sample headers ... --- Delivered-To: [EMAIL PROTECTED] Received: (qmail 25872 invoked from network); 21 Sep 2000 11:39:27 - Received: from gw2.fibrespeed.net ([EMAIL PROTECTED]) by web.fibrespeed.net with QMQP; 21 Sep 2000 11:39:27 - Received: from growl.pobox.com (208.210.124.27) by gw.fibrespeed.net with SMTP; 21 Sep 2000 11:39:27 - Received: from growl.pobox.com (localhost [127.0.0.1]) by growl.pobox.com (Postfix) with ESMTP id 53F6014F46 for [EMAIL PROTECTED]; Thu, 21 Sep 2000 07:38:27 -0400 (EDT) Received: from web.yn-tobacco.com (unknown [202.98.189.88]) by growl.pobox.com (Postfix) with ESMTP id B9CA914D34 for [EMAIL PROTECTED]; Thu, 21 Sep 2000 07:38:16 -0400 (EDT) Received: from mickey (tnt6-szb.szptt.net.cn [202.104.105.8]) by web.yn-tobacco.com with SMTP (Microsoft Exchange
Re: spam processing
This program will only grab the most recent (last) Received: line's IP
address.
It can be modified to do more if you like, or you could just have it dump
its output to a file listing IPs and every night run it through sort uniq.
-x-CUT-x
#!/usr/bin/perl
$names="name1|name2|name3";
while ()
{
if (/Received: from/) { $received = $_; }
if (/To:.*$names/i)
{
$received =~ s/(([0-9]{1,3}\.){3}[0-9]{1,3})/$1/;
$SpamIP = $1;
# If you want to print them out ...
print "$SpamIP\n";
}
}
-x-CUT-x
i would like to process them automatically via a .qmail* file, and one
thing i would like to extract automatically is the IP of the SMTP relay
that sent the mail to our server. example:
[...]
so i would like to extract 194.206.111.65 from the line
Received: from unknown (HELO srvweb.IMPI-GIPSI.FR) (194.206.111.65)
Re: spam processing
This program will only grab the most recent (last) Received: line's IP
address.
It can be modified to do more if you like, or you could just have it dump
its output to a file listing IPs and every night run it through sort uniq.
-x-CUT-x
#!/usr/bin/perl
$names="name1|name2|name3";
while ()
{
if (/Received: from/) { $received = $_; }
if (/To:.*$names/i)
{
$received =~ s/(([0-9]{1,3}\.){3}[0-9]{1,3})/$1/;
$SpamIP = $1;
# If you want to print them out ...
print "$SpamIP\n";
}
}
-x-CUT-x
i would like to process them automatically via a .qmail* file, and one
thing i would like to extract automatically is the IP of the SMTP relay
that sent the mail to our server. example:
[...]
so i would like to extract 194.206.111.65 from the line
Received: from unknown (HELO srvweb.IMPI-GIPSI.FR) (194.206.111.65)
Re: OT: Need some help with SSL
It also happens to support SSL (TLS) secure connections out-of-the-box (so to speak) if you have openssl installed. - Original Message - From: "Jamie Heilman" [EMAIL PROTECTED] Stephen F. Bosch wrote: I am trying to set up SSL with a UW IMAP server. Before I bother the list with this I thought I'd ask if anybody knew of a mailing list for SSL e-mail... We got your first message just fine, no need to keep sending it over and over again. To setup an SSL wrapper around UW's IMAP server I suggest you go to stunnel.org and read the documentation. It is, ofcourse, probably worth mentioning that any security you gain from using SSL connections you're going to circumvent by using something as poorly written as UW's IMAP server. There's every indication that that the programers at UW just don't give a damn about security. I suggest you look into courier-imap instead, provided that it's Maildir-only nature doesn't interfere with your plans.
Re: Mass Mailout Performance Tips
- Original Message - From: "Petr Novotny" [EMAIL PROTECTED] On 12 Sep 2000, at 16:06, Michael T. Babcock wrote: How does a different filesystem, like ReiserFS help? Hypothetically? Any system which doesn't scan directories in linear order but using binary search (keeping directory entries sorted, or indexed) helps a lot. Not only ReiserFS, but also NTFS lie in that domain. (Well, I *think* ReiserFS lies in that domain; I *know* NTFS does.) [ ... ] Hell, I would like to see ext2 with much better scaling - Maildirs would finally stop to suck when overcrowded. But *personally* I trust more the code from the "mainstream distribution" (read: ext2) then patching my kernel (read: reiserFS). I'll wait until a better filesystem claws its way into RedHat distro. :-) I'm running ReiserFS on our non-critical partition (squid caching) and have been for about 6 months solid. The only errors or glitches I've come across is running out of space incorrectly (df -h reports one amount, but the filesystem reports an error when creating a file). This would be an issue -- but in this case, I'm running things close to the line (I've told Squid to use 450M of a 500M partition). There is a project to modify qmail 1.03 to work more efficiently with ReiserFS' design; see their mailing list archives if you want details.
Re: linuxpeople thread
- Original Message - From: "Robin S. Socha" [EMAIL PROTECTED] Now? Where have you been? As far as pissing people off that seems to be the main goal of the peole that have replied to my posts. Doesn't that make you wonder why? Yeah, right: "Nameless idiot helps ML reader to death after being flamed by a Bastard." Film at 11. Anyone feel like buying popcorn shares? You just have a bad attitude, plain and simple. And like I said in private before, you've come close to prosecutable offenses in some countries. Note: your posts are more noise, less signal, than any of the people you've flamed. Most of my flames are done in private Email. Start reading some of those Internet newbie sites again, and learn how to deal with people you don't like on mailing lists the recommended way -- in private. I think you just enjoy being heard (anyone want to search 'socha' in the mail archives?). Note: which part of "discussion of qmail" eliminates asking for help? Its not a specific help list, no. Its a _general_ list.
Re: Questions...
- Original Message - From: "Petr Novotny" [EMAIL PROTECTED] On 12 Sep 2000, at 16:32, Michael T. Babcock wrote: cf. http://www.faqs.org/rfcs/rfc974.html This is the only mention of the non-use of CNAMEs in the mail standards. I beg to differ. Please have a look at RFC1912, called "Common DNS errors". Quoting section 2.4: [RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME. This results in unnecessary indirection in accessing the data, and DNS resolvers and servers need to work more to get the answer. If you really want to do this, you can accomplish the same thing by using a preprocessor such as m4 on your host files. RFC1912 is "Category: Informational" and is a recommendation, not an Internet standard (that was my original point). RFC 1034 is also a non-standard recommendation (only) from 1987 and I'm unable to open RFC 974 for perusal right now. Please note the difference ... RFCs are good reading. HTTP and several other non-standard protocols are entirely implemented based on RFCs, but are allowed to diverge from those RFCs without anyone having the right to be terribly upset because they are /not/ Internet standards. It is sometimes a good idea to follow the recommendations in non-standards RFCs. In many cases, citing 'its in an RFC' is irrelevant though, as the carrier pigeon implementation of IP should demonstrate.
Re: Linuxluser thread (Was: linuxpeople thread)
Because every other time someone posts an error message, they get told to send ALL their logs. So now, someone does, and they're told they're an idiot for not reading your mind? - Original Message - From: "Robin S. Socha" [EMAIL PROTECTED] * [EMAIL PROTECTED] [EMAIL PROTECTED] [000913 04:32]: Hello I have documented each step up until they fail. Damn, you are *STUPID*. When someone tells you to post a *SHORT* and *PREGNANT* error message, why do you send 600 lines?
Re: Linuxluser thread (Was: linuxpeople thread)
How do you manage to get back to MUAs in most messages you write? How exactly am I mis-using my MUA? Hmmm? I'm not misusing my MUA. I didn't complain about how messages looked, yours, mine or others'. You're the one who's been whining. That can be verified by the archives if you have some problem with your memory. You whine CONSTANTLY about peoples' MUAs. Don't tell us to change, follow your own advice and shut-up. - Original Message - From: "Robin S. Socha" [EMAIL PROTECTED] You call that a log? Why don't you learn to use your MUA in a decent way instead of lamenting the fate of an unknown luser. Your pathetic whining sucks.
Re: Spamming .....
On which note, it is quite useful to create your newsletter in HTML on a website, and then make a mailing list that simply gives the major headings and points back to that website for the actual newsletter (many large newsletters do this to save bandwidth and create a nicer looking newsletter). - Original Message - From: "Rick Harris" [EMAIL PROTECTED] That being the case, you will probably need to look toward things like Ezmlm and do the whole mailing list thing. IMHO . YOu might notofy your ISP that you are running a listserv or going to email out that much. THe provider I work for , we monitor that kind of traffic and when you decide to send 100k emails in a very short timespan , someone is very likely to notice and it wil raise an eyebrow or two. There is I would think better ways to disseminate this information than mass emails. Takes up to much servers space and just eats bandwitdh if you plan on doing this on any kind of regular basis ..
Re: Questions...
I'm missing the message where Scott said to ignore the RFC. He may have several times said the RFC was irrelevant, or hinted at that, but never said (to my reading) that it should be ignored. In fact, I understood him to be saying it should be changed. - Original Message - From: [EMAIL PROTECTED] here's my summary of this issue that scott has been preseverating on for the past year and a half or so: -the RFC says MX records can't point to CNAMEs -scott thinks that is silly and doesn't understand why it should be -others point out that this was originally due to fears of efficiency (multiple lookups for the same record). -scott says: 'oh yeah? it's not that inefficient and so are other things anyway'. -others say: then change the RFC to be compliant -scott says that we should ignore rfcs rather than update them. -people generally stop taking scott seriously. i've heard this conversation several times on the list so far and it always goes like this. am i missing the ways in which this is a productive conversation for anyone? todd On Tue, 12 Sep 2000, Scott D. Yelich wrote: On Tue, 12 Sep 2000, Petr Novotny wrote: Pointing to CNAMEs is close to forbidden. ok, I can't resist: "WHY" ? 1. Because the law (RFC) says so. but why was the "law" put in place? perhaps... 2. You also want some logic? Because you'd have to start over again resolving the CNAME chain. There were fears of efficiency. AH! Someone once thought it might not be as efficient. Which is used more (ie: higher traffic?) -- email or web? No, in general... not that it really matters, but lets just say web is a "whole heck of a lot more" on popular sites. What is that site uses cnames for www.domain? Why is this not against the law, but doing the same for email -- is? I still don't understand why #1 is not enough for you. Are you in position to change the RFCs? If yes, please do. If not, well... I'm just questioning the validity of rabid insistance on this statement. It's only impossible until it's not. Certain types of laws can be changed. Lets approach it another way... just like the "perfect" documentation for qmail -- if something is so common -- yet the "law" controlling it is seemingly so obscure to locate and is constantly being trampled and may not even truly be relevant -- what seems like the more beneficial approach: (1) change/ignore the law or (2) continue to try to get the seemingly ever increasing major of law breakers to see the err of their ways and rehabilitate and repent? Quick Qmail Quiz HOW MANY MAILERS FAIL TO USE CNAMES AS MX TARGETS?! Lets everyone name all of them! Quick Qmail Quiz (for those who passed the first one): HOW MANY MAILERS REFUSE TO ACCEPT BARE CARRIAGE RETURNS? Actually, I'm honestly interested in learning the answer to those two questions -- without RTFMing all day, without reading FAQs all day and without INSTALLING and TRYING each mailer out there. Scott -- Todd Underwood Chief Technology Officer Oso Grande Technologies, Inc. [EMAIL PROTECTED]
Re: Mass Mailout Performance Tips
How does a different filesystem, like ReiserFS help? Hypothetically? - Original Message - From: "Petr Novotny" [EMAIL PROTECTED] On 12 Sep 2000, at 20:10, Peter van Dijk wrote: I don't know if it sucks more than sendmail. Sendmail doesn't have a todo queue, and it often has several processes spawning at once, because of it's nature. However, sendmail (by default) also has a single queue directory (like todo is); it is hit by the very same problem (scandir(), open(), unlink() taking *too*long* in large directories) as qmail. If you get a big-todo patch for qmail, then 2 messages in todo queue are no problem...
Re: Questions...
- Original Message - From: [EMAIL PROTECTED] If you're serious, the answer is that some people view that adherance to standards is important even if it seems to temporarily hamper interoperability. "Temporarily"? I'm talking the long-term view of the Internet not the next couple of years. Standards-rot over the last 20 years on the Internet has already caused serious problems and blithely ignoring them, no matter how vague, is a contributor to that standards-rot. I'd just like to throw in a little comment, without disagreeing with you outright, that CNAMEs are not 'prohibited' by any Internet Standards documents (to my knowledge). For those reading this who don't know, standards and rfcs are not equivalent. HTTP, for example (as someone on this list's homepage points out) is not a standard. For the sake of answering the original questionner w.r.t. reasoning, from RFC974 (which is standard 0014): Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. cf. http://www.faqs.org/rfcs/rfc974.html This is the only mention of the non-use of CNAMEs in the mail standards.
RBL checks and header modification
Does anyone have a program that does the checks rblsmtpd does, except that it allows the modification of the message header instead of blocking the mail? I've mentionned this before, but after trying some things, didn't manage to get it to work right. Basically: - incoming message from server a.b.c.d - software checks if a.b.c.d is in RBL (or RSS, etc.) - if so, adds "X-RBL-Failure: http://www...blah" (which is the failure line) - if not, ignores the message (as is currently done).
Return Receipts
I'm aware of how qmail currently handles receipts, but am wondering if it would be possible (of course ;-) to (by adding a header?) request that qmail-remote or qmail-local generate a return-receipt-verified E-mail once they succeeded? It doesn't seem that difficult to return a confirmation message (on request) once the sending server has successfully delivered the message to where it was going. The user may not have received it yet, etc., but it is sent.
Re: ezmlm killing mail server
- Original Message - From: "Dave Sill" [EMAIL PROTECTED] The problem you seem to have with qmail-send is that it processes deliveries in the order in which they're received. This property is known as "fairness", and it's perfectly reasonable in a queuing system that doesn't support multiple priorities. Actually, its just FIFO. Fairness would involve queuing and re-ordering of some form. Fairness infers intelligence on the part of the queuer. Now you can say that there is fairness built in to the randomness of the queue's order, but its not "fairness" in a queuing sense. SFQ comes to mind w.r.t. IP packets. Incidentally, I don't agree with the original poster's assumptions. But qmail-send isn't "fair" -- thats a level of complexity that wasn't added and won't (probably) be added because of possible implications for security and stability.
Re: Slightly Off Topic
- Original Message - From: "Petr Novotny" [EMAIL PROTECTED] On 6 Sep 2000, at 8:26, Dave Sill wrote: Wut? qmail supports fallback smtp hosts. If you're referring to alternate MX's, that's not the same thing as Sendmail's fallback host. With Sendmail, if the first delivery attempt fails, the message can be passed off to a fallback host for subsequent delivery attempts. Hmm...maybe if you set queuelifetime to 0 and redirect bounces to another host somehow you could achieve the same effect. A better way seems to try qmail-remote yourself, and if it fails, inject the mail to another qmail's queue via qmail-qmqpc. Interfaces to both qmail-remote and qmail-qmqpc are well documented. I can't possibly believe you advise this as a 'better' way unless you're expecting the issue to occur only once a day or less. If the user wants this feature, it may not be available in qmail, but I wouldn't advise manual intervention on a server for such an automate-able event.
Re: Monitoring Email
To help discussion:
-x-
How do I keep a copy of all incoming and outgoing mail messages?
Answer: Set QUEUE_EXTRA to "Tlog\0" and QUEUE_EXTRALEN to 5 in extra.h.
Recompile qmail. Put ./msg-log into ~alias/.qmail-log.
You can also use QUEUE_EXTRA to, e.g., record the Message-ID of every
message: run
| awk '/^$/ { exit } /^[mM][eE][sS][sS][aA][gG][eE]-/ { print }'
from ~alias/.qmail-log.
-x-
This cannot be considered a good FAQ answer for beginners (and pointing that
out in the FAQ itself would be nice). grep'ing for QUEUE_EXTRA in the
sources only gives:
-x-
BLURB3:* optional logging of one-way hashes, entire contents, etc.
(QUEUE_EXTRA)
CHANGES:19961202 change: added FAQ entry on QUEUE_EXTRA.
CHANGES:19961129 change: added QUEUE_EXTRA, QUEUE_EXTRALEN.
extra.h:#define QUEUE_EXTRA ""
extra.h:#define QUEUE_EXTRALEN 0
FAQ:Answer: Set QUEUE_EXTRA to "Tlog\0" and QUEUE_EXTRALEN to 5 in extra.h.
FAQ:You can also use QUEUE_EXTRA to, e.g., record the Message-ID of every
qmail-queue.c: if (substdio_bput(ssout,QUEUE_EXTRA,QUEUE_EXTRALEN) == -1)
die_write();
THOUGHTS:contents of the message? With QUEUE_EXTRA it'd be possible to
record a
-x-
Considering the only source references to it are extra.h's defining (or not)
of their values and qmail-queue's "write to this", anyone not wanting to
figure out qmail by the sources (which honestly, should not be necessary to
_use_ it) will not figure out how to use QMAIL_EXTRA or what it
accomplishes.
What happens, from my understanding, is this delivers the message not only
to the intended recipient, but also to whoever/whatever is specified in the
~alias/.qmail-log file.
Read up on aliases and once you understand how qmail deals with aliases,
you'll (maybe) 'get' what is happening here.
And yes, you would be able to configure that a user receive all the
deliveries of those messages.
- Original Message -
From: "Leslie Bester [EMAIL PROTECTED]" [EMAIL PROTECTED]
So your answer is no then. Okey, thanks for your "help".
- Original Message -
Is there a way to have all incoming and outgoing emails (with
attachments) sent to a secret user for later viewing?
http://cr.yp.to/qmail/faq/admin.html#copies
Being new to Qmail, and even after going to the url that you so
politely
provided, I still do not see the answer.
Re: Monitoring Email - Clarified
Seeing as you so enjoy being sarcastic, lets ask a few extras: - Original Message - From: "Robin S. Socha" [EMAIL PROTECTED] * Jason Brooke [EMAIL PROTECTED] [000906 09:34]: Cool quoting style, honey... The URL http://cr.yp.to/qmail/faq/admin.html#copies that someone posted does in fact seem to say that what you need can be done, although it certainly appears to assume the user has a certain knowledge level - Like what? Reading ability? God bless America... No, like knowing how qmail delivery works, etc. Do you want me to explain to you how quantum properties of light purportedly work without giving the introductory physics? It would be nice if that FAQ at least mentionned cross-references for the other documentation related to the issue (note my previous E-mail). | How do I keep a copy of all incoming and outgoing mail messages? | Answer: Set QUEUE_EXTRA to "Tlog\0" and QUEUE_EXTRALEN to 5 in extra.h. Ok, this begs the question, where do the copies end up? | Put ./msg-log into ~alias/.qmail-log. And you are free to tell everyone (in the FAQ maybe?) what putting msg-log in .qmail-log does. Sure, it tells qmail how to handle deliveries intended for the 'log' alias. So, how does the user (as was asked) have these messages delivered to an account for POP retrieval? (Just to point out that you didn't answer the question, and neither does the FAQ).
Re: QMTP
The code for serialmail comes with code to send via qmtp. - Original Message - From: "Austad, Jay" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 05, 2000 11:35 AM Subject: QMTP Where would I find detailed specs on the QMTP protocol? I've found some stuff at http://cr.yp.to/proto/qmtp.txt, but I need more. We're writing a little piece of code that's going to sit on a couple of hundred Win2000 webservers that can talk QMTP to our qmail box for faster delivery. Users come to our site and sign up for automatically generated charts and other such things and the webservers generate the content for the email and send it off using SMTP right now. We need to speed this up as much as possible, and QMTP looks like the best way to do it since we already have a qmail box sending most of our other subscriber mail.
spam relay follow-up
For the sake of following up on my previous questions about the spam relay tests and Qmail's responses, also see RFC 2505 http://www.rfc-editor.org/rfc/rfc2505.txt, "Anti-Spam Recommendations for SMTP MTAs" (Feb, 1999).
Relay Testing
I just decided to manually run the RSS relay tests (telnet to mail-abuse.org, and it will start a relay test on the machine that connected to it). qmail, of course, didn't relay any messages, but I was wondering why it gave one response it did: Relay test 7 MAIL FROM:[EMAIL PROTECTED]@[216.168.105.33] 250 ok RCPT TO:"nobody%mail-abuse.org" 250 ok RSET 250 flushed Why the '250 ok' ? Why would it accept "nobody%mail-abuse.org"? Maybe I need to re-read the RFCs?
Sender domain verification ...
A quick one ... ? ... mail is being rejected from one of my clients to one of their partners because their mail server is claiming that the sending machine's dns doesn't resolve. We aren't authoritative (in the Internet sense ;-) for our subnet for our ISP, so we can't easily make it resolve if they're doing reverse DNS and checking the host names (which I've seen some mail server software, like Imail, do). Logs: Deferral reasons: (from qmailanalog) 22 56.96 Connected to 209.146.143.99 but my name was rejected./Remote host said: 504 DNS verification of sending machine failed: no mail will be accepted/ From the mail logs: qmail: 967569833.463729 status: local 0/10 remote 1/20 smtpd: 967569833.603162 tcpserver: end 22548 status 0 smtpd: 967569833.603278 tcpserver: status: 0/50 qmail: 967569834.109640 delivery 6271: deferral: Connected_to_209.146.143.99_but_my_name_was_rejected./RAug 29 13:23:54 web qmail: 967569834.109757 status: local 0/10 remote 0/20 The primary mail server there is running groupwise ... "220 wwd.von.ca GroupWise Internet Agent 5.5.1 Ready (C)1993, 1998 Novell, Inc." ... which is the one rejecting our mail, but their secondary is running sendmail: "220 queue1.magma.ca ESMTP Sendmail 8.9.3/8.9.3; Thu, 31 Aug 2000 15:11:03 -0400 (EDT)" ... and accepts our mail. Is there an easy way to have mail destined for this domain (wwd.von.ca) go to the secondary MX instead of the first? Would the best way to do this be to copy their domain data and claim to be authoritative for it on my mail server? Thank-you.
Re: Relay Testing
Thanks ... interesting reading ... a test message would be needed to truly check I guess is the result. - Original Message - From: "Peter Green" [EMAIL PROTECTED] Relay test 7 MAIL FROM:[EMAIL PROTECTED]@[216.168.105.33] 250 ok RCPT TO:"nobody%mail-abuse.org" 250 ok RSET 250 flushed Why the '250 ok' ? Why would it accept "nobody%mail-abuse.org"? Maybe I need to re-read the RFCs? Nope, just the archives. :) http://www-archive.ornl.gov:8000 and search on ``MAPS relay test''.
Re: Sender domain verification ...
Thank-you, I hadn't thought of that. - Original Message - From: "Peter Green" [EMAIL PROTECTED] wwd.von.ca:queue1.magma.ca in /var/qmail/control/smtproutes. This will route all mail to *@wwd.von.ca to the queue1.magma.ca server. See qmail-remote(8) for more info.
TCPSERVER + RBLSMTPD
DJB: Are there any plans to release the official version of rblsmtpd (in tcpserver) with the patch to work with the A records when TXT records aren't available?
Reasonable soft limits
Does anybody have suggested soft memory use, etc. limits to place on smtpd and qmqpd on a machine with 48M RAM that typically has 10M free? -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Clean up syslog for analog
Just in case this is of any use to anyone else out there, I've been
using a quick little PERL program to clean up my tcpserver logs which
are output to syslog (no, I don't use multilog, because I send all my
logs to a remote server over our network and don't keep them locally for
long).
I use:
cat /var/log/maillog \
| qmail-syslog-cleanup.pl \
| matchup \
/tmp/qmail-log-matched.dat
... and then process that file with the various z* programs from
qmailanalog.
qmail-syslog-cleanup.pl:
#!/usr/bin/perl
while ()
{
if (/tcpserver/) {
s/(.*: )(\d*\.\d* .*)/$2/;
print $_;
}
}
Incidentally, if anyone has a better/faster version, feel free to tell
me.
--
Michael T. Babcock (PGP: 0xBE6C1895)
http://www.fibrespeed.net/~mbabcock/
Re: SMTP port 25
- Original Message - From: "Brett Randall" [EMAIL PROTECTED] simply change an IP address on our port forwarding machine and its done - no external DNS and TTL hell to live through... You COULD alternately try ipmasqadm with ipchains but I haven't had any luck with port forwarding this yet... From my experience, the portfw code isn't quite as mature as it could be (which is accessed by ipmasqadm) but it works quite well under medium load situations at least. We're using it in the same capacity as listed above for a number of services.
Re: patching qmail with multiple patches
Also double-check with the appropriate patch author (especially if its a larger patch, like LDAP) to see which configurations he/she has tested it with. - Original Message - From: "Dave Sill" [EMAIL PROTECTED] I would: 1) Select only patches that I have a proven or mandated need for. For example, I haven't seen DNS problems, so I'd skip that one. 2) For the remaining patches, I'd construct a matrix showing which patches modified which files. 3) If any files are modified by more than one patch, I'd read the patch files to see where the modifications are being made. 4) If more than one patch modifies the same original qmail code, I'd strongly consider dropping one of the patches or finding a competent programmer to merge them. This could be tricky and/or a lot of work. 5) Use "patch" to install non-conflicting patches. 6) Manually install conflicting and failed patches. 7) Build qmail per INSTALL and patch-specific instructions. 8) Test, test, test. 9) Test some more, but still expect the unexpected.
Re: Queue Time
I'm not Dan, but this is slightly less mathematical than it sounds. The main point (if I understand DJB here) is: Its only an hour late? Another 10 minutes will hurt about "this much". Its a day late? Another hour will probably also hurt about "this much". Its a week late? Another (day?) won't hurt more than, oh, "this much". "this much" being more or less equal ... djb: '...is worth the same as...' ... where the amount of delay is respective to the amount of accumulated delay. - Original Message - From: "Rogerio Brito" [EMAIL PROTECTED] BTW, Dan, where could I read more about optimal schedules? I'm particularly interested in learning more about the following paragraph of yours (I'm not very experienced on Statistics, but I'm willing to learn more about it): - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Mathematical amusement: The optimal retry schedule is essentially, though not exactly, independent of the actual distribution of message delay times. What really matters is how much cost you assign to retries and to particular increases in latency. qmail's current quadratic retry schedule says that an hour-long delay in a day-old message is worth the same as a ten-minute delay in an hour-old message; this doesn't seem so unreasonable. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: rblsmtpd emergency
You're right -- there's no doubt that the TXT record is useful (or was ;-) ). But my point is that the lookups (according to the spec) were to be done on A records, and the TXT records fetched if you wanted that description. This is two lookups, so no qmail person would settle for that (humour). That was the jist of my original coment. - Original Message - From: "Mate Wierdl" [EMAIL PROTECTED] On Thu, Aug 17, 2000 at 06:34:21PM -0400, Michael T. Babcock wrote: The best approach to this is to have rblsmtpd use A records, as it should have from the beginning (that's what you get for optimising solely for speed, not for correctness). But then the TXT record is really useful: it does give a clue to the client how to get out of the mess.
Re: Queue Time
The current algorithm is probably fine for most users, but what about configuring the initial frequency? I can see some people being interested in trying again in 5 or 30 seconds, and others wanting to wait a few hours. - Original Message - From: "David Dyer-Bennet" [EMAIL PROTECTED] Shane Wise [EMAIL PROTECTED] writes on 17 August 2000 at 11:12:30 -0500 Is there any way to change the queue time to where it will retry more often? No. Why do you think you need this? The current algorithm is essentially exponential backoff by host. It tries more often at first, and gradually less often as the message gets older, until eventually it gives up and bounces after one last try.
Proper secondary MX configuration
What is the correct way to configure a secondary MX machine (qmail using qmqp) so that the messages are sent with the standard exponential backoff until '24 hours', and then every day for two weeks? I've been asked to secondary a machine that is down sometimes for extended periods of time (they won't upgrade, but they'll pay us to host secondary ...) and they don't want to lose their mail.
Re: Queue Time
- Original Message - From: "David Dyer-Bennet" [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] writes on 17 August 2000 at 11:32:00 -0700 I can't see much harm in being able to define the queuelifetime on an individual submission - perhaps limited to between 0 and some multiple of control/queuelifetime. The harm is in the increased complexity of the queue itself, and in the programs that manage and access it. Increased complexity costs in reliability, security, and resources consumed. I do agree that that feature has some benefit. I'm doubtful it's worth the cost, but I have little idea what the cost would *actually* be. Remember that there'd have to be some way to get the information passed to the queueing engine, too. Oh come now. It may cost in speed. But it adds functionality. Any functionality like this can be coded in a secure and reliable manner, so those shouldn't be cited as reasons to avoid the issue.
Re: Proper secondary MX configuration
- Original Message - From: "David Dyer-Bennet" [EMAIL PROTECTED] Michael T. Babcock [EMAIL PROTECTED] writes on 17 August 2000 at 13:30:37 -0400 What is the correct way to configure a secondary MX machine (qmail using qmqp) so that the messages are sent with the standard exponential backoff until '24 hours', and then every day for two weeks? One way is to configure that domain as virtual on the secondary, and direct it all into a maildir. Then run maildirsmtp (or maildirqmtp) on the maildir under cron or other control to make attempts at delivery to the primary on whatever schedule you want. Remember that a small amount of mail will end up at the secondary even when the primary is actually up, due to connectivity and DNS flakiness; so you need a system that delivers that mail fairly promptly. You can't, for example (as I wanted to before I realized this problem), hold the mail and require a manual trigger to deliver it. Right ... because of ignorance of preference levels and/or the primary simply rejecting a connection because of tcpserver hitting its max. That said, there's no way to do this more ... integrated-ly with QMQP without having the exponential failure rate increase and bounces?
Re: Queue Time
- Original Message - From: "Charles Cazabon" [EMAIL PROTECTED] If I send an email to mother saying "I'll be home for lunch" I'd like to tell my MTA to drop/bounce the mail after that event has occurred. One frequently-proposed (and possibly implemented) solution for such time-critical email is to avoid queuing the message in the first place. Instead, you call qmail-remote directly with your message. If it succeeds, you know immediately that the message reached the MX you pointed it at. If it fails -- then you can queue it, if you think it might still get there before the information is obsolete. ... on which note ... how much of a hack would it be to qmail-inject to add this as an option?
Re: rblsmtpd emergency
- Original Message - From: "Mate Wierdl" [EMAIL PROTECTED] On Wed, Aug 16, 2000 at 09:55:53AM -0500, Ben Beuchler wrote: On Wed, Aug 16, 2000 at 07:08:28AM -0500, Mate Wierdl wrote: That would not allow for the rapid changes necessary in a blackhole list. Imagine you are an ISP with several thousand customers. Through an oversight, your mail server is blacklisted. Would you rather wait for the tens or hundreds of thousands of sysadmins out there administering mail servers to remove you from their blackhole list or just submit it to the maintainer of the list and have it fixed in minute or hours? The fact is a few thousand mail servers running rblsmtpd cannot use relays.mail-abuse.org. So now they all have to apply for a domain so that they can use rbldns. Or they can start patching rblsmtpd to use A records---until relays.mail-abuse.org will change the record structure again. The best approach to this is to have rblsmtpd use A records, as it should have from the beginning (that's what you get for optimising solely for speed, not for correctness).
Re: MYSQL y QMAIL
The most-frequently used way to do this is with LDAP or vpopmail (both well-used, "non-standard" qmail modifications). - Original Message - From: [EMAIL PROTECTED] Hello friend... I am from Peru I need change of Sendmail to Qmail agent MTA, but I would like use MYSQL as database of my users because I need have username majors of 8 characters and my system no could be. Where is these information? What is LDAP? Mysql 3.22.32 is very good with QMAIL? or need install other server database?
Re: filters
A slightly different version of the question: how would one go about filtering for Mailing List (etc.) and adding [qmail] to the subject line on one's own mail? - Original Message - From: "Raul Beltran" [EMAIL PROTECTED] hi, is there a possibility to automatically concatenate a string like "[qmail] " to the subjects of all the messages coming from this mailing list?
Re: rblsmtpd and relays.mail-abuse.org
I'm using it too -- but everything seemed fine with the patch so ... - Original Message - From: "Jon Rust" [EMAIL PROTECTED] Odd that this issue has been so quiet. Are there really so few people using rblsmtpd?
Re: legit mail being blocked because of relay methods
Exactly -- what if the 'relay server' accepted messages for delivery, and then delivery failed. It would notify the mailing list server that those messages failed (if you're lucky). Wouldn't one rather have one's own mailing list server handle this work? Definately sounds like a spammer's dream ;-) - Original Message - From: "Eric Long" [EMAIL PROTECTED] on 8/10/00 2:31 PM, Michael T. Babcock at [EMAIL PROTECTED] wrote: What you're describing, if it is indeed happening, sounds more like an unintentional result of open relays and strange mailing list server logic. [...] Even so, I'm not sure I would want to rely on other people's systems to deliver important mailing list messages from a list I would host.
Re: rblsmtpd and relays.mail-abuse.org
Actually, no. The output from one is automatically sent to the input of the next as they execute each other. The "\"'s are to allow the commands to be on multiple lines. - Original Message - * Robert Sander ([EMAIL PROTECTED]) [11 Aug 2000 04:07]: It seems to me that rblsmtpd can only take one "-r" at a time, as I have version 0.70 that may be a bit old. But they can be ordered in a row, as in rblsmtpd -r rbl.maps.vix.com \ rblsmtpd -r dul.maps.vix.com \ rblsmtpd -r relays.mail-abuse.org ... I believe you meant to write: rblsmtpd -r rbl.maps.vix.com | rblsmtpd -r dul.maps.vix.com | rblsmtpd -r relays.mail-abuse.org ...
Re: Someone have a bad experience with qmail once.
And those on each side still disagree with each other. The mailing list archives are, of course, full of this discussion and should be consulted so that you can draw your own conclusions. Unless you disagree with ORBS, stating your opinions here is probably hazardous. - Original Message - Sean C Truman [EMAIL PROTECTED] wrote: This was taken straight from the www.orbs.org site. http://www.orbs.org/otherresources.html This is at best a gross misstatement of the facts, and at worst is two pounds of horseshit in a one pound bad. All of these supposed issues have also been discussed to death, on this list and elsewhere. Let it die.
Re: legit mail being blocked because of relay methods
What you're describing, if it is indeed happening, sounds more like an unintentional result of open relays and strange mailing list server logic. To justify my opinion; how could this reduce Internet traffic unless the mailing list server chose E-mails _purposely_ (not just "20 or so") for a given mail server that had other servers "behind it" on the Internet? If they were just out on the public Internet and the server receiving this set of addresses were just another mail server, it would relay the messages, yes, but at no bandwidth savings over the original MDA simply sending it directly to the resulting host. - Original Message - From: "Eric Long" [EMAIL PROTECTED] 1. Mail list server has 500 identical e-mails to send. 2. It gives that list of addresses to the mailserver, along with the e-mail message. 3. The mailserver then contacts teh first server on teh list, says "here's an e-mail message", along with a list of addresses (usually 20 or so). Sometimes all those addresses are on that server, somtimes not. 4. To stop spam, the receiver then checks the list for at least one valid receiver. if one is local, it delivers it and any other local mails, then relays the rest off to the first system in the list left over.
Re: Anti Virus
I beg you to cite the place where this list abides by these "Age-old standards". I've cited some standards about mailing lists to people before -- but usually along the lines of "don't quote 100 lines and give only 1 of your own" or "don't use 10 line signatures". I don't complain about whether my mail reader is only intelligent enough to recognise "-- " as a leader to a signature instead of "--" or "- Michael" ... That, and I much prefer to put my statements above the quoted text if my statement deals with the entirety of the comment (not just segments, as yours was), so that anyone following the list can quickly read what I have to say without scrolling. - Original Message - From: "Robin S. Socha" [EMAIL PROTECTED] Because I reformatted his mail according to age-old standards. In short, it boils down to the following: [ MTB: available in archives: http://www-archive.ornl.gov:8000/ ] Rationale: some people actually pay for download. Full quotes with HTML make an email significantly bigger than necessary (like, 5 times per average) without buying the reader anything. All it takes is a little thoughtfulness on behalf of the users of inferior (or badly set up) software (cf. my sig for a good tool). Is that asked too much, Paul? [ MTB: cf. http://cr.yp.to/sarcasm/modest-proposal.txt ]
Re: Anti Virus
- Original Message - From: "Robin S. Socha" [EMAIL PROTECTED] So you are basically advocating running a piece of exremely expensive software with a mixed track record of functionality, running on an unstable, expensive and insecure operating system for production services? [ ... ] So, you're not only running an unstable OS but also an extremely flaky, bug-ridden MTA, and you actually have this setup connected to the internet. May I ask what your company is worth *to you*? Sometimes its not their choice, you do realise. It might be that any tech that decides to change operating systems gets fired. That happens. Deal with the question at hand, please. It's more up to one's TCO calculations, isn't it? So, you're not only running an unstable OS but also an extremely flaky, bug-ridden MTA, have this setup connected to the internet, but also throw in more money to buy unneeded functionality that is likely to introduce more bugs. Can you explain your rationale, please? They have no need to justify their rationale to you. You don't matter to their corporation in all likelihood. In that light, maybe you could have stuck to answering what was asked? Wow, we're finally back on topic... *sigh* The previous part of the message was to satisfy those folks who always say 'give us more detail about your setup' (like me). Incidentally, I dislike NT, Microsoft Outlook and Exchange as much as you probably do. I've said it once and I'll say it again: anti-virus software is snake oil. Under certain circumstances, it will buy you exactly nothing. Had I sent you ILOVEYOU the moment I got it, you would have been fucked. Real bad. Maybe your filter would have caught it, but who knows? No, its not snake-oil. Its just not perfect. The anti-virus software companies, by necessity, need to analyse a virus before they can add the signature to their software. That usually requires that the virus be "in the wild" for some period of time first. However, I've had client machines come in with dozens of viruses -- usually some combination of Stoned or Monkey with a few other oldies. These are all caught by modern anti virus software and thus it _should_ be installed on machines. McAfee VirusScan for workstations is only $15 (cost). I don't classify that as snake-oil -- Michael T. Babcock CTO, FibreSpeed
Maildir archiving
I'm looking for an easy way to archive old messages in a Maildir (by compressing them, like the gzip patch does, perhaps) for users who don't believe in deleting old mail (especially their sent mail folder). Incidentally, its an IMAP system, with several Maildirs (courier-imap). eg: scan folders, find messages older than 3 months and 1) (maybe) move to different folder with (3 month ago's) date attached 2) compress messages I prefer something with the moving of the files as listing the contents of the folder becomes much faster. -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Re: why qmail is more secure, was: Mailing list performance
The multiple UIDs provide a few failsafes, if nothing else, whereby one broken / buggy / replaced binary can't do damage to files it doesn't own. DJB has comments about this in the readmes, if I'm not mistaken. - Original Message - From: "Ronny Haryanto" [EMAIL PROTECTED] On 02-Aug-2000, Dave Sill wrote: 1) Postfix only uses a single uid. qmail uses six. Why is using more than one uid better? What sort of security problem would using one uid potentially pose?
Re: updated load balancing qmail-qmqpc.c mods
Re-read my point: its unnecessary. I didn't say it wouldn't work. I said the CPU use of doing it this way was unnecessary over a simpler round-robin approach (After picking an initial random server). Note: I think using an array of pointers to server addresses would allow you to do your rotations a lot faster. Think "point quicksort". - Original Message - From: "Austad, Jay" [EMAIL PROTECTED] Even if one server is getting hit multiple times in a row, I don't think it will matter. I put in 10 servers in my qmqpservers file and some well placed printf's in qmqpc and ran it 100,000 times several times through. Each server was getting picked about 10% of the time +/- 1% or so. If we're sending millions of messages, this +/- 1% isn't going to make a significant difference.
Re: updated load balancing qmail-qmqpc.c mods
My pseudo code was supposed to infer that one would re-select (randomly, if you wish) a server at a certain % of the time, based on how many times it had been polled and turned out to be down. Simply replace my first (increment, go to #2) with (go to #1). - Original Message - From: "JuanE" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 02, 2000 12:37 PM Subject: Re: updated load balancing qmail-qmqpc.c mods I agree with you both (Jay and Michael), at least partially. I agree that altough what Jay proposes will work, it is too much computation and that a simpler round-robin (after picking initial position) would suffice. My comment is that in the event of a down server, the simple round robin will flood the next server in the chain with twice the load of the others. Jay's solution does not do this (at a high computational cost).
Re: [offtopic?] RE: Encryption (was: Open letter)
True -- but that would require the countries the software manufacturers do business in to relax their export regs. and allow for open encryption hooks in their tools. Dave Sill wrote: It's not even this complicated with 6.5. You click on the window whose text you want to encrypt, click on the try icon, and click "encrypt window" (or something like that). PGP automatically does the copying and pasting for you. Still too hard. The way it *should* work is that I click "Send", a pop-up asks me for my pasword, and the message is sent signed and encrypted.
Re: tai64n -- why?
Are you asking more for something like: 2000/07/31 06:02:10.42 (GMT+05) This has always been the date format I've prefered ... its sortable (as the year comes first -- although its quite narrow-minded of me to not allow for 5 digit dates), its human-readable, and quite parsable. The decimal portion after the time allows for sub-second time measurement. I'm pretty sure adding a function to your copy of multilog/whatever that converted from the tai64n format to something more like the above wouldn't be that hard. David Dyer-Bennet wrote: Would you prefer the splogger format (to wit, Unix timestamp with fractional part) instead? I'd do anything to use a logging format that avoids timezone dependency, and multilog/tai64n seems to do that job well. You mean this: Jul 31 06:02:10 gw qmail: 965023330.820010 status: local 1/10 remote 0/50 ? It's better than tai64n, because syslog puts a real timestamp on, but that big chunk of meaningless numbers in the middle wastes a lot of the line and adds no useful information. It's what I'm using now on my main server, but it's quite wasteful and annoying. (But qmailanalog expects it)
Re: RE: Blocking Spam, badmailfrom not working
That's more of what the RBL is for -- if you want to take that step. The RBL is supposed to be a good list of sites that are producing spam, not that are necessarily open relays at all. "Hubbard, David" wrote: Thanks for responding Chris. I am currently using the MAPS relays.mail-abuse.org with rblsmtpd, I guess the spam I'm getting isn't coming from an open relay. Actually, the spammers usually relay through a valid mail server for their network that isn't an open relay on the internet, it's just allowing users who are behind it to go through it. I guess in this case my best bet would be to forward it to their admins since I can't block by originating IP...
Re: MUA HTML support (was: question)
Actually, no. The problem is that his E-mail client (Outlook Express) has the option of sending BOTH plain and html versions of the message and is sending them encoded as seperate MIME segments. Netscape Messenger also supports this, but IMHO, its an incorrect reading of how MIME should be used. "Robin S. Socha" wrote: * Chad Cranston [EMAIL PROTECTED] writes: 1. (*) text/plain ( ) text/html ^ Turn this off. It only makes your mail 5x as big without adding anything.
Re: Open letter
Agreed: PGP (et. al.) is definately the answer, not server-to-server encryption. However, properly authenticated DNS (or an evolution thereof) and resulting authenticated (S/Q)MTP sessions would be a leap forward as well. [EMAIL PROTECTED] wrote: The problem with your solution is that server to server encryption does not stop government and big corporations from looking at your mail on the mail server after it has arrived. Ask any system admin how hard it is to scan /var/mail or a users home directory. Answer, it's trivial.
Re: Open letter
And unfortunately, zero-effort security is, with current technology, an oxymoron. Swipe-card key systems that do the authentication would be low-effort. Retina scanning cameras built into your monitor to do authentication would be low effort as well. Until then, people have to decide if its worth their effort or not. [EMAIL PROTECTED] wrote: Key management is a non-zero effort, installation is a non-zero effort, cost is a non-zero effort and actual usage is a non-zero effort. Total transparency is what I define as "easy to use" in the context of the average email user (who probably has an email address at AOL). I'm afraid anything less won't get there.
Re: [offtopic?] RE: Encryption (was: Open letter)
Potentially long, off-topic message: (follow-ups and/or flames probably best kept private :) "Ihnen, David" wrote: Would you consider PGP more than a low-effort? It would be zero effort if we weren't concerned about the privacy of our own secret keys, thus keeping them encrypted behind passwords. Personally? Using PGP is very low-effort for me. Typing my 25+ character passphrase has become reflexive. I've run a site re: PGP use since my first website in 1993 or so, so I'm probably not a good test-case. :-) Maybe an extra-low-effort system would consist of a simply speaking a keyword into a microphone, and using voiceprint authentication to decrypt the secret keys. Fortunately almost all computers have the ability to read in decent quality audio. Sending to particular people is no effort - the public key aquisition can be automated. I saw some very interesting matrix-mapping software back in 1994 and 1995 for DOS that converted individual words (expandable to phrases) into vectors (stored as matrices) that could easily be compared against a stored file for each person. The idea was to do the "opposite" of voice-to-text recognition software and store the portion of audio that is unique for each user instead of using primarily the part that is similar. Its interesting to think of the change in load on list servers. Would you encrypt to the list server, who then decrypts and re-encrypts for each client, or would there be a collaborative key for the list that everybody had the secret to and could decrypt? More probably we would just cleartext-sign the messages for source authentication, for backwards compatibility, I suspect. Assuming, like the original 'open letter' poster, that you don't want others to snoop on the messages (but their being a subscriber to the list is "okay"), then you'd want a public key for the mailing list that all messages are encrypted to. The mailing list would decrypt the session key for the message (PGP only requires using CPU intensive P.K. cryptography to sign a session key). It would then re-encrypt the session key (effectively, the message) to the public keys of each of the recipients on the list. (It would not need to necessarily verify the sender's signature, to avoid decrypting messages at all). The sender's signature (if used) would be intact in the encrypted message and each person would be able to verify for themselves that that user had sent 'them' the message in question. The CPU intensive portion would be encrypting the session keys to everyone on the list. Assuming the old PGP protocol, that would mean doing 1024 (or more) bit RSA on a 128 bit session key (16 bytes). Either way, it can be zero-effort for the people generating the e-mail, outside of authenticating your personal secret key, though accepting the e-mail has the same effort problems. I would be signing my messages pgp, if I could, but I haven't gotten ahold of PGP 7 yet... and the earlier versions don't work on 2000. Use any version of PGP or "PGP for Windows" and use the clipboard encryption features: 1) select all text (Ctrl-A) 2) "copy" (Ctrl-C) 3) click on PGP tray icon 4) click "sign encrypt" 5) enter password 6) click window of program with selected text 7) "paste" (Ctrl-V) (replacing original with encrypted + signed cipher-text)
Re: QMTP MX encoding
Your arguments are interesting in so far as they pertain to the use of QMTP, but my concern is more that at some point the Qmail community may want to have QMTP as RFCxyz and used as a standard feature of mail exchange. With that goal (in my mind, maybe not yours), my proposal seemed to have more comatibility and standards potential than the MX magic, especially when DJB mentionned not using the MX magic preference values. Russell Nelson wrote: Michael T. Babcock writes: (stuff) I think that's a silly idea. Better to pick a "magic" MX preference,
Re: orbs.org accuses qmail of mailbomb relaying!
-x- A package is the concatenation of three strings: first, an encoded 8-bit mail message; second, an encoded envelope sender address; third, an encoded series of encoded envelope recipient addresses. -x- The encoded envelope sender address isn't expanded on beyond the examples given, but your proposal might give a good performance increase for very large lists (a la redhat.com lists, etc.). The qmtp documentation doesn't seem to mention VERP at all. See http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/02/msg00293.html for previous discussion on the issue (that went almost nowhere). cf. http://cr.yp.to/proto/qmtp.txt Paul Jarc wrote: Peter van Dijk [EMAIL PROTECTED] writes: Does QMTP support per-recipient envelope senders for a single copy of a single message? What I had in mind at first was a protocol that would have multiple sender, recipient tuples per message in the envelope. This would also allow a list server to send just a single copy to each host having subscribers.
Re: QMTP via EHLO type command
To make this a little more QMTP compatible, and to agree with some of Peter
Norton's comments from late 1998, the sending MTA could also immediately
'transfer' the request to the QMTP by opening a new connection on the QMTP
port when it 'saw' the QMTP response from the foreign SMTP MTA. It would
not have to wait for the TCP session to close, etc. (this could be done in a
non-blocking manner) and the QMTP session could begin almost as quickly as
it would if it knew the foreign server supported QMTP to start with.
As someone else said over a year ago (and I'm sure its been repeated since),
the knowledge that a foreign MTA supports QMTP could be temporarily cached,
if it were desired (and proved faster than not) and reused instead of
opening new SMTP requests to those servers.
This would have the added benefit of using QMTP more often when
communicating with servers that receive a lot of repeated traffic.
I wrote:
{ Syntax: "" from server ... "" to server }
220 IP ESMTP QMTP
QHLO
(data stream)
(response)
I see this last one as being best, since the opening message can be
customised to mention QMTP in it easily, and once that is parsed by the
sending MTA, no further foreign responses are required until the QMTP
dialog is finished. The initial "QHLO" would be added to inform the
foreign MTA of our intentions.
rblsmtpd and not bouncing
I would like to offer an option similar to pobox.com's [spam: 84%] "Subject:" munging for incoming messages from RBL or RSS listed sites. Instead of actually bouncing the message as RBLSMTPD does, allow the message but add [spam - rbl] or [spam - rss] or the like to the Subject: field of the messages in question. I'm wondering if anyone else has done this before I go making a completely modified version of rblsmtpd to do so.
Re: ezmlm
Has anyone made an auto-responder to work with ezmlm (or others??) that would reply to messages containing such "remove" messages to the list and ask the sender if they wished to unsubscribe (with the proper instructions)?? Guy Rosinbaum wrote: REMOVEremove
Re: orbs.org accuses qmail of mailbomb relaying!
Replies are in private ... anyone actually interested may ask for ensuing discussion :-). Markus Stumpf wrote: This may get somewhat off topic ...
Re: orbs.org accuses qmail of mailbomb relaying!
No offense to DJB at all, but you have a very strange view of open sourced software if you don't believe in using patches. I presume you don't use rolled distributions of Linux (if you run Linux at all) either, seeing as they're usually packed with patches. Patches are basically the equivalent of plug-ins, which you probably don't use either (for your browser, if you use anything but Lynx). That said, if DJB says 'this patch breaks the security in Qmail' I'd be tempted not to use it, if he has no comment, that's another thing entirely. If he just doesn't like the proliferation of patches for Qmail, I don't really care. Example: I use vpopmail to replace the usual pop authentication, for instance. Do I think it should be part of the Qmail distribution? No, I think it works better on its own. Russ Allbery wrote: 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.
Re: orbs.org accuses qmail of mailbomb relaying!
Joe Kelsey wrote: If a major point of Qmail's existence is to provide reliable E-mail delivery, then this _must_ include cooperating with other MTAs (without violating standards) at least enough to keep from crashing / giving them headaches so that we don't 'encourage' them to lose mail ... (through failures of their own). You *REALLY* don't understand the point of Qmail. Qmail is designed to be standards compliant, fast, reliable and secure. Your belief seems to be that the designer of Qmail only cared about reliability. That is demonstrably false, by DJB's own admission. I didn't say it was "just" reliability ... I've quoted myself above, but that isn't good enough, so I'll say it again, "major point provide reliable E-mail delivery". I was commenting on trade-offs between speed and reliability. Helping to keep other MTAs from crashing is to help reliability with a potential speed trade-off. Nothing in the design or implementation of Qmail was there ever consideration given to causing or preventing broken implementations of SMTP from crashing. I realise that -- that's why I mentionned it. Now you have gone and changed the subject to secure e-mail. There is no such thing in the defined SMTP protocol. Security is an add-on and has nothing to do with Qmail. Security has many definitions. Come back later when you can interpret a topic outside your preconceptions.
Re: orbs.org accuses qmail of mailbomb relaying!
I must have mistakenly added the message to the list. As my own comment stated, I didn't mean to subject the list to our discussion. I wrote: That said, I'm leaving this off the list because I don't like noise, so I'm not going to subject others to it. Joe Kelsey wrote: You don't bother to read headers? I sent a private message to you. Why would you even consider broadcasting a private message over a public mailing list?
[Fwd: Attitude]
Score: Apology for indirection: 1 Asanine comments: 1 Thanks everyone. I think this discussion has been very helpful to the Qmail cause ... really. Adam McKenna wrote: On Sun, Jul 23, 2000 at 12:37:55AM -0500, David Dyer-Bennet wrote: Probably our responses are by now somewhat cryptic, encoded in local language that's completely clear to those of us who've been through the argument umpteen times before. And which is probably NOT clear to you; sorry about that! Yes, let me translate for David: "Shut Up and Go Away" --Adam
Re: Want to know your potential multiple recipient savings?
This is what I've asked for too -- and been given "do it yourself". Best of luck. Frank Tegtmeyer wrote: In his measurements that indicated that qmail used less bandwidth in real-life situations than sendmail, Dan counted the DNS traffic due to sendmail. And I have never seen numbers, only Dan's claims. It's hard to argue using them without being backed up by numbers.
Re: Solaris / DoS / Broken bare LF mailers / thousands of qmail-smtpdqmail-queue procs
The 'problem' as it relates to RFCs, not to Qmail's implementation, is probably the original question. Dave Sill wrote: "James Blondin" [EMAIL PROTECTED] wrote: The question I have is, and excuse my ignorance if it's something silly: why not just accept the bare linefeeds? From what I can understand in RFC822, there's nothing wrong with bare linefeeds in the body of the messages as long as the headers have all the right CRLFs. From looking through qmail archives and reading a few webpages, all I can find is some reference to the fact that you shouldn't have bare linefeeds after the smtpd process. Anyone have any more specifics about this? Is it to protect mailers that don't know how to interpret bare linefeeds? Or something integral to the MTA? The problem is simple. If a message contains a bare linefeed, qmail will convert it to a premature end-of-line if it resends the message. E.g.: This message consists of one line\012with an embedded linefeed. Will become: This message consists of one line with an embedded linefeed. -Dave
Re: void main (no, not a long one)
I don't see how "If there is ever a compiler dumb enough to break void main(), I will happily advise everyone to use a different compiler" engenders any trust in someone's ability to write C code. Qmail is well written, sure. But void main() is and always has been wrong on 99% of platforms and adding "return 0;" to the end of the function will shut up GCC as well. That said ... Dave Sill wrote: Incidentally, is there a discussion in the past that I've missed about 'void main' declarations? :-) Yes. A quick search of the archives for "void main" yields: http://www.ornl.gov/its/archives/mailing-lists/qmail/1996/12/msg01898.html
