Re: Frustrating mutt address problem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday, May 25 at 08:30 AM, quoth Seth Williamson:
> To answer your question, I considered using msmtp, but there is no
> deb of it available via Ubuntu. I am using Kubuntu at home.
Huh? http://packages.ubuntulinux.org/dapper/mail/msmtp
And if that fails, my understanding is that Ubuntu users can use
Debian packages: http://packages.debian.org/testing/mail/msmtp
> Maybe this is a noob thing, but I am afraid of compiling programs on
> my own because of potential dependency problems. It has been my
> understanding that, if I don't install a program with apt-get
> install, I'm opening myself up to dependency hell.
>
> Is this true or am I worrying needlessly?
Mmm, no, not exactly. So-called "dependency hell" is typically an
artifact of packaging systems (i.e. rpm or deb/apt) which may have
things like circular dependencies (e.g. foo depends on foo-dev, but
foo-dev depends on foo), contradictory dependencies, or massive trees
of dependencies that are really unnecessary (for example, in order to
install subversion, you may be required to install apache, and all
that that requires as well). Even more fun is when something (foo)
depends on a specific version of something else (bar-2.0) but doesn't
say that it requires bar-2.0, so when you install bar-2.5, foo gets
mad, but can't tell you why. According to wikipedia
(http://en.wikipedia.org/wiki/Dependency_hell):
Dependency hell is a colloquial term for the frustration of some
software users who have installed software packages which have
dependencies on specific versions of other software packages.
Hand-installed software does not have the kinds of "dependencies" that
packaged software does, and thus is not susceptible to the standard
dependency hell.
When you install a program by yourself, all that is happening is
you're essentially asserting that you will be maintaining that program
by yourself. The standard worst-case scenario is that during an
upgrade of other system software, you upgrade a library that the
software you've compiled yourself relies upon (or, more specifically,
your compiled software relies upon a specific version of such a
library). What will happen is when you try to use the software, it
will refuse to run. All you need to do to recover is to recompile the
software (especially easy if you kept the source around) so that it
works with your current set of libraries. This is only likely with
some kinds of software - things like msmtp, mutt, and so forth rarely
tie themselves to specific versions of libraries, so they almost never
suffer from this sort of problem.
>> What is the rest of your mutt configuration that might affect this?
>
> That's what I don't know. I have gone over the entire muttrc several
> times, trying to see what might be doing this. I am unable to see
> anything that would be forcing it to address all e-mails to
> seth@xxxxxxxxxxx
So, what mutt does is it composes a command like so:
$sendmail -f $from_addr $to_addrs
You can make a small shell script to find out exactly what arguments
mutt is giving to ssmtp. For example, this script:
#!/bin/sh
echo $@ > /tmp/ssmtp_args
If you save that to a file, make it executable, and set your $sendmail
to that, it will tell you how mutt is attempting to call ssmtp when
you send mail (the arguments will be stored in the file
/tmp/ssmtp_args). Once you do that, you can attempt to re-create the
problem without mutt ("by hand"). I'll explain more in a moment.
>> Why are you thinking that mutt is to blame?
>
> I don't know for sure that it is. One possibility is that it's a line in
> muttrc that I don't understand, either missing or set incorrectly.
>
> More generally, it seems that ssmtp is actually getting the mail as far as
> my ISP's server, where it gets the "mailbox full" error message, so it
> seemed that perhaps ssmtp might be working OK, and that the incorrect
> address problem might be from an incorrect or missing line in muttrc.
The above trick, with the shell script, will demonstrate whether it's
probably mutt's fault or not.
>> Have you tested trying to use ssmtp to send a mail by hand (i.e.without
>> mutt)?
>> What have you tried? What happened? What were you expecting to happen?
>
> No, I haven't. I don't know how to do it. Not sure what you mean by
> "send a mail by hand." I have sent mail from the console using SMTP as
> described in section 10.2 of Rutebook (http://tinyurl.com/nmw9w), but I
> don't know how to get ssmtp involved in it.
>
> If you could outline the procedure, I'd be grateful.
Generally, this works:
echo foo | ssmtp -f me@xxxxxxxx you@xxxxxxxxx
That will send a message containing the text "foo" to you@xxxxxxxxx
from me@xxxxxxxx, or at least, it's supposed to. From the information
above
>> Why did you decide not to use the advice I gave you the last time you
>> asked this question on this mailing list?
>
> You mean the patch from Brendan Cully? The url you quoted was unavailable
> all yesterday afternoon and up til I quit working on this yesterday
> evening. A bigger problem is that I am such a newbie that I don't know
> how to install or run a patch in the first place. I have learned what
> little I know about Linux from books, no humans to teach me in person, and
> this is something I haven't figured out how to do. Generally speaking I
> am afraid to do something that might disable my entire box at home, given
> that I do a lot of freelance work that depends on having that box working
> for me. In the early days with Linux I compiled a program or two myself
> and wound up with horrific problems that eventually forced me to nuke the
> hard drive and start over again. I am hoping to avoid such trouble in the
> future. Undoubtedly if I knew more about how to do such things, I
> wouldn't be so fearful, but I just don't know enough about compiling
> programs or running patches.
Wow. What were you trying to compile? (not that it matters at this
point, I'm just curious)
Anyway, just fyi, patches are done to source-code. A patch is a text
file of a specific format that records a set of changes to other text
files (e.g. the code of a program). They are generally applied by
running:
patch -p1 < /path/to/patch
...from the directory containing the files that need to be patched.
Now, depending on how the patch was made, though, that "-p1" argument
may need to be different: if when you run the patch command it says
something like "where is file xyz?" you control-c out of it, and run
"patch -p0 < /path/to/patch" instead.
> However, if you think that compiling msmtp is the way to go, I will
> try it when I get home this evening and see what happens. I notice
> there are instructions at that website for doing so, so maybe I can
> manage it. I am guessing I'd have to do an apt-get remove on ssmtp
> first to get it off my system?
Nah, they can coexist. You'll eventually want to keep either one or
the other, but that's just to save disk space. And you don't *have* to
compile msmtp; plenty of people have done it for you (see the links at
the top of this email).
~Kyle
- --
Carpe per diem---seize the check.
-- Robin Williams
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iD8DBQFEda/6BkIOoMqOI14RAhCJAJ92CNfm102q9Z4rmnY7Or1Q+jv+FwCg0Z1E
lZkCwPbQWpUVg2wMGyAY0M4=
=fzQb
-----END PGP SIGNATURE-----