Re: Wanna make sure I don't screw the list up!
On Sun, Dec 01, 2002 at 03:00:04PM -0500, Derrick 'dman' Hudson wrote:
> On Sun, Dec 01, 2002 at 06:33:51PM +0000, Pigeon wrote:
> | 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.
Right. SMTP is what I use, cos that's what the ISP uses.
> | 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
> :-).
That's not a bad idea, especially given the number of times I've
reinstalled Windoze on that box...
> | > 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 :-))
Hmm, that's why I like dead trees - I find them a much easier way to
build up that sort of fuzzy mental hashing table than browsing docs on
a monitor. Partly because the "novel" style is what comes most
naturally to me, and partly because I am short sighted but find that
staring at monitors with specs on gives me headaches!
> In fact, read section 18.1 (line 9360 in the spec from exim 3.35).
> Section 18 explains the pipe transport.
Hah - and tells me about your stdout/stderr bit! I see what you mean.
> 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)
Good idea - now it's (apparently!) working I can tidy it up and make
it nice.
> | 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.
OK. Looking at /etc/exim.conf there is no user or group option in
either the address_pipe transport or the userforward director. I don't
have any users with no entries in /etc/passwd. So it looks like this
should work for me, and if anything comes through that is not for a
real user I'm not gonna want it processed as a digest.
Right, this is coming together pretty well now - thanks!
Pigeon
Reply to: