patch to qmail-remote outgoingip patch
Thanks for the "qmail-remote outgoingip patch", I was able to successfully apply it (by hand) to qmail 1.03. Unfortunatly, it didn't fix the problem I was having, which was that qmail was connecting to itself (it was the backup MX for a down system) because the MX record was bound to a secondary IP address, thus looping mail. The reason is because ipme still just looks at the primary interface and qmail-remote uses that to compare against the MX record instead of the bound address. Here is a very lightly (oh, about 5 minutes) tested patch. I was kinda in a hurry and am not quite sure if [0] of a ip_address is the most or least significant octet, I was betting on it being the most but this should still work even if it's the least, as I don't think zero is legal for either. *** ../qmail-ldap/qmail-remote.cTue Jan 11 01:43:02 2000 --- qmail-remote.c Sat Feb 12 01:47:31 2000 *** *** 29,34 --- 29,35 #include "timeoutconn.h" #include "timeoutread.h" #include "timeoutwrite.h" + #include "byte.h" #define HUGESMTPTEXT 5000 *** *** 396,402 prefme = 10; for (i = 0;i ip.len;++i) ! if (ipme_is(ip.ix[i].ip)) if (ip.ix[i].pref prefme) prefme = ip.ix[i].pref; --- 407,413 prefme = 10; for (i = 0;i ip.len;++i) ! if (outip.d[0] ? byte_equal(ip.ix[i].ip,4,outip.d[0]) : ipme_is(ip.ix[i].ip)) if (ip.ix[i].pref prefme) prefme = ip.ix[i].pref; -- Aaron Nabil
Re: The Canonical Set of qmail Patches
On Sun, 2 Jan 2000, Russell Nelson wrote: listy-dyskusyjne Krzysztof Dabrowski writes: Why can't we make something like this (qmail-whatever)? This way we can port all the exisiting patches that everyone is applying these days into one bit patch and later on supporters can work off this patch to add more feautres? Applying a lot of patches to qmail these days leads me into reading diffs manualy and adding them by hand. Is this idea anything good in your opinion? Sure. Propose a canonical set of patches. About the only thing I install, and only on very high volume sites, is big-todo. Oh, and the rblsmtpd multiple -r option patch. Given that MAPS (http://mail-abuse.org) has adopted the DUL and RSS zones, you really need multiple zones. And running multiple copies of rblsmtpd (Dan's suggested solution) is too much of a hack, given the simplicity of Aaron Nabil's patch. Cool, thanks! I like being useful. :) But I was a bit surprised that you overlooked my POP "stat" bug on your page, since qmail has so few (if any) other bugs, I was kinda expecting it to get better billing. (maybe even it's own category and little box like all the other categories!) It isn't even mentioned! Considering how much a bug like that could screw up a email client, I'd certainly put it (and the big-dns thing) into the "must patch" category. It still lives at http://www.spiritone.com/~nabil/popstatbug.diff and a search of the archives would turn up some explanatory material, in case anyone needs it. -- Aaron Nabil
My non-cannonical patch list
This isn't intended to be a list of all patches, patches that I think you should apply, or anything like that. It is just part of an internal log I keep so I know what I've changed. I was hoping some people might find it useful (I certainly would have killed for something like this when I started with qmail), and was also hoping to encourage other "mature" installations to share their wisdom about what they changed in qmail. This is from a 10k user site that's been running qmail for about a year, and we are running in a single-UID environment that is very much like a POP toaster. I'm just looking at vpopmail now to handle our virtual domain stuff instead of the way we are currently doing customer domains. (some of these are specific to the alpha, and although qmail is mostly free of aligment and word-size dependancies, the "ULL" stuff are the few places it isn't) qmail-1.03/Makefile (several changes) qmail-1.03/conf-cc cc -O2 -Olimit 768 -misalign qmail-1.03/dns.c big aol DNS patch qmail-103.patch qmail-1.03/install-big.c pop bulletins qmail-popbull-1.03.patch mail-1.03/qmail-pop3d.c MAKE_NETSCAPE_WORK right from QLDAP uidl patch qmail-pop3d-1.03.diff fix for STAT buglocal fix for extra /r/n bug local fix to uidl patch local qmail-1.03/qmail-popup.c ignore after @ local lowercase username local eudora CAPA qmail-popup-CAPA-2.patch qmail-1.03/qmail-smtpd.c syslog envelope local LF RFC fix local qmail-1.03/qmail-popbull.c new file from qmail-pop3d-1.03.diff checkpassword-0.81/Makefile some changes checkpassword-0.81/checkpassword.c get data from users cdb local mess822-0.58/caltime_tai.c alpha ULL fix local mess822-0.58/caltime_utc.c alpha ULL fix local mess822-0.58/conf-cc cc -O2 mess822-0.58/conf-ld cc -s mess822-0.58/conf-ld cc -s mess822-0.58/ofmipd.c smtp auth mostly from brisby smtpd version lowercase username local ignore after @ local allow passwd retry local OFMIPLOCAL local took out PIPELINING local mess822-0.58/tai_now.c alpha ULL fix local rblsmtpd-0.70/rblsmtpd.c multiple lookup hacklocal add IP address to error local ucspi-tcp-0.84/Makefile add env.a for recordio local ucspi-tcp-0.84/recordio.c RECORDIO hack local TODO mime-bouncesqmail-mime.tgz tarpitting tarpit.patch -- Aaron Nabil
Re: Lots and lots of qmail-queue's
Martin Ouwehand writes...
Has anybody seen this: from time to time, a whole bunch of qmail-queue's
will accumulate (I'd say up to ~400), apparently doing nothing (ps shows
that most of them have the same WCHAN, but not all of them). Most of
them have 1 as PPID, a few still have qmail-smtpd as parent.
Are they all in TIME_WAIT? It's probably one machine.
Look in the logs (or use netstat or lsof) to get the IP address of the
machine.
Use my recordio patch to record dialog just for that host.
I bet you'll find qmail is dropping the connection with the "bare LF"
message. I've previously given my point of view on qmail's non-RFC
compliance on the list before, find that message, apply the patch.
This has a serious impact on the through-put and reliability of our qmail
server. Right now, killing and restarting "tcpserver [...] qmail-smtpd"
fixes the problem, but I'd really like to know what is going on to altogether
avoid this behavior. BTW, this is a Solaris 2.5 machine.
Any idea ?
Martin
--
Aaron Nabil
Re: Lots and lots of qmail-queue's
Martin Ouwehand writes... Aaron Nabil [EMAIL PROTECTED] writes: ] Has anybody seen this: from time to time, a whole bunch of qmail-queue's ] will accumulate (I'd say up to ~400), apparently doing nothing (ps shows ] that most of them have the same WCHAN, but not all of them). Most of ] them have 1 as PPID, a few still have qmail-smtpd as parent. ] ] Are they all in TIME_WAIT? It's probably one machine. It sure is. As to the TIME_WAIT, this doesn't seem to be a problem (a "netstat -an" doesn't show to many sockets, in whatever state). On mine the connections would hang around 2*MSL, but this doesn't seem to be a problem in your implementation, or you've tuned your MSL down, sometimes people do that. ] Look in the logs (or use netstat or lsof) to get the IP address of the ] machine. ] ] Use my recordio patch to record dialog just for that host. Thanks, it was very useful. You are welcome. ] I bet you'll find qmail is dropping the connection with the "bare LF" ] message. I've previously given my point of view on qmail's non-RFC ] compliance on the list before, find that message, apply the patch. You're right about the "bare LF" message. About your patch: if you mean the one where you just comment out those "if (ch == '\n') straynewline();" lines, I'm afraid that the exchange following your proposal convinced me that this isn't the right solution. Yikes! I stopped the dialog on the qmail list beacuse it's simply wasn't productive, not beacause I didn't have more to say. The author's position on the subject seems political, not technical, and the qmail list is the wrong place for a politcal debate. RFC-822 allows bare line feeds. RFC-821 prohibits termination before quit. RFC 1652 requires 8BITMIME to supress local conversions and pass data unmodified (although RFC's dealing with the MIME _body_ may disallow bare LF's, RFC 1652 defines how the MTA must handle an 8BITMIME envelope). There is no debate on these issues. It's all in black and white, and qmail violates all three. That some _draft_ version of a future RFC (that may or may not ever become an internet "standard") disallows bare LFs is a very flimsy excuse for a MTA to refuse to interoperate with a MTA that _is_ following RFC-822 _as published_. I fully intended to make sure the the working group understands that people are using the _draft_ as an excuse not to interoperate with RFC-822 MTA's, and that some language needs to be inserted about interoperability. It's perfectly OK for a 822bis MTA to not generate bare LF's itself (in fact, it shouldn't), but there are always going to be RFC-822 MTA's out there, and you need to interoperate with them. I _am_ going to take it up with the 822bis working group, but plowing through the existing 5000 messages is taking a while, and there has been some substantial discussion on the subject before. It may be a couple weeks. BUT, I'm also convinced that the present situation isn't satisfactory. It is of no comfort to me that the client is the culprit by not following some RFC if my server is on its knees ! So what can we do to avoid this ? One way would be not to _exit() in straynewline() but taking care of the state we're in is barely within the limit of my window of understanding of the source code. What do you think of this ?: Well, I guess I've already made my opinion about bare LF's known, but if your intention is still to disallow them but fix the "terminate before quit" problem, it seems like a reasonable approach. I'm not sure using a 451 error is desirable, unless your back-up MX handler is sendmail it's just going to re-queue and fail again. Might as well use 551 and be done with it. . . . Another solution for me would be to understand (and fix) why all these qmail-queue stay around when their father _exit()'s. For example, shouldn't straynewline() do some clean-up before _exit()'ing ? Thanks for any advice... I'm just guessing, but there might be some kind of deadlock or subobtimal signal handling going on with the child. Failing anything else, I'd imagine the qmail-queue would get a SIGPIPE when the qmail-smtpd dies, but purhaps it's getting masked, and you are getting zombification. Dunno, would have to look into it. -- Aaron Nabil
Re: Bare LF and zombie processes
Ferhat Doruk writes...
After some our client's Bare LF problem, I used fixcr according to DJB's
suggestion and I started qmail-smtpd process by using a command like this:
I'd suggest instead you simply patch Qmail.
Below is an article I never got around to posting, it has a patch that
should work. I guess I never posted it becuase there seems to be
some kind of unwritten rule that if qmail does something unusual or
unexpected, it's because the RFC says to do it that way. And if the
RFC says to do it some other way, the way Qmail is doing it is actually
better.
---
Qmail advertises itself as supporting 8BITMIME. In no sense whatsoever
does it support 8BITMIME (well, other than printing 8BITMIME as a
response to a EHLO).
# telnet qmail.org smtp
Trying 192.203.178.37...
Connected to qmail.org.
Escape character is '^]'.
220 ns.crynwr.com NO UCE ESMTP
EHLO erehwon.org
250-ns.crynwr.com NO UCE
250-PIPELINING
250 8BITMIME
According to RFC 1652,
A server which supports the 8-bit MIME transport service extension
shall preserve all bits in each octet passed using the DATA command.
Qmail will not pass, let alone preserve the bits of bare LF's in the DATA
phase. It detects them as "stray new lines", and bombs out in the middle
of message collection and closes the connection. This termination before
quit violates section 4.1.1 of RFC 821 and was responsible for a near
catastrophe last week which when a NT server (which consider a dropped
onnection an invitation to immediatly retry the failed message about
.2 secs later, charming) started a mailing list delivery run to our
server. This interaction resulted in several million failed messages
delivery attempts over a span of several days.
Since Qmail doesn't contain any code to check for the 8BITMIME message
type indicator (which looks like this on a MAIL FROM command)
MAIL FROM:[EMAIL PROTECTED] BODY=8BITMIME
it will also silently transform CRLF pairs into the local \n, also a
violation of RFC 1652 for BODY=8BITMIME messages.
Qmail is not RFC 822 compliant either, although it's reasonable for the
MTA to restructure bare LF's according to local end-of-line conventions,
bare LF's are perfectly _legal_ in the message body and the MTA can't
refuse to process messages that contain them, like Qmail does as
described above.
From the RFC 822 BNF...
text= any CHAR, including bare; = atoms, specials,
CR bare LF, but NOT ; comments and
including CRLF ; quoted-strings are
; NOT recognized.
Note that some measure of RFC 822 compliance can be achieved by simply
commenting a few lines in qmail-smtpd.c, like...
switch(state) {
case 0:
/*if (ch == '\n') straynewline(); */
if (ch == '\r') { state = 4; continue; }
break;
case 1: /* \r\n */
/*if (ch == '\n') straynewline(); */
if (ch == '.') { state = 2; continue; }
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 2: /* \r\n + . */
/*if (ch == '\n') straynewline(); */
if (ch == '\r') { state = 3; continue; }
state = 0;
break;
case 3: /* \r\n + .\r */
if (ch == '\n') return;
put(".");
put("\r");
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 4: /* + \r */
if (ch == '\n') { state = 1; break; }
if (ch != '\r') { put("\r"); state = 0; }
}
If Qmail wants to detect people terminating lines with bare LF's, it
needs to do that before it gets to the DATA phase.
It's somewhat amusing to note in the author's page at
ftp://koobera.math.uic.edu/www/docs/smtplf.html
"Even if this slight message corruption is acceptable for the
end users, it is dangerous behavior, since LF dot LF can legitimately
appear in the middle of a binary mail message."
that qmail won't permit a "legitimate" LF dot LF in a message either!
Qmail's MIME behavior also results in some undesirable auto-conversion
when it is in a message delivery chain,
mua - sendmail -- qmail -- sendmail
since qmail is promising to the upstream sendmail that it will
keep the 8BITMIME intact, when in fact it does a "just send 8" to
the next sendmail which will cause it to auto-convert when it
detects the incoming 8 bit data.
--
Aaron Nabil
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Robin Bowes writes... I'm seeing the above error message in the log for my MS Mail gateway (MailBeamer), but only for 1 particular message. . . . I've looked at Dan's explanation of the problem and I am aware of the SMTP LF issue. My problem is why should this error occur just for 1 message? I mean, if *every* message had the same problem, I could understand it and would put it down to a broken program, but for just 1 message to cause the error? Seems strange to me... The problem is Qmail. The message in question had a "bare LF" in it, perfectly legal, but qmail barfs on them. I just posted a message describing the phenomena in more detail. -- Aaron Nabil
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Russell Nelson writes... But I'm not sure I see where this is going. Qmail would never deliver such a message, it would barf. The case you are also stating in specifically one of delivery, where local newline standards come into play. What about the case of transport? Qmail does not distinguish between delivery and transport, therefore it can store the messages in a file which use newlines for a line terminator. Well, sort of. It doesn't distinguish between delivery and transport in the sense that it coerces all tranported message into a local delivery format. Is this supposed to be a qmail feature? Thus, qmail cannot accept bare newlines, since such a message cannot be reconstructed once it's been in a queue or mailbox file. Cannot be reconstructed? You have entirely lost me. Is that exactly the question you posed me, reconstructing a message with embedded bare LF's? Was something wrong with my answer? It also sounds like you are saying that qmail must refuse to transport messages that it doesn't have the local ability to reconstruct. That seems awfully presumptuous of qmail, denying transport say, to sendmail, simply on the basis of some potential ambiguity in qmail's local delivery environment and projecting that ambiguity onto the target delivery enviroment. It's entirely possible the the recipient MTA at the end of the transport has no such ambiguity, why in the world would qmail try to enforce such a silly restriction? Qmail is saying, "I AM QMAIL, IF THIS MAIL WAS DESTINED FOR LOCAL DELIVERY I WOULDN'T KNOW WHAT TO DO WITH IT, THEREFORE I WILL REFUSE TO TRANSPORT IT TO ANOTHER MTA THAT MIGHT POSSIBLY BE ABLE TO DELIVER IT WITH NO AMBIGUITY." Pretty damn cheeky. -- Aaron Nabil
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
D. J. Bernstein writes... Aaron Nabil writes: The message in question had a "bare LF" in it, perfectly legal, Bare LFs are now categorically prohibited by 822bis. They were never handled correctly by sendmail. The client's behavior is inexcusable. I guess not having access to 822bis, I'll have to ask for clarification. Are bare LF's themselves prohibited? Or is it the treating of bare LF's as line terminators that is prohibited? What about in 8BITMIME messages? No bare LF's allowed at all? -- Aaron Nabil
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Following up on my own message... Aaron Nabil writes... D. J. Bernstein writes... Aaron Nabil writes: The message in question had a "bare LF" in it, perfectly legal, Bare LFs are now categorically prohibited by 822bis. They were never handled correctly by sendmail. The client's behavior is inexcusable. I guess not having access to 822bis, I'll have to ask for clarification. Are bare LF's themselves prohibited? Or is it the treating of bare LF's as line terminators that is prohibited? I found draft-ietf-drums-msg-fmt, which seems to be the 822bis-in-progress. 2.3. Body The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows: - CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body. which would seem to address the question of 822bis messages. But my question about MIME messages still remains, the draft goes on to read... - Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF. Note: As was stated earlier, there are other standards documents, specifically the MIME documents [RFC-2045, RFC-2046, RFC-2048, RFC-2049] that extend this standard to allow for different sorts of message bodies. Again, these mechanisms are beyond the scope of this document. My question about 8BITMIME messages remains. Would a bare LF be legal? I'm not suggesting that a bare LF be treated a line terminator. In any case, I'm not sure where 822bis sits on the standards track, but wouldn't it be reasonable to require an MTA to interopertate with MTAs that are following real, published, approved RFCs like RFC-822 and RFC-1652? Thanks, -- Aaron Nabil
bug (?) in qmail-pop3d-1.03.diff
There seems to be a small problem in the UIDL/Status feature patch
qmail-pop3d-1.03.diff. The problem is that when using the TOP
command, it chops everything off following the added X-UIDL line.
Here is a suggested patch (also includes the extra /r/n patch) (note
"suggested", for example I couldn't figgure out what the
str_diffn(line.s, "-", 5) was supposed to be doing (yes, looks
like a part separater, but that would only be one _possible_ sep of
an infinite number (and no, it's not RFC-934, that would only be
one dash) so I whacked it out. I guess "--" would make more sense
if he really did intend it to detect a part sepr. Anyway, I'll dig up
the authors and drop them a note, maybe they can tell me.
*** /usr/staff/nabil/qmail-pop3d.c Sun Jun 27 09:07:28 1999
--- qmail-pop3d.c Wed Jul 21 19:40:02 1999
***
*** 123,134
if (!match !line.len) break;
if (match) --line.len; /* no way to pass this info over POP */
if (limit) if (!inheaders) if (!--limit) break;
! if (!line.len || !str_diffn(line.s, "Content-Type: ", 14) || !str_diffn(line.s,
"-", 5) )
{
/* add our status notification here... */
#if defined(USE_STATUS_HEADER) || defined(USE_XUIDL_HEADER)
- if (!extradone (inheaders || !str_diffn(line.s, "Content-Type: ", 14) ||
!str_diffn(line.s, "-", 5) ))
- {
#ifdef USE_STATUS_HEADER
if (m[i].flagread)
put("Status: RO\r\n",12);
--- 123,132
if (!match !line.len) break;
if (match) --line.len; /* no way to pass this info over POP */
if (limit) if (!inheaders) if (!--limit) break;
! if (inheaders !extradone (!line.len || !str_diffn(line.s, "Content-Type:
", 14)))
{
/* add our status notification here... */
#if defined(USE_STATUS_HEADER) || defined(USE_XUIDL_HEADER)
#ifdef USE_STATUS_HEADER
if (m[i].flagread)
put("Status: RO\r\n",12);
***
*** 141,150
put("\r\n",2);
#endif
extradone = 1;
- }
#endif
- inheaders = 0;
}
else
if (line.s[0] == '.')
put(".",1);
--- 139,148
put("\r\n",2);
#endif
extradone = 1;
#endif
}
+ if (!line.len)
+ inheaders = 0;
else
if (line.s[0] == '.')
put(".",1);
***
*** 152,158
put("\r\n",2);
if (!match) break;
}
! put("\r\n.\r\n",5);
flush();
}
--- 150,156
put("\r\n",2);
if (!match) break;
}
! put(".\r\n",3);
flush();
}
--
Aaron Nabil
Re: Bug in qmail-pop3d.c
Stefan Paletta writes... Aaron Nabil wrote/schrieb/scribsit: Examples: C: RETR 1 S: +OK 120 octets S: the POP3 server sends the entire message here S: . Qmail does... Examples: C: RETR 1 S: +OK 120 octets S: the POP3 server sends the entire message here S: \r\n S: . From_ CHANGES: 19960818 change: qmail-pop3d now appends an extra blank line to every message, for compatibility with popper. some clients can't deal with the right thing, unfortunately. tnx FPL. First thing I tested what seeing what cucipop does, and it doesn't add the extra line. Considering how widely used cucipop is, I figgured that would be a good indicator if this was a RFC-vs-Practice issue. But thanks, lesson learned. I'll check the CHANGES next time, and the list archives as well. -- Aaron Nabil
Re: Advantages with qmail and using reiserfs???
Troy Morrison writes... I had theorized that chunking over the 100MB mailbox was slow, and that using a maildir would be much faster, and it is except that with that many messages, the OS slows down. Does anyone have any suggestions (including a different filesystem -- we just used ext2) that might help this? Modify qmail to enforce a number of stored messages quota. -- Aaron Nabil
recordio hack
Makes recordio only record I/O if RECORDIO is in the environment.
copy at http://www.spiritone.com/~nabil/recordio.diff
diff -c dist/ucspi-tcp-0.84/Makefile local/ucspi-tcp-0.84/Makefile
*** dist/ucspi-tcp-0.84/MakefileWed Nov 11 21:32:01 1998
--- local/ucspi-tcp-0.84/Makefile Wed Jul 07 14:16:54 1999
***
*** 451,459
tcpcat mconnect mconnect-io fixcr addcr delcr argv0 recordio rts
recordio: \
! load recordio.o strerr.a substdio.a error.a str.a fs.a fd.a sig.a
! ./load recordio strerr.a substdio.a error.a str.a fs.a \
! fd.a sig.a
recordio.0: \
recordio.1
--- 451,459
tcpcat mconnect mconnect-io fixcr addcr delcr argv0 recordio rts
recordio: \
! load recordio.o strerr.a substdio.a error.a env.a str.a fs.a fd.a sig.a
! ./load recordio strerr.a substdio.a error.a env.a str.a fs.a \
! fd.a sig.a
recordio.0: \
recordio.1
diff -c dist/ucspi-tcp-0.84/recordio.c local/ucspi-tcp-0.84/recordio.c
*** dist/ucspi-tcp-0.84/recordio.c Wed Nov 11 21:32:01 1998
--- local/ucspi-tcp-0.84/recordio.c Wed Jul 07 14:03:59 1999
***
*** 7,12
--- 7,13
#include "exit.h"
#include "fmt.h"
#include "select.h"
+ #include "env.h"
#define FATAL "recordio: fatal: "
***
*** 138,143
--- 139,146
if (argc 2)
strerr_die1x(100,"recordio: usage: recordio program [ arg ... ]");
+ if (env_get("RECORDIO")) {
+
if (pipe(piin) == -1)
strerr_die2sys(111,FATAL,"unable to create pipe: ");
if (pipe(piout) == -1)
***
*** 159,164
--- 162,169
strerr_die2sys(111,FATAL,"unable to move descriptors: ");
if (fd_move(1,piout[1]) == -1)
strerr_die2sys(111,FATAL,"unable to move descriptors: ");
+
+ }
execvp(argv[1],argv + 1);
strerr_die4sys(111,FATAL,"unable to run ",argv[1],": ");
--
Aaron Nabil
Re: mess822 and ULL
Sam writes... On Mon, 5 Jul 1999, Aaron Nabil wrote: Sam writes... On Mon, 5 Jul 1999, Aaron Nabil wrote: . . . UL: x=987654321 ULL: x=87654321 Your native compiler has a bug. A warning or error would be desirable if ULL isn't part of the implementation's grammar (instead of silently emitting broken code). Or were you suggesting the reason it's broken was that it doesn't grok "ULL" but should? No, the reason its broken is because when casting an ULL to UL, the compiler appears to simply lop off the topmost digits until the number fits into an UL, instead of taking the remainder of the ULL divided by 2^(sizeof(UL)*8). That's not the problem. On an alpha, a "long long" and a "long" are both 8 bytes, no casting required. Besides, even on a sizeof(long) = 8 machine, 987654321 would still fit inside a long. This should happen automatically even if compiler does not support ULL, however, in that case, it should really refuse to compile it in the first place. Yup. Or the author could have taken avoided using non-standard C in the first place. -- Aaron Nabil
Re: mess822 and ULL
Aaron Nabil writes... That's not the problem. On an alpha, a "long long" and a "long" are both 8 bytes, no casting required. Besides, even on a sizeof(long) = 8 Oops, I meant 4, like on an x86. -a
omfmipd + Mrs. Brisby smtpd auth
I've made the few lines of changes to ofmipd.c to enable "Mrs. Brisby"'s qmail-smtpd auth patch (which works great, BTW) to drop in and work. I would have posted them, but I've made a few local changes to the code itself I didn't want to tease out unless someone was interested. -- Aaron Nabil
Re: Bug in rewriting of sender address?
David Harris writes... Russell Nelson [mailto:[EMAIL PROTECTED]] mailto:[mailto:[EMAIL PROTECTED]] wrote: Typically, Dan doesn't acknowledge bug reports. He just fixes them for the next release. Given that Dan is working on qmail 2.0, I expect that you'll find the problem gone by then. In the meantime, submit a patch and I'll put it on www.qmail.org. Weird. I'm used to seeing developers jump on bug reports and reply with some kind of answer. At a minimum "okay, we got it". That's what I've seen on other projects I participate in Apache, mod_ssl, etc... and how I operate with the little teeny projects I run myself. I think that's the difference between the "cathedral" and "bazzar" open source development paradigms. I do work on one piece of open source software where the author only acknowledges bug reports that are wrong. It bugged me at first, but I quickly got used to it. If I didn't see a refutation in a few days, I knew my fix would be in the next release. :) -- Aaron Nabil
Re: small stat bug in qmail-pop3d.c
Aaron Nabil writes...
Stat is only supposed to include un-marked-for-deletion messages for
both the size and enumeration values, not just the size as qmail
is doing.
A couple people asked me for "more info", here's an extract from
rfc1939 that describes the STAT command. The important bit is
the "Note that messages marked as deleted are not counted in either
total." line.
I don't know if this bug breaks any maintstream clients, but it sure
had a funny result on my web-based POP email tool, when you deleted
a messages the count of remaining messages would stay the same!
I've put the patch in http://www.spiritone.com/~nabil/popstatbug.diff ,
sorry if the "fuzz" is way off, I have some other patches in my local
copy.
STAT
Arguments: none
Restrictions:
may only be given in the TRANSACTION state
Discussion:
The POP3 server issues a positive response with a line
containing information for the maildrop. This line is called a
"drop listing" for that maildrop.
In order to simplify parsing, all POP3 servers are required to
use a certain format for drop listings. The positive response
consists of "+OK" followed by a single space, the number of
messages in the maildrop, a single space, and the size of the
maildrop in octets. This memo makes no requirement on what
follows the maildrop size. Minimal implementations should just
end that line of the response with a CRLF pair. More advanced
implementations may include other information.
NOTE: This memo STRONGLY discourages implementations from
supplying additional information in the drop listing. Other,
optional, facilities are discussed later on which permit the
client to parse the messages in the maildrop.
Note that messages marked as deleted are not counted in either
total.
Possible Responses:
+OK nn mm
Examples:
C: STAT
S: +OK 2 320
--
Aaron Nabil
parallel rblsmtpd
I did an experiment that may be of interest. I parallelized a stand-alone command line rbl program (1) that can check "a bunch" (I had it check 6) of rbl-ish lists in series. I used pthreads. For non-cached answers the parallel version took about 1.1 to 1.5x as long, for cached answers about 10x as long. Some simple experiments lead me to the conclusion that the pthread creation overhead is very large in comparison to the delay of just waiting for the resolver to get the answer. Compared to forking though, I'd imagine creating a thread is a stroll in the park. I'm going to see if I can hack it up (without the pthreads, tho) to drop into where rblsmtp goes. I'm guessing it will be a zillion times faster. (1) http://www.xnet.com/~emarshal/rblcheck/ -- Aaron Nabil
Questions about fastforward
I've got qmail-1.03 + fastforward running on a test machine, and it seems to deliver mail properly. We have a big /etc/aliases (from sendmail) and would like to continue to use it. My first question: Unless I'm misreading the FM, ~alias/.qmail-default (where fastforward gets invoked) is only used AFTER local lookup in the system /etc/passwd fails. Sendmail tests for an alias first, so you can overide delivery to a local user by having an entry pointing somewhere else. Would I be correct in saying the only way I could get an /etc/aliases lookup with fastforward for an existing local user is to somehow disable their account, like by chaning the ownership of their home directory? Is there any other way around this? One common entry we have in our /etc/aliases is something like... localuser: localuser,[EMAIL PROTECTED] so that a local user gets a copy of all of their email at work as well as on our machine. Is there some way to make this work in fastforward? It would appear that since localuser is local and has a deliverable home directory, it won't. Another question is about file delivery. We have a few entries like this... sales: salespersona, salespersonb, /var/spool/sales-archive since fastforward support program delivery, is there anything obvious we could use (say, like binmail or procmail) to deliver to that would keep a copy (mailbox styles, and provide some locking to prevent multiple instances from stomping on each other)? And the final question seems to have been asked many times on the mailing list, but I haven't seen a concise answer. Some of our usernames (and aliases) have dashes (hypens) in them. They seem to work correctly in the password file (longest match) but not /etc/aliases. Can this be fixed by changing conf-break, to, say a ":"? What else will this effect? Thanks! (I'd appreciate it if you would CC me on any replies to the list.) -- Aaron Nabil
