[vox-tech] introduction & debian / mutt / exim question

[Jonathan McPherson]

Hello,

> hi jonathan, and welcome.  i'm always excited to see new potential
> active members who can contribute back to lugod.  where did you do your
> undergrad?

Washington State University, Tri-Cities (branch campus). Basically, a
little night school. (-: I was casually associated with the Linux users
group there, 3CLUG (http://www.3clug.org).

> i'm writing my dissertation right now, so this needs to be short, but
> some free-flowing ideas:
>
> * sounds like you're very clueful, so i assume you've checked all the
>   log files in /var/log?

All the ones that would seem to have possible relevancy. I've had a
single message frozen in the queue for ages that has been generating
whiny log messages from exim, but today I thawed and flushed it with exim
-Rff. Other than that, the logs seem to indicate that all mail has been
delivered successfully.

> * very often, a quick scan of bugs.debian.org is useful.  see if there
>   are any bugs that mention dropping messages

A few bugs looked potentially relevant, but it appeared that my current
version of exim was already configured such that the bugs were not
relevant. The frustrating thing is that no bugs seemed to reference
_occasional_ message drops... My best theory so far is that there's
something in the way exim is labeling my messages that is causing them to
be rejected as spam or otherwise malformed mail by the target mail hosts.

> * have you checked your spool directory to see if the missing messages
>   are there?

I have now! But they aren't there. It's as if exim sends them off happily
and successfully, but sometimes the remote server silently "eats" them.

> * if you want to pull out the huge-hunking guns to fight the war, try
>   running exim with strace or ltrace.  set -s to something ridiculous
>   like 999.  you might be able to learn something if a message gets
>   dropped and you can see system or library calls, their arguments and
>   their return values.

ugh! (-: good idea, but I hope it doesn't come to that.

> * exim comes with a -d switch to set a debugging log level.  see the
>   man page for details (run exim by hand, not in daemon mode).   -df
>   looks interesting too.

hm. maybe I'll give that a shot.

> * i did a quick scan of google groups and can only find a mention of
>   exim dropping messages with fetchmail.

... which I'm not using. \-:

> * i'm sure you've thought of this, but it might be interesting to see
>   what kinds of commonalities exist between the domains that you have
>   problems with.  for example, the mail exchanger for ucdavis.edu is
>   smtp.ucdavis.edu.  oops.  nmap can't fingerprint this system.  does
>   anyone know what OS that system is running?  i'll submit it to
>   insecure.org.

hm. Haven't tried that. To be honest, ucdavis.edu is the only domain I
know of that consistently rejects the majority of my messages.

> well, anyway, i better get back to work.

yeah, me too. (-:

Jonathan.