[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Wanna make sure I don't screw the list up!



On Sun, Dec 01, 2002 at 06:33:51PM +0000, Pigeon wrote:
| 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:

| > | 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.

Possibly.  That's certainly true of my setup where I receive each
message one-at-a-time (whenever it happens to arrive) via SMTP.  I'd
expect that IMAP could be quite efficient in receiving multiple
messages in series.  Nevertheless, I have noticed a significant
difference with FTP and scp in terms of per-file overhead.

| 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.

Sure.  Unless you could install cygwin on their machine and use
fetchmail, procmail, mutt, etc. for handling the messages like usual
:-).

| > 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.

| I poked around in /usr/doc/exim/spec.txt (which is H*U*G*E, no way
| have I read it all!)

It is huge -- Philip was very thorough in documenting exim.  I use vim
to read the spec so that I can search for the desired text until I
find a relevant section.  Another handy way of using the documentation
is the HTML index at www.exim.org.  The more you read of the spec the
more you'll understand how the various components interact with each
other and the more you'll know where to look for information.
(however, don't try and read it like an exciting novel :-))

In fact, read section 18.1 (line 9360 in the spec from exim 3.35).
Section 18 explains the pipe transport.  I'd recommend adding an
option (eg -q) to your program to supress the output.  There could be
situations where you might want output even though there isn't a tty.
A command line option gives you control to choose precisely when and
where it generates output.  (and then add the -q to the pipe command
in exim's config)

| 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?

It would fail if no user had been specified on the director or
transport.  In that case the message would be frozen on the queue and
the log would say "neither director nor transport specified a user
id".  Since exim won't deliver as root ("never_users = root"), it
needs to be told who to setuid() to.  I know that I have
check_local_user on some of my directors because I want them to accept
responsibility only if the local part is a real unix user.  A case
where that is not the case is If you host virtual domains or mail-only
users that don't have an account in /etc/passwd.

| > 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? :-)

I got that from phil hunt on comp.lang.python.

-D

-- 
I tell you the truth, everyone who sins is a slave to sin.  Now a slave
has no permanent place in the family, but a son belongs to it forever.
So if the Son sets you free, you will be free indeed.
        John 8:34-36
 
http://dman.ddts.net/~dman/

Attachment: pgpz5jER4iqeu.pgp
Description: PGP signature


Reply to: