On Mon, Feb 17, 2003 at 07:10:14PM +0100, Christian Jaeger wrote: > At 21:25 Uhr -0800 16.02.2003, Ted Deppner wrote: > >On Sun, Feb 16, 2003 at 08:02:45PM +0100, Christian Jaeger wrote: > >> - By default, qmail tries for a week to deliver a message before it > >> gives up. No warning whatsoever is sent to the sender before. Is > >> there no way to make it send a delay warning after 4 hours? > > > >man qmailsend, look for "queuelifetime". > > That's not really what I'm asking for, I think it's ok to let qmail > try for a week, but I want to get informed about the delay soon.
Missed that. Use "find /var/qmail/queue/info/ -mmin +160 -type f" to find the list of messages in queue longer than 4 hours. The contents of the info/*/MSGNUM file contains the envelope from, to which you can send bounces (if non empty). Obviously you'll need to make sure you don't duplicate delay warnings is left as exercise for the reader. > Thanks for the link. Well, why "not true", qsbmf is plaintext, and > the original mail is appended unformatted :) - and from the view of > my mailer the whole qsbmf is unformatted as well. It *is* formatted, meaning that it follows a defined format. Not the format you wanted, but then you didn't write qmail. > It should not take significantly more cpu to use mime boundaries > instead of the "--- Below this line is a copy of the message." > boundary. I'm not sure what if any rules there are about multiple levels of MIME encapsulation. Never the less, your desire is really based on the mail reader you're using (or your users). I find it quite easy to edit bounce messages from a qmail server... just delete the offending topmost lines and resent. Very easy from inside of mutt. > As far I can see, D.J.Bernstein states in qsbmf.txt that he does not > want to follow the rfc's because of the complication in correctly > *parsing* mime messages (as opposed to building them). But is it any > better to have to write code for the qsbmf format, now that many mime > parsing libraries exist (i.e. D.J.B's own fast C library)? Again, I'm not sure of the guidelines regarding multiple levels of MIME encapsulation. In other words, the behavior you're wanting may only be available because Microsoft popularized it... not because there's a standard that every MUA can follow. I'm not sure on this point. I will say that the standard bounce format meets all of the issues you've raised for my choice of mailreader. > http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html > which (paragraph 3.3) says exactly what I think. Potentially valid concerns if you're concerned about MIME... > >This is a DoS in the making. Perl is really way too expensive for > >something so trivial. Maybe sh could echo your text and exit 100? > > Why should perl be slower than sh (at least when using bash for sh)? Perl takes a step to compile, and typically has more library type code to load than a shell. > In fact, with sh you'll probably pipe the message through sed or > something to get the \r\n line endings, and I'm pretty sure that > would be slower. > (..yep it is: > time for ((i=0; i<100; i++)) do ./refuse.pl > /dev/null; done > time for ((i=0; i<100; i++)) do ./refuse_lf.sh > /dev/null; done > time for ((i=0; i<100; i++)) do ./refuse_using_sed.sh > /dev/null; done Did you try /bin/echo? or /bin/cat? The point is that echoing a block of text and then exiting with a 100 isn't something that needs perl. Shell tools (not necessarily another shell script) should be sufficient and much faster. Remember, raw clock time isn't the only factor... system time, disk time, memory time are all important. And you certainly don't need a heavyweight shell like bash if you do invoke a shell. > > > *BUT* this still gives this ugly, non structured failure notice as > > > described above, in particular, if I print german umlauts from the > > > script, they are not sent correctly. > >> (There is a program "bouncesaying" which has exactly the same drawbacks) > > > >It's not all that, see http://cr.yp.to/proto/qsbmf.txt again. > > (What do you mean with it's not all that?) Meant "it's not all that" [bad that you're making it out to be]. Speaking english natively, I've no idea what the importance of a German umlaut is (I know it's char encoding problem you're raising, but I don't know if it's an annoyance like a missing bit of punctuation, or if "mother" is suddenly "bitch" or something equally offensive). As you've noted, the qmail bounce email is not MIME, therefore I'd expect NO valid context in which to place an umlaut. No char-encoding is present, and you're just as likely to get your umlaut on your PC as your friend would be to get the (C) copyright symbol courtesy Windows. It's a moot point, move on. > The reason I'm asking here is that I'm wondering to how you solve the > problem. I don't like playing test bunny for patches that you haven't > tried :). And are they really what I'm looking for?: Only you can answer that... > http://www.qmail.org/qmail-bouncecontrol-1.03.patch > As far I can see does not solve the problem with umlauts (it does not > add a content-type header with charset). It simply replaces the first > paragraph (and the subject). The result will not only not be RFC > compliant, but not even comply to QSBMF. It will do what you tell it too, including allowing you to do things non QSBMF compliant. You are still in control. > So I still have no solution. There might not be one that suits you (yet). Still, since there doesn't seem to be a ready fix patch sitting on the proverbial internet supermarket shelf, either no one else thinks it's a problem, or you're just lucky enough to finally put words to what everyone else has been lurking for. -- Ted Deppner http://www.psyber.com/~ted/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
