On Sun, Dec 01, 2002 at 12:33:18AM -0500, Derrick 'dman' Hudson wrote: > On Sun, Dec 01, 2002 at 01:02:32AM +0000, Pigeon wrote: > | Hi, > | > | I have the following ~/.forward: > | > | # Exim filter > | if $header_from: contains "digest" > | then pipe "/home/pigeon/bin/burster" > | save "/home/pigeon/mail/debug/burster.log" > | endif > > Ok, that's fine.
Cool. > | The program "burster", written in C, takes its standard input (the > | digest) apart into individual messages and writes them directly to > | /var/spool/mail/pigeon. > > (Is there an advantage to doing that as opposed to just receiving each > message individually?) It seems that a small number of large messages are downloaded more efficiently than a large number of small ones. Also, for example, when I go to visit my parents, I receive email on my dad's box using Messy Outlook Express. I then write it to a CD-R and take it back with me. It's easier to manage this with the messages grouped into digests. > | It does not attempt to call any other mail > | software, and always returns exit status 0. > > Don't return 0 if the operation fails. Return 1 or some other > non-permanent (see the exim docs for which return codes are permanent) > failure. If the pipe fails to exit successfully, then exim will store > the message on the queue and retry the delivery later. That's what I did originally, until I began to suspect it of causing errors. I couldn't see how it could be returning 1 and still working, but I thought I'd make certain. > | It is delivering the messages OK, and the original digests saved in > | burster.log are all there. > > Ok. > > | However, my /var/log/exim/mainlog is full of stuff like this (sorry > | for line length): > | > | 2002-11-30 22:59:38 18IGaF-0004IT-00 <= >[EMAIL PROTECTED] H=pigeon >(localhost) [127.0.0.1] U=pigeon P=esmtp S=31554 >[EMAIL PROTECTED] > > Message was received. > > | 2002-11-30 22:59:38 18IGaF-0004IT-00 => /home/pigeon/mail/debug/burster.log ><pigeon@localhost> D=userforward T=address_file > > Message was successuflly delivered to the mbox specified. > > | 2002-11-30 22:59:38 18IGaF-0004IT-00 ** |/home/pigeon/bin/burster ><pigeon@localhost> D=userforward T=address_pipe: return message generated > > There was an error of some sort with delivery to the pipe. > > | 2002-11-30 22:59:38 18IGaI-0004J1-00 <= <> R=18IGaF-0004IT-00 U=mail P=local >S=33038 > | 2002-11-30 22:59:38 18IGaF-0004IT-00 Error message sent to >[EMAIL PROTECTED] > > A bounce message was created and delivered. > > | 2002-11-30 22:59:38 18IGaF-0004IT-00 Completed > > The message is "successfully" done, as far as exim is concerned. OK, thanks. That's pretty much what I thought, but I was far from sure. > | To my untutored eye, it looks like every time it pipes a message to > | burster, some sort of error return is generated and sent back to the > | list. This despite the fact that I have made burster always return > | exit status 0, to try and stop this. > > Do you ever print stuff on stdout or stderr? If so that output will > cause a bounce message to be generated containing the output. WHACK-O! GOT IT. THANKS!!! Yes, it writes a list of messages it's successfully processed. I thought this would just go to the bit bucket if it didn't have a tty. I've now read man 4 tty and changed it so that if it can't open /dev/tty it writes this list to a log file instead. > | Am I somehow inadvertently buggering things up by sending error > | messages back every time I receive a digest? > > You'll only end up getting yourself automatically unsubscribed from > the list. So it'll only bite me. OK. > | What should I be checking? > > | Also, why does the list come from bounce-thingummy? I was quite > | alarmed when I saw all these bounce-debian-user-digest messages, > | until I checked my Windoze stuff from before I got online from Linux > | and found it had always been like that. > > Yes, it's always like that. That "bounce-thingummy" is the 'envelope > sender' address. The envelope sender is where error (bounce) messages > will be delivered to. The address looks weird, but if you dissect it > you'll notice that the beginning part is constant, followed by a > delimiter, followed by an encoding of your address. It is structured > that way so that first of all bounces go to the list management > software, not the original sender. Secondly, the mailling list > software can then automatically unsubscribe the no-longer-functioning > address from the list. I'd sort of noticed that, now I understand it better. Thanks. > One way you can monitor the problem is to use the > errors_to = pigeon@localhost > option on the director in your exim.conf. Then exim will change the > sender address so that you get the bounce instead of the list manager. > Then you can read the message exim generated and figure out how to > prevent it from happening in the first place. That's a useful suggestion. I now have: userforward: driver = forwardfile no_verify check_ancestor file = .forward modemask = 002 filter check_local_user errors_to = pigeon@localhost I poked around in /usr/doc/exim/spec.txt (which is H*U*G*E, no way have I read it all!) searching for errors_to, and it seemed that I would need to set check_local_user so that it would get the uid/gid for pigeon from /etc/passwd before running the pipe, otherwise it would fail anyway, even though burster is executable by all. Is this correct? > HTH, > -D It sure did! Just what I needed. Thanks! > One OS to rule them all, one OS to find them, > One OS to bring them all and in the darkness bind them, > In the Land of Redmond, where the Shadows lie. Tee hee - like it - how about an ascii-art Tengwar version? :-) Pigeon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
