Re: customizing qmail failure delivery
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/
Reply to: