Problem with qmail-remote
Hi, I am having quite a fight with qmail right now. I looked through the archive for a possible solution, but I did not find anything. If this has been addressed before, please feel free to flame me personally as long as you include a pointer to where I could find the answer, thanks! I use qmail as a SMTP relay on our server. It is configured to relay only local clients, and this much works properly. My problem is that instead of the sender's email address, qmail-remote puts lo0... in the initial MAIL FROM: command when it forwards an email. The net result of this is that most SMTP server will reject this and we are unable to send any message because of that. Here is a sample bounce message generated by qmail (locally): -- Hi. This is the qmail-send program at xyz.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Connected to 1.2.3.4 but sender was rejected. Remote host said: 553 ... Unbalanced '' --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 78837 invoked by uid 0); 6 Mar 2000 18:00:15 - Date: 6 Mar 2000 18:00:15 - Message-ID: [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: sdf sdf /. ./ -- Here is what is logged with syslog: -- Mar 6 14:18:57 jacuzzi qmail: 952370337.320111 new msg 177 Mar 6 14:18:57 jacuzzi qmail: 952370337.322243 info msg 177: bytes 261 from [EMAIL PROTECTED] qp 81726 uid 0 Mar 6 14:18:57 jacuzzi qmail: 952370337.384976 starting delivery 65: msg 177 to remote [EMAIL PROTECTED] Mar 6 14:18:57 jacuzzi qmail: 952370337.386023 status: local 0/10 remote 1/20 Mar 6 14:19:10 jacuzzi qmail: 952370350.335286 delivery 65: failure: Connected_to_1.2.3.4_but_sender_was_rejected./Remote_host_said:_553_..._Unb alanced_''/ Mar 6 14:19:10 jacuzzi qmail: 952370350.339818 status: local 0/10 remote 0/20 Mar 6 14:19:10 jacuzzi qmail: 952370350.357106 bounce msg 177 qp 81729 Mar 6 14:19:10 jacuzzi qmail: 952370350.374765 end msg 177 Mar 6 14:19:10 jacuzzi qmail: 952370350.393388 new msg 178 Mar 6 14:19:10 jacuzzi qmail: 952370350.394587 info msg 178: bytes 851 from qp 81729 uid 87 Mar 6 14:19:10 jacuzzi qmail: 952370350.453256 starting delivery 66: msg 178 to local [EMAIL PROTECTED] Mar 6 14:19:10 jacuzzi qmail: 952370350.455154 status: local 1/10 remote 0/20 Mar 6 14:19:10 jacuzzi qmail: 952370350.481800 delivery 66: success: did_1+0+0/ Mar 6 14:19:10 jacuzzi qmail: 952370350.502240 status: local 0/10 remote 0/20 Mar 6 14:19:10 jacuzzi qmail: 952370350.503784 end msg 178 -- Here is what I saw with tcpdump/tcpshow: --- Packet 7 TIME: 10:34:11.819549 (0.000381) LINK: 00:50:BA:AB:66:0B - 00:90:2B:39:80:8C type=IP IP: XXX - 1.2.3.4 hlen=20 TOS=00 dgramlen=74 id=1FCE MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=D99E TCP: port 4345 - smtp seq=0378815384 ack=0111320541 hlen=20 (data=34) UAPRSF=011000 wnd=17520 cksum=C385 urg=0 DATA: MAIL FROM:lo0.. --- This happens also when I try to send mail from the relay host itself. It is not related to the email client I am using. I am completely lost here, and I would appreciate any help! Patrick.
Re: web based filtering
Hi, You could look at a package called "sieve" from the Cyrus IMAP project. It is not a web-based, but at least it is server based. Patrick.
Re: Problem with qmail-remote
Hi,
[...]
My problem is that instead of the sender's email address, qmail-remote
puts
lo0... in the initial MAIL FROM: command when it forwards
an
email.
qmail-remote doesn't make up envelope return paths. If it's using
lo0..., that's because that's what the message had when
it came in.
While the intent of qmail's code is NOT to make up a return path by itself,
in that case your statement is not true. I have spent some time lookup
through the code and tracing where that happens, and I found it.
There is a bug in the FreeBSD code that deals with "ifconf". What happens is
that FreeBSD returns more data than was requested by qmail. This causes the
return path to be overwritten with garbage.
While the proper fix should be to repair FreeBSD, it has to be noted that
the method employed by qmail in the function ipme_init() to find the list of
all the interfaces of the system is really not the best. The code starts
with a 256 bytes buffer and then increments it gradually issueing a system
call each time to fill up the memory area with the proper information.
A size of 256 bytes is good enough in cases where you only have one
interface (in addition to lo0 of course). In my case, I have 8 interfaces so
to get it right the code has to do 5 iteration before it reads everything.
The quick fix is to allocate a fairly big chunk of memory (1500 bytes) right
from the start. This solves my problem. Also it would reduce the number of
system calls necessary to obtain the list of all the network interfaces. I
don't think that saving a few bytes is worth the number of system calls. Of
course the kernel needs to be fixed, but that's another story.
A patch that fixes my problem is included at the end of this email for
anybody to use if they encounter the same symptoms. Beware though that it
may not be working in all cases. It works in mine, that's all I can say.
What is this? You really used abc.com, and its MX is 1.2.3.4? And the
unbalanced '' error is not the same as a sender of
lo0
Yes the error is directly related to the problem I described. The remote end
of the SMTP connection tries to understand the sender's address and stops
processing it after 2 consecutive dots. It then complains that it did not
find the closing ''. I just did a little bit of homework before asking a
question.
Patrick.
--- ipme.c.orig Fri Mar 10 17:15:58 2000
+++ ipme.c Fri Mar 10 17:19:48 2000
@@ -48,7 +48,7 @@
if ((s = socket(AF_INET,SOCK_STREAM,0)) == -1) return -1;
- len = 256;
+ len = 2000;
for (;;) {
if (!stralloc_ready(buf,len)) { close(s); return 0; }
buf.len = 0;
@@ -60,7 +60,7 @@
break;
}
if (len 20) { close(s); return -1; }
-len += 100 + (len 2);
+len *= 2;
}
x = buf.s;
while (x buf.s + buf.len) {
Re: Problem with qmail-remote
Hi,
My problem is that instead of the sender's email address, qmail-remote
puts
lo0... in the initial MAIL FROM: command when it forwards
an
email.
Here is a piece of code that will test if your implementation is subject to
the bug I experienced on my FreeBSD installation. This bug can manifest
itself with a few interfaces (one can be enough) with non-IPv4 configuration
(such as netatalk). I just submitted a patch for FreeBSD (both 4.0 and 3.x).
If your system contains the bug, let me know (as well as the vendor of
course).
This bug is probably present in most of the BSD socket implementations...
There are 2 variants of it:
- pure and simple buffer overflow (this is the one present on FreeBSD 3.x)
- no buffer overflow, but the announced size of the returned buffer is
incorrect (this one is present in the latest FreeBSD 4.0 [after feb 28,
2000]).
Patrick.
#include errno.h
#include sys/types.h
#include sys/param.h
#include sys/time.h
#include sys/ioctl.h
#include sys/socket.h
#include net/if.h
#include netinet/in.h
#include sys/sockio.h
#define VERBOSE_CHECK_
int check55(char *start,char *end)
{
int startoff=-1,endoff=0;
int off=0,c=0;
int ret = 0;
#ifdef VERY_VERBOSE_CHECK
printf("%03d\t",off);
#endif
for(;startend;start++,off++)
{
if(*start != 0x55)
{
if(startoff0)
{
startoff=off;
}
endoff=off;
}
#ifdef VERY_VERBOSE_CHECK
if(++c=33)
{
printf("\n%03d\t",off);
c=1;
}
printf("%02x ",*(unsigned char*)start);
#endif
}
if(startoff=0)
{
#ifdef VERBOSE_CHECK
printf(" ** buffer changed from %d to %d = %d bytes modified
**\n",startoff,endoff, endoff - startoff + 1);
#endif
ret = endoff-startoff+1;
}
return ret;
}
main()
{
struct ifconf ifc;
char *x;
struct ifreq *ifr;
struct sockaddr_in *sin;
int len,ret;
int s;
char buf[16000];
int bug=0;
int mod=0;
#define END_TEST 8000
if ((s = socket(AF_INET,SOCK_STREAM,0)) == -1) return -1;
for (len=1;len=END_TEST;len++) {
ifc.ifc_buf = buf;
ifc.ifc_len = len;
memset(buf,0x55,sizeof(buf));
#ifdef VERBOSE_CHECK
printf("\n[Try with len=%d]\n",len);
#else
printf("try %4d\t", len);
#endif
if ((ret=ioctl(s,SIOCGIFCONF,ifc)) 0)
{
printf("\n\n = ioctl failed (returned %d, errno=%d)\n",ret,errno);
}
#ifdef VERBOSE_CHECK
printf(" = ioctl succeeded, pretends it wrote %d bytes\n",ifc.ifc_len);
#else
printf("pretends %4d\t\t", ifc.ifc_len);
#endif
mod = check55(buf,buf+sizeof(buf));
printf("modified %4d\t", mod);
if (bug 2 mod ifc.ifc_len)
{
bug = 2;
}
else if (bug 1 ifc.ifc_len len)
{
bug = 1;
}
printf("bug %4d\n", bug);
}
switch (bug)
{
case 0:
printf("\n\n*** Implementation OK (FIXED)*** \n\n");
break;
case 1:
printf("\n\n*** Implementation corrupts buffer ***\n\n");
break;
case 2:
printf("\n\n*** Implementation returns incorrect ifc.ifc_len, but
buffer OK ***\n\n");
break;
default:
printf("\n\n*** Huh ??? %d ***", bug);
break;
}
return bug;
}
Re: Poor documentation of anti-spam options?
Hi, From: "Paul Schinder" [EMAIL PROTECTED] At 3:06 PM -0500 3/31/00, Dave Sill wrote: Do the spammers: 1) throw up their hands and admit defeat, or 2) start using valid (but wrong) domains in their envelope return paths, thereby defeating your rejection and escalating the arms race? Note that many are already doing (2), of course. I've had several emails using my @pobox.com address as the MAIL FROM bounced because spammers use phony @pobox.com addresses. I've never seen a single spam that originated on pobox's servers. Most of the spam I see comes from China or relay raped machines outside the US. And, of course, I've seen numerous pieces of spam with phony @yahoo.com, @hotmail.com, @aol.com, etc. Maybe one way to deal with this is: 1. verify that the domain of MAIL FROM is correct 2. verify that the address of the server sending the mail resolves to that domain... This is probably not the best answer, but if you apply that to some key domains, then you should be able to cut down on a fairly good volume of spam with fake addresses. Also it should be fairly easy to implement a scheme like this in qmail (although it also means more DNS lookups for a good number of incoming mail messages). Patrick.
Re: Poor documentation of anti-spam options?
Jon Rust [EMAIL PROTECTED] wrote: I agree with most of what you said here Dave, but I'd have to say that rejecting mail with envelope sender domains that don't exist is a good thing (either an A or CNAME record, or an MX). If for no other reason, you can't bounce back to them. I don't consider this aspect an arms race with spammers, just common sense. You give me a false from address, I reject your mail. Except you're supposing that if a domain is valid, you can resolve it. They aren't the same thing. I see the daily mail logs here every day, and we always have a few legitimate mails which are rejected by a receiver doing this; the problem is, their DNS is down, or their resolver is broken, or their BIND has decided to take a field day. Result? They reject our legitimate mail. Well there are other ways to test if a domain *at least* exists. You can check it with whois. OK this is not *the* good answer either, but at least it gives you an good indication that the domain name is potentially working... The problem with spam is that there is no reliable way to split spam from legitimate mail. If you try to filter-out spam, you will always end-up filtering out proper mail as well. The key is to try to keep track as much as possible of what is accepted and what is rejected. Also the tolerable lost email / killed spam ratio is somewhat a personal decision... Patrick.
Re: Poor documentation of anti-spam options?
From: "Len Budney" [EMAIL PROTECTED] The key is to try to keep track as much as possible of what is accepted and what is rejected. Why? To satisfy your curiosity? Or do you then track down all senders of legitimate email, and tell them what happened? The reason why I feel that logging of spam filtering is crucial is exatly that: try to find out how much valid mail you are killing compared to the number of spam. I definitely want to know what gets rejected by a filter to fine tune it or remove it if does not satisfy my needs. ...the tolerable lost email / killed spam ratio is somewhat a personal decision... The tolerable ratio is zero. If you are an ISP and think differently, then your customers should abandon you. They might even have grounds to sue you. (``The computer threw your job offer away. Sorry.'') They probably won't, because they don't understand. (``Oh. Those darn computers!'') Hey, don't flame me. I said this is a personal choice. For my part I don't filter anything out (yet) because spam is not enough of a problem for me at this time. The only thing I am pointing out is that the choice of doing spam filtering is a personal one, and one has to understand that it will kill legitimate mail as well. Patrick.
Re: Poor documentation of anti-spam options?
Hi, From: "Peter van Dijk" [EMAIL PROTECTED] advertise the e-mail address associated with that user account in the MAIL FROM, nothing prevents you to advertise your "official" email address in the reply-to header. Uhm. You are correct. Nothing prevents you from doing that. But it kinda defeats the purpose of being able to dialin anywhere in the world, POP mail off your home-provider and send thru the relay of the ISP you're dialing into. Well I think that the better answer in this case would be to use your home-provider's SMTP relay using either SMTP-after-POP or SMTP AUTH or TLS or whatever other scheme that will let you use your *normal* relay. Since you are already accessing you home provider's services (the POP account), you should be able to also its mail relay. Again I am not saying that this is practical today. My only claim is that you should be able to use the domain indicated in MAIL FROM to do validity checks and possibly reject spam. This amounts to enforcing stricter relay servers: should a server relay mail if the address presented in MAIL FROM does not belong to one of its domains (in addition to does it come from one of the "local" computers, etc.) ? Yes it should. Relaying should be based on IP, either fixed (subnets) or dynamic (SMTP-after-POP), and _nothing_ else. I think that this is debatable (cf. my comment above). If I am an ISP, why should I let somebody use my mail servers to relay messages that pretend they are not from one of my users (including any virtual domains that I may have) ? Anyway, most people here will agree that the rules you are proposing are insane, because you will prevent your customers from using a POP-account at another ISP. When you configure a POP account in your MUA, you usually configure a SMTP server along with it. Why not configure that ISP's SMTP server ? Please note that I am not trying to start a flame war. I just want to have strong arguments as to why that method should or should not be used. So far we have: - travelling users may be impacted badly by this, unless they always use their "home" mail relay (how feasible is it today ? should it be enforced ?). - this could work with yahoo or hotmail (because the only way you can use their relays is via their web interface) - this is insane (this is the point I have trouble with :) Patrick.
Re: Poor documentation of anti-spam options?
I guess it's time to close the debate on that issue. I appreciate the main point here which is: that solution could work, except that today it is not practical to use "remote" relays that correspond to your main email domain. - Original Message - From: "Peter van Dijk" [EMAIL PROTECTED] On Sat, Apr 01, 2000 at 12:24:43PM -0500, Patrick Bihan-Faou wrote: Again I am not saying that this is practical today. My only claim is that you should be able to use the domain indicated in MAIL FROM to do validity checks and possibly reject spam. ágain 'should'. But you can't enforce this policy until all providers in the world support this. [...] If I am an ISP, why should I let somebody use my mail servers to relay messages that pretend they are not from one of my users (including any virtual domains that I may have) ? Becuase the person in question is dialling in to _your_ service, and you are probably making money out of that. They're paying. You provide a service. The picture is very simple. This is the key point. Personally, I view a provider's task as giving me access to the internet (a pipe). The rest (SMTP relays, etc.) is secondary and I would not mind if the provider told me to use my primary servers for that. Of course you would have now 2 classes of users: internet connection and internet connection + services. I guess that this way of looking at a provider is still a bit new, but ultimately I think that we will have to move in that direction. There certainly aren't many technological barriers anymore to do that. When you configure a POP account in your MUA, you usually configure a SMTP server along with it. Why not configure that ISP's SMTP server ? Becuase that ISP is not so stupid as to allow you to relay while you're not dialling in to them. This is the other part of the problem. If I pay somebody to handle my mail, I expect that he will provide me with a way to do it all the time. We now have the technology to do it (ranging from SMTP over TLS, SMTP after POP, tunneling, etc.). I hope that providers will start using them sometime. Anyway, this is now of topic as far as qmail goes, we agree that we can't do that now, so let's close the subject. Patrick.
Re: Qmail on FreeBSD 4.0
Hi, I am using qmail on FreeBSD with ucspi and daemontools as decribed in LWQ and everything is great... There is one patch you need to implement on the FreeBSD kernel in order to not suffer a buffer overflow in one of the function that qmail uses. This buffer overflow will effectively replace the address for the MAIL FROM command of outgoing smtp session with crap leading in email rejections from remote smtp servers. Note that this bug affects FreeBSD, but may also be present in other BSD based TCP/IP implementations. The file to patch is /usr/src/sys/net/if.c, the attached patch is against the current RELENG_4 version. Have fun with FreeBSD... Patrick. if.c.patch
Re: Re[2]: Qmail on FreeBSD 4.0
Hi,
- Original Message -
From: "Gabriel Ambuehl" [EMAIL PROTECTED]
buffer overflow will effectively replace the address for the MAIL FROM
command of outgoing smtp session with crap leading in email rejections
from
remote smtp servers.
Hmm that's bad...
Well, it's been around forever. I first noticed the bug in FreeBSD
3.4-STABLE. I have sent the patch to the FreeBSD team and code to test if a
particular installation is vulnerable.
The issue is as much with qmail as with the FreeBSD code. Most application
that try to discover the interfaces present on a given system use the same
system call as qmail, but with a large buffer (usually around 8k). This
buffer is big enough in 99.99% of the case. Qmail on the other hand tries to
save a few bytes here and there, so it uses the system call with a very
small buffer (256 bytes) and then increases it by a few bytes until it knows
that it got all the interfaces.
The only advantage of qmail's way is that is save some memory. The main
drawbacks are:
- it is vulnerable to the BSD socket bug (which is not limited to FreeBSD)
- it uses a fairly high number of system calls to do something that should
be done
in one system call.
Qmail can be patched for that problem as well.
(here it is)
--- ipme.c.orig 2000/04/08 18:49:08
+++ ipme.c 2000/04/09 08:14:11
@@ -48,7 +48,7 @@
if ((s = socket(AF_INET,SOCK_STREAM,0)) == -1) return -1;
- len = 256;
+ len = 8092; /* any value big enough to get all the interfaces in one read
is good */
for (;;) {
if (!stralloc_ready(buf,len)) { close(s); return 0; }
buf.len = 0;
@@ -60,7 +60,7 @@
break;
}
if (len 20) { close(s); return -1; }
-len += 100 + (len 2);
+len *= 2;
}
x = buf.s;
while (x buf.s + buf.len) {
The file to patch is /usr/src/sys/net/if.c, the attached patch is
against
the current RELENG_4 version.
Do you mean 4.0 Current or 4.0 Release (we'll use the later, if WC
sends us the CDs.. Ordered them since they're scheduled but nothing
yet arrived)?
This is for any FreeBSD to date. And as for the CD's we got ours last week,
so yours should not be too far away...
Patrick.
Re: Qmail on FreeBSD 4.0
Hi, - Original Message - From: "S.P. Hoeke" [EMAIL PROTECTED] Has anyone else encountered this? Is this a major problem? I've been running qmail on OpenBSD 2.x for about a month now, and haven't had any problems (yet) Looking quickly at the NetBSD and the FreeBSD code, I would say that they are not affected by that bug. Also solaris 2.5 is clean. I don't know about any of the linux... Patrick.
Re: Qmail on FreeBSD 4.0
Hi, - Original Message - From: "Mike" [EMAIL PROTECTED] Patrick Bihan-Faou wrote: Looking quickly at the NetBSD and the FreeBSD code, I would say that they are not affected by that bug. Also solaris 2.5 is clean. I don't know about any of the linux... Well, now that you mention it, does NetBSD also mean OpenBSD by extension? I didn't see any references to a patch in their (OpenBSD) port. Oops I meant, NetBSD and OpenBSD are not affected. FreeBSD is for all version (including 3.x). Patrick.
Re: Qmail on FreeBSD 4.0
Hi, I remember one patch in FreeBSD shortly before 4.0-release which, according to the cvs log, was supposed to fix this problem. I'll see if I can dig it up. If this bug is not fixed someone who is affected should file a PR with FreeBSD gnats. Yep, there was a first attempt at fixing it, but it was incomplete and will result in a kernel panic. I have filed a PR with the proper fix, but it has not been commited yet (PR 17311). Patrick.
Re: Qmail on FreeBSD 4.0
Good news for everybody, the FreeBSD bug I was mentioning earlier in the list has been fixed for FreeBSD 4.0 and -current. If you upgrade your system, you should not have any problems with this anymore. Patrick.
Re: Lowercasing non-ASCII chars?
Hi, Maybe I am missing the point, but I thought that only 7 bits ASCII characters were legal in an email address... Just as a side question, how do I type the following email address with my standard US keyboard ? Mikko.Hä[EMAIL PROTECTED] ? More precisely how do I type the "ä" ? Please don't take this as a US-centric comment because I am NOT a US citizen... Patrick.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html If you don't count that as a bug in qmail, then I don't know what is a bug... Patrick. "Scott Gifford" [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Matt Brown [EMAIL PROTECTED] writes: This has been a feature of recent spam, which is probably why it's now an issue. Several spam senders are now having sender addresses of spammer@spamdomain, where spamdomain resolves via DNS to '0.0.0.0'. Eventually qmail rejects the message because it recognises that it's looped around too much, of course. Right, but it's a very effective (perhaps inadvertant) DOS tool. If you can generate a stream of 10 messages/sec of these, it's the equivalent of generating about 300 messages/sec --- a great way of turning a puny dial-up connection into a mail server crushing machine. We had a spammer sending a huge number of messages to users at this address (sigh their fake bounce addresses are now getting on each others' list...), which was causing our not-processed queues to hover around 100, which was causing regular messages to be processed very slowly. Since qmail works around this simple mail loop for other address referring to the local machine, it should do so for 0.0.0.0 as well. --ScottG.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
On Thu, Jan 25, 2001 at 12:40:47PM -0500, Patrick Bihan-Faou wrote: Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html If you don't count that as a bug in qmail, then I don't know what is a bug... You quote it, but have you also read the document? Especially the "Rules" section, part 1. (and also 8.1) Well failure to recognize that 0.0.0.0 is yourself is not quite DNS related exploit. It is a bug. sarcasm I like these rules that say "yeah we are setting up a challenge, but there is no way that you could ever win it"... If you ask me, qmail is far from bug free... The first security issue with this product is itself: the code is completely obfuscated (I know I know, style is a matter of taste), there is 0 line of comments in the code (hey isn't the fact that qmail code is "small" one of its selling points ? remove comments and you reduced the code size...) Read Bruce Schneier's comment on these type of contests in his latest book... /sarcasm This 0.0.0.0 problem can easily be deflected by saying "some stupid people mis-configure DNS to cause you problem (clause 8)", but the facts are: - other MTA handle this properly (not qmail) - this sort of "attack" is in use and causing problems with site that selected qmail as their MTA So saying "it does not fit our challenge because you need to use DNS to perform the attack" is like saying "well qmail is perfectly safe if you don't use it in the real world"... Good PR move guys, and a cheap one too! Well my answer to this is "don't use qmail" Patrick.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Oh and for the fact that the challenge is closed. I mean cool more money to FSF. But still my comment is more on "what constitute a problem with qmail". I don't really care for the challenge itself, but more on the attitude of saying "this is not a qmail issue, but something else's fault". Patrick.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Read Bruce Schneier's comment on these type of contests in his latest book... Name of book, please. "Secrets and Lies" if my memory serves me right. Well my answer to this is "don't use qmail" So, what do you recommend? I am not recommending anything, choose a solution based on your needs. I looked at many MTA. Qmail is really nice for a large number of things and is usually reliable. But as I started to want things that do not fit with its design assumptions it became really difficult to play with it. As far as overall code quality and design quality goes, postfix is the best MTA I have seen so far (IMO). But as with a lot of things this is a matter of personal preferences and even religion for some. I currently use both qmail and postfix. Any new system I build uses postfix. I don't want to start a holy war on these issues as they are not worth the effort. My main motivations to move to postfix were: - qmail obscure licensing terms (for my needs) - postfix is generally more flexible and easier to configure for fancy things - postfix performance is on par with qmail - and a few other reasons that are not worth mentioning Why I used qmail in the past: - easier to configure than sendmail - more reliable than sendmail - only true alternative to sendmail (at the time) - good performance - easy to use for "simple" cases (where "simple" does not mean simplistic/useless, but means "typical") Patrick.
RE: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Hi Mark, Patrick. If you're that bitter about people accurately explaining to you that a bug is not necessarily the same as a security exploit, [...] Well I guess I disagree on the meaning of a security problem. If you can use this trick to create a DOS attack on a system, to me that would qualify as a security problem. Of course this trick will not provide the attacker with root access to the machine, so in a stricter sense it is not a security exploit, but I find that definition a bit too narrow. I am not bitter about it, I am just a bit hot tempered at times :). off topic However I find it a bit extreme to be called an idiot because I state some of my views. I certainly did not intend to call people names, and I don't think I did. I find it a bit disturbing that people are always ready to call you names as soon as you state even the slightest negative comment about qmail. I guess I will never understand that kind of passion (zealotery ?), but it is always amusing to witness. /off topic Patrick.
Re: The joy of Qmail
Hi, Well my answer to this is "don't use qmail" This note from Patrick intrigued me. It intrigued me because I remember myself being so frustrated with Qmail, I cursed and said "The only reason I am using Qmail is because it is too hard to switch over to something else." There were times when I wanted to scream in frustration. I'd like to set the record straight. I am not on a crusade against qmail. More the contrary, I find that it is a great MTA. However it has its own set of quirks that I grew more and more uncomfortable with as time passed. At this time, I use it along with other MTAs to get what I want done. And when it comes to select an MTA, I base my choice on my knowledge of the alternatives, it may or may not be qmail for a given task. As Sam mentioned, sometimes interacting with qmail is *very* frustrating. But this is the same with any piece of software that exists. The key is to use it the way it works best. Regarding the 0.0.0.0 issue and all of that I guess that people are split between calling it a bug or not. Well does it really matter ? Can the patch for this issue be integrated in qmail and the issue die off ? It seems to me that it would be more important to not have the undesirable side effect than to argue endlessly on what to call it. I would also like to add a note on qmail and security. This piece of code was created with security in mind and it fulfills this goal really well apparently(1). Security requirements are somewhat changing these days and restricting it to mean "root-exploit" feels a bit outdated now. But again, when you look at the overall picture, qmail succeeded where so many MTAs still fail miserably today. The fact that people are arguing about an issue that could eventually lead to a DOS more than 2 years after qmail was released speaks for itself: DJB did a really good job with qmail. (1) I use apparently, because it would be futile to say that it will never ever fail. It is very very very unlikely but is it impossible ? I think that if DJB thought that "impossible" is the answer, he would not have bothered with setting up a contest in the first place. He put is money behind his work and never had to pay up. Draw your own conclusion. Finally, to put my quote more in context, what I meant is that people who are not happy with free software do not have to stick with it. This does not say that qmail is inapropriate or bad or anything like that. As for my choices, I am the only person responsible for them. Patrick.
