[clue-tech] logs

[Jed S. Baer]

On Mon, 13 Apr 2009 14:05:36 -0600 (MDT)
David L. Willson wrote:

> If it's not one thing, it's another.  I setup the root alias on all my
> clients' server to point to an un-filtered email address of mine.
> Sometimes, the messages are blocked because the sender domain's not
> valid, and sometimes I end up with strings of undeliverability, like
> the one attached.  Has anyone come up with a good, reliable way of
> doing this?

Sounds like the address you're using _is_ filtered. Or there are other
delivery problems, which I can't tell from what you provided (not that I
necessarily could in the first place, but I didn't see the usual 5nn
error codes I'd expect.)

You might want to try some whitelisting that occurs before any of the
other SMTP checks.

Not sure what you've got running on the client machines. Maybe you could
pull the e-mail, instead of pushing it? I'm thinking something like
running fetchmail in a cron job every 15 minutes or whatever, on the
machine which is the target of all this forwarded mail. Since I haven't
used fetchmail, I don't know what needs to be on the other end for it to
work. http://fetchmail.berlios.de/ says it works with almost
everything. If you don't want to have an open IMAP/POP/whatever port, use
port forwarding and tunnel fetchmail through ssh (since you were talking
about using scp anyway).

Instead of periodically copying root's spool, you could use procmail to
deliver messages to an MH type mailbox (which is a directory tree). Then
each mail message is a seperate file, so you don't have to worry about
date-stamping your spool copy. Then you could use rsync to synch each MH
directory tree back to your target machine, and import the messages
into your MUA (not sure on the last step -- I'm 99% sure it's do-able,
just not sure on how, 'course, depends on your MUA). You'd want to
periodically clean out the MH dir on each client machine (find
{incantation for files older than n days} -exec rm {} \; -- bearing in
mind the previous discussion on mtime ;)), so don't use any of the
--delete options in your rsynch transfer.

jed