HOWTOs for send/post email using EXMH/nmh on Ubuntu/Debian?
=JeffH
My overall question is how to send/post email messages using EXMH/nmh
on the Ubuntu (nee Debian) flavor of GNU/Linux.
I think I may have this somewhat figured out, in the case of using
postfix et al to effect the send/post to my ISP's MTA using the
"relayhost" parameter of the /usr/share/postfix/main.cf postfix config
file, and also the "mts" parameter of the /etc/nmh/mts.conf config
file.
however, pointers to, or recounting of, HOWTOs decribing how others
have set it up would be helpful, because there's further detailied
issues (see below).
Additionally, it occurs to me that postfix is pretty heavyweight in
terms of likely running daemons etc, and I only need to get outgoing
email over to the ISP's MTA (which has an authn'd account for me), and
it'll take care of the proper email header rewriting/concocting. Plus
I don't want postfix's daemons running and listing in any ports for
incoming email, because I use fetchmail to explicitly go suck down my
inbound email (via IMAP).
So, is there something even more simple to set up?
I note that one can config /etc/nmh/mts.conf such that nmh's "post"
command interacts directly with an SMTP server.
However, it looks from the mh-tailor(5) manpage like one cannot
specify the SMTP port to use (it defaults to the standard one (which
my ISP isn't using (they use port 26))), nor can one specify using
SMTP-over-TLS, apparently (which I'd prefer to do (and I need to
specify the port)).
Does anyone have any feedback/thoughts?
thanks,
=JeffH
ps: turns out my system has postfix already running, it appears to
send outgoing mail by connecting directly to recipient mail systems,
rather than routing thru a given outbound MTA.
I looked briefly at nullmailer, but if I install that I have to
uninstall postfix and Linux Std Base (LSB), the latter being something
I don't want to do...
Jerry Heyman
wrote:
> Hi,
>
> My overall question is how to send/post email messages using EXMH/nmh
> on the Ubuntu (nee Debian) flavor of GNU/Linux.
>
> I think I may have this somewhat figured out, in the case of using
> postfix et al to effect the send/post to my ISP's MTA using the
> "relayhost" parameter of the /usr/share/postfix/main.cf postfix config
> file, and also the "mts" parameter of the /etc/nmh/mts.conf config
> file.
>
> however, pointers to, or recounting of, HOWTOs decribing how others
> have set it up would be helpful, because there's further detailied
> issues (see below).
>
> Additionally, it occurs to me that postfix is pretty heavyweight in
> terms of likely running daemons etc, and I only need to get outgoing
> email over to the ISP's MTA (which has an authn'd account for me), and
> it'll take care of the proper email header rewriting/concocting. Plus
> I don't want postfix's daemons running and listing in any ports for
> incoming email, because I use fetchmail to explicitly go suck down my
> inbound email (via IMAP).
>
> So, is there something even more simple to set up?
I'm running Mandriva 2008.0 (having upgraded recently from 2006.0)
and have run mh/nmh/exmh/Sylpheed over the past 20yrs.
Also, I own my own domain, so I have the additional issue of
wanting my send/return email to appear like it's coming from that
domain. To do so, I've done the following:
in mts.conf -
mts: smtp
localname: <my specific domain>
masquerade: draft_from
servers: <my ISP smtp server>
Critical for me was the 'masquerade: draft_from' and I have modified
all the components templates (components, replcomps, forwcomps) adding
a From line -
From: myid@my domain
As I'm the only user, I could have modified the system versions of
the components files, but didn't want to remember that the next
time I upgraded.
Additionally, changes that I made to /etc/postfix/main.cf
mydomain = <my specific domain>
masquerade_domains = <my specific domain>
my_origin = $mydomain
inet_interfaces = $myhostname,localhost
mydestination = localhost, localhost.$mydomain, $myhostname, $mydomain
mynetworks_style = subnet
My ISP disallows use of it's email system as a relayhost, so
that's why I've had to go through the mts.conf with masquerade_from.
The postfix MTA is necessary for both incoming and outgoing email.
It does the delivery to my id correctly when I fetchmail all my
inbound mail, and by configuring it correctly I can even use
mailx (nail on my system) to send email.
jerry
--
// Jerry Heyman | "Software is the difference between
// Amiga Forever :-) | hardware and reality"
\\ // hey...@acm.org |
\X/ http://bellsouthpwp.net/h/e/heymanj/
Joel Reicher
> I think I may have this somewhat figured out, in the case of using
> postfix et al to effect the send/post to my ISP's MTA using the
> "relayhost" parameter of the /usr/share/postfix/main.cf postfix config
> file, and also the "mts" parameter of the /etc/nmh/mts.conf config
> file.
You'll need to ask on a different forum for help with postfix, but
I've written some MH answers below.
> Additionally, it occurs to me that postfix is pretty heavyweight in
> terms of likely running daemons etc, and I only need to get outgoing
> email over to the ISP's MTA (which has an authn'd account for me), and
> it'll take care of the proper email header rewriting/concocting. Plus
> I don't want postfix's daemons running and listing in any ports for
> incoming email, because I use fetchmail to explicitly go suck down my
> inbound email (via IMAP).
I agree that if your ISP were running a standard outgoing mail service
then you wouldn't need to run your own MTA.
> So, is there something even more simple to set up?
Normally, yes.
> I note that one can config /etc/nmh/mts.conf such that nmh's "post"
> command interacts directly with an SMTP server.
>
> However, it looks from the mh-tailor(5) manpage like one cannot
> specify the SMTP port to use (it defaults to the standard one (which
> my ISP isn't using (they use port 26))), nor can one specify using
> SMTP-over-TLS, apparently (which I'd prefer to do (and I need to
> specify the port)).
Your observations are correct. You could always hack the source code
to use a different port (see mts/smtp/smtp.c) but there's no support
for TLS.
> Does anyone have any feedback/thoughts?
There is probably a way to do this without running an MTA. You could
select "sendmail" as the MH mail transport method, and then specify
whichever program you chose for mail submission. So long as that
program will handle the mail submitted on its standard input your
problem is solved.
There will certainly be software that can do this without being a
"daemon" listening on a port.
Cheers,
- Joel
Joel Reicher
> There is probably a way to do this without running an MTA. You could
> select "sendmail" as the MH mail transport method, and then specify
> whichever program you chose for mail submission. So long as that
> program will handle the mail submitted on its standard input your
> problem is solved.
I just figured out how you can do this.
Write yourself a script containing something like
#!/bin/sh
openssl s_client -connect your.isp.server:smtp -quiet
with whatever extra flags are required to make the connection, e.g.
-starttls smtp
if your ISP is using STARTTLS, and then in mts.conf put
mts: sendmail
sendmail: /path/to/the/script
I've tested this with a STARTTLS connection to a mailserver of my
choice and it works.
Cheers,
- Joel
Joel Reicher
> Write yourself a script containing something like
>
> #!/bin/sh
>
> openssl s_client -connect your.isp.server:smtp -quiet
Sorry, I forgot you said the server's listening on port 26, so that
should read
openssl s_client -connect your.isp.server:26 -quiet
> with whatever extra flags are required to make the connection, e.g.
>
> -starttls smtp
So you're not flying blind you should run this command line or script
from the shell first so you can check it's successfully opening a
connection. You'll get something resembling a telnet session if it
works, so you should see a 220 welcome line from the mail server, and
you can then type "quit" to end the session.
Cheers,
- Joel
=JeffH
> Joel Reicher <j...@panacea.null.org> writes:
>
> openssl s_client -connect your.isp.server:26 -quiet
>
> > with whatever extra flags are required to make the connection, e.g.
>
> > -starttls smtp
Hey Joel, thanks for all the info (and also to Jerry).
So, i played around with OpenSSL as you suggest. I can connect just
fine using port 26, but it appears that the exim they're running on my
hosting box doesn't support starttls. :(
It does support TLS/SSL on port 465 though, and so using OpenSSL to
connect there worked just fine.
> then in mts.conf put
>
> mts: sendmail
> sendmail: /path/to/the/script
>
> I've tested this with a STARTTLS connection to a mailserver of my
> choice and it works.
hm, ok. I guess I'm not clear on how exactly the script automagically
pipes it's stdin into OpenSSL's stdin (who then pipes the data over
the net to the other endpoint)....
but a more pressing question is that since my hosting service's MTA
doesn't support starttls, I need to authenticate over SMTP to it, and
so I need to put those (I'm guessing) scripted commands somewhere.
I looked over at the bottom of this page..
http://www.technoids.org/saslmech.html#appA
..and figured out the "AUTH LOGIN" stuff, and tried it over TLS/SSL
with my hosting MTA and it worked -- I authenticated just fine.
But again the question is now I'm not sure where/how I can script the
in-band "AUTH LOGIN" exchange, and the "get out of the way" to allow a
subsequent flow of outgoing email messages.
And a part of this is wondering how OpenSSL SMTP support works -- does
it support SMTP only if starttls is used? AFAICT from poking about,
this seems the case.
Anyway, thanks again, it seems I'm quite a bit closer to getting this
working, just a little bit more...
=JeffH
I guess the question is now
Joel Reicher
> On Dec 16, 6:19 pm, Joel Reicher <j...@panacea.null.org> wrote:
> > Joel Reicher <j...@panacea.null.org> writes:
> >
> > openssl s_client -connect your.isp.server:26 -quiet
> >
> > > with whatever extra flags are required to make the connection, e.g.
> >
> > > -starttls smtp
>
> Hey Joel, thanks for all the info (and also to Jerry).
>
> So, i played around with OpenSSL as you suggest. I can connect just
> fine using port 26, but it appears that the exim they're running on my
> hosting box doesn't support starttls. :(
It doesn't need to. STARTTLS is used to make an (initially)
unencrypted connection encrypted, such as you might want to do with
port 25 which needs to be unencrypted to begin with.
If your ISP is running port 26 as encrypted from the very beginning of
the connection, there is no need to request encryption with STARTTLS.
> It does support TLS/SSL on port 465 though, and so using OpenSSL to
> connect there worked just fine.
You mean OpenSSL didn't work on port 26? What are they doing on port
26 then? I thought you said it was encrypted.
What are they doing on port 465? I doubt they would be running
encrypted SMTP in two places, so you need to find out which port you
should be using.
> > then in mts.conf put
> >
> > mts: sendmail
> > sendmail: /path/to/the/script
> >
> > I've tested this with a STARTTLS connection to a mailserver of my
> > choice and it works.
>
> hm, ok. I guess I'm not clear on how exactly the script automagically
> pipes it's stdin into OpenSSL's stdin (who then pipes the data over
> the net to the other endpoint)....
There's nothing automagic about it; this is standard shell behaviour,
because it's standard fork() behaviour: the child process inherits all
the file descriptors of the parent. In the case of command execution
in a shell, when the command is executed in the foreground the shell
waits on the command (child) and they don't fight over stdin.
So the MH command executing the shell script is not writing to the
process running the script, but is writing to an object that *both*
the script and the command within the script have a file descriptor
for, and the command is getting all the data because the script, which
is the parent, is waiting.
OpenSSL is then sending that over the connection because that's just
what the s_client command does.
> but a more pressing question is that since my hosting service's MTA
> doesn't support starttls, I need to authenticate over SMTP to it, and
> so I need to put those (I'm guessing) scripted commands somewhere.
Authentication and encryption are two entirely unrelated things. You
need to find out what your ISP is actually requiring on connections to
their SMTP server; it's no good guessing.
> I looked over at the bottom of this page..
>
> http://www.technoids.org/saslmech.html#appA
>
> ..and figured out the "AUTH LOGIN" stuff, and tried it over TLS/SSL
> with my hosting MTA and it worked -- I authenticated just fine.
So your ISP requires both a TLS connection and SASL authentication?
Is this true on both 465 and 26 or would one port be easier to use
than the other?
> But again the question is now I'm not sure where/how I can script the
> in-band "AUTH LOGIN" exchange, and the "get out of the way" to allow a
> subsequent flow of outgoing email messages.
There might not be any need. MH has SASL support. Have a look at the
man pages for send and post. It will depend on whether your ISP is
using SASL to negotiate the encryption, but if the OpenSSL command is
working then probably not.
> And a part of this is wondering how OpenSSL SMTP support works -- does
> it support SMTP only if starttls is used? AFAICT from poking about,
> this seems the case.
I hope what I wrote above has cleared this up.
Cheers,
- Joel
=JeffH
got things working, in terms of being able to successfully post an
email message to my hosting MTA using your local-script-wrapping-
openssl hack. yea! though, i need to figure out one last (I hope)
detail wrt nmh config on my end...
On Dec 20, 12:31 am, Joel Reicher <j...@panacea.null.org> wrote:
> "=JeffH" <Jeff.Hod...@neustar.biz> writes:
>
> > So, i played around with OpenSSL as you suggest. I can connect just
> > fine using port 26, but it appears that the exim they're running on my
> > hosting box doesn't support starttls. :(
>
> It doesn't need to. STARTTLS is used to make an (initially)
> unencrypted connection encrypted, such as you might want to do with
> port 25 which needs to be unencrypted to begin with.
uh, well, I was one of the IETF participants that invented the notion
of STARTTLS, see..
http://ietf.org/rfc/rfc2830.txt
..so yeah, that's how it works.
But what I said above is that my hosting MTA simply doesn't support it
AFAICT -- I issued the STARTTLS command to it while connected to port
26 (which it's using for SMTP-over-TCP, as opposed to SMTP-over-TLS,
which it's doing on port 465).
so anyway, not a big deal, I just wanted to be clear for anyone else
who might read this thread.
> > It does support TLS/SSL on port 465 though, and so using OpenSSL to
> > connect there worked just fine.
>
> You mean OpenSSL didn't work on port 26?
correct, because the hosting MTA (which is exim apparently) doesn't
support STARTTLS (apparently).
> What are they doing on port
> 26 then? I thought you said it was encrypted.
uh, I didn't mean to say that. they are doing unencryped, but AUTH
required, SMTP-over-TCP on port 26.
> What are they doing on port 465?
SMTP/TLS/TCP with TLS "on" by default, no client-side TLS-based authn
required. SMTP AUTH required.
> > hm, ok. I guess I'm not clear on how exactly the script automagically
> > pipes it's stdin into OpenSSL's stdin
>
> There's nothing automagic about it; this is standard shell behaviour,
> because it's standard fork() behaviour: the child process inherits all
> the file descriptors of the parent. In the case of command execution
> in a shell, when the command is executed in the foreground the shell
> waits on the command (child) and they don't fight over stdin.
ah ha, thx for the rudimentary *nix programming tutorial. Now I
'member. I've never written a script that did that with stdin as yet
-- all my scripts have operated on files and or output from invoked
commands/scripts.
> Authentication and encryption are two entirely unrelated things.
understood.
> There might not be any need. MH has SASL support. Have a look at the
> man pages for send and post. It will depend on whether your ISP is
> using SASL to negotiate the encryption, but if the OpenSSL command is
> working then probably not.
ah ha. got it. thanks. I config'd a ~/.netrc file appropriately.
and also config'd /etc/nmh/mts.conf and ~/.mh_profile, and wrote a
script..
> cat /usr/local/bin/openssl-smtp
#!/bin/sh
/usr/bin/openssl s_client -connect <my mta host>:465 -quiet
And then tried this..
/usr/lib/mh/post -sasl -saslmech LOGIN /home/hodges/Mail/drafts/2777
..and it worked (!)
THANKS.
Now my question is where/how to tell /usr/lib/mh/post automagically
that it needs to use the " -sasl -saslmech LOGIN " switches ?
I tried putting them in ~/.mh_profile...
> cat .mh_profile
...
postproc: /usr/lib/mh/post -sasl -saslmech LOGIN
..but the "send" command doesn't like that...
> send drafts/2777
unable to exec /usr/lib/mh/post -sasl -saslmech LOGIN: No such file
or directory
send: message not delivered to anyone
Any ideas?
Thanks again,
=JeffH
=JeffH
>
> Now my question is where/how to tell /usr/lib/mh/post automagically
> that it needs to use the " -sasl -saslmech LOGIN " switches ?
>
> I tried putting them in ~/.mh_profile...
>
> > cat .mh_profile
> ...
> postproc: /usr/lib/mh/post -sasl -saslmech LOGIN
>
> ..but the "send" command doesn't like that...
>
> > send drafts/2777
> unable to exec /usr/lib/mh/post -sasl -saslmech LOGIN: No such file
> or directory
> send: message not delivered to anyone
>
> Any ideas?
ok, i sorta figgered this out...
I wrote another wrapper scrip...
> cat > /usr/local/bin/my-post-proc
#!/bin/sh
/usr/lib/mh/post -sasl -saslmech LOGIN $1
> chmod 755 /usr/local/bin/my-post-proc
..and then edited ~/.mh_profile...
> cat .mh_profile
...
postproc: /usr/local/bin/my-post-proc
..but when I try send, I get this...
> send drafts/2777
post: missing argument to -library
send: message not delivered to anyone
I don't see "-library" mentioned in my post manpage.
any ideas?
thanks again,
=JeffH
Joel Reicher
> On Dec 20, 12:31 am, Joel Reicher <j...@panacea.null.org> wrote:
> > "=JeffH" <Jeff.Hod...@neustar.biz> writes:
> >
> > > So, i played around with OpenSSL as you suggest. I can connect just
> > > fine using port 26, but it appears that the exim they're running on my
> > > hosting box doesn't support starttls. :(
> >
> > It doesn't need to. STARTTLS is used to make an (initially)
> > unencrypted connection encrypted, such as you might want to do with
> > port 25 which needs to be unencrypted to begin with.
>
> uh, well, I was one of the IETF participants that invented the notion
> of STARTTLS, see..
>
> http://ietf.org/rfc/rfc2830.txt
>
> ..so yeah, that's how it works.
Sorry. :) I was under the impression port 26 was encrypted and that
you were trying to issue STARTTLS on an encrypted connection, so I
inferred you didn't understand the command.
> > What are they doing on port
> > 26 then? I thought you said it was encrypted.
>
> uh, I didn't mean to say that. they are doing unencryped, but AUTH
> required, SMTP-over-TCP on port 26.
>
> > What are they doing on port 465?
>
> SMTP/TLS/TCP with TLS "on" by default, no client-side TLS-based authn
> required. SMTP AUTH required.
If they both require SASL auth then perhaps it would be easier to use
port 26 and skip the use of TLS and OpenSSL. That reduces the problem
to having the MH tools connect on port 26 instead of 25, which is
probably what you were originally asking for but I misunderstood.
If I were in your shoes I would patch the MH source and recompile, but
that's because I compile it from source to begin with. Is this
feasible for you?
If not you could always do something similar to the current hack for
the redirection.
> /usr/lib/mh/post -sasl -saslmech LOGIN /home/hodges/Mail/drafts/2777
>
> ..and it worked (!)
>
> THANKS.
>
> Now my question is where/how to tell /usr/lib/mh/post automagically
> that it needs to use the " -sasl -saslmech LOGIN " switches ?
Put it in your profile as arguments for send, i.e.
send: -sasl -saslmech LOGIN
> I tried putting them in ~/.mh_profile...
>
> > cat .mh_profile
> ...
> postproc: /usr/lib/mh/post -sasl -saslmech LOGIN
>
> ..but the "send" command doesn't like that...
>
> > send drafts/2777
> unable to exec /usr/lib/mh/post -sasl -saslmech LOGIN: No such file
> or directory
> send: message not delivered to anyone
FYI the reason that failed is that it treated the entire string as the
executable's path. The familiar 'path arg1 arg2 ...' form actually
results from parsing of the command line that the shell does, i.e. it
breaks the string up according to a field separator which is usually
whitespace. This parsing is extra work that non-shell "command
launchers" usually don't do.
Cheers,
- Joel
=JeffH
On Dec 20, 6:22 pm, Joel Reicher <j...@panacea.null.org> wrote:
> Sorry. :) I was under the impression port 26 was encrypted and that
> you were trying to issue STARTTLS on an encrypted connection, so I
> inferred you didn't understand the command.
no worries 8^)
> If they both require SASL auth then perhaps it would be easier to use
> port 26 and skip the use of TLS and OpenSSL.
well, the SASL-based AUTH LOGIN over OpenSSL w/o client-side authn is
fine by me and it works (thanks to your help), so I'm just going to do
that.
In general, we all ought to try to move towards using encrypted
connections where feasible. Of course for the bigger picture we need
mutual authn like everywhere, but that's off topic for here.
That reduces the problem
> to having the MH tools connect on port 26 instead of 25, which is
> probably what you were originally asking for but I misunderstood.
well, yeah, that was at the root of the question, but I also wanted to
do TLS/SSL if possible, so my posting was multi-layered. no worries.
> If I were in your shoes I would patch the MH source and recompile, but
> that's because I compile it from source to begin with. Is this
> feasible for you?
well, yeah it's of course feasible, but then it's one more locally-
hacked thing to manage across Ubuntu distro upgrades, so I'd rather
not.
> Put it in your profile as arguments for send, i.e.
>
> send: -sasl -saslmech LOGIN
AH HA!! *That* is the magic bullet, thanks!
Now it works, I can send email via
exmh/nmh/openssl ---[SMTP/TLS]----> mail.myhost.com:465
super, many thanks :)
> FYI the reason that failed is that it treated the entire string as the
> executable's path.
yep. hence my writing another wrapper script that i noted in a
subsequent post, but that didn't work cuz of some "library" problem
something complained about, but now it doesn't matter cuz of the
little "send:" .mh_profile hack noted above.
Ok, I'm set, thanks again,
=JeffH
http://xri.net/=JeffH
Joel Reicher
> Hey Joel, thanks again for all the help. I got it working -- yeehaw.
Excellent. :) If what you now have is reliable and correct (and it
should be) then it's much better than running your own MTA.
> On Dec 20, 6:22 pm, Joel Reicher <j...@panacea.null.org> wrote:
>
> > If they both require SASL auth then perhaps it would be easier to use
> > port 26 and skip the use of TLS and OpenSSL.
>
> well, the SASL-based AUTH LOGIN over OpenSSL w/o client-side authn is
> fine by me and it works (thanks to your help), so I'm just going to do
> that.
>
> In general, we all ought to try to move towards using encrypted
> connections where feasible. Of course for the bigger picture we need
> mutual authn like everywhere, but that's off topic for here.
I agree that encrypted connections are better, but the problem with
email, as you probably know, is that it works with relaying rather
than a sender-to-recipient connection. While either end of that
delivery path can insist on encryption, the current state of affairs
makes it impossible, in general, to ensure the relaying in between is
encrypted, or even that the relays themselves are trustworthy.
IMHO S/MIME is the correct solution to securing email, because it
secures the message rather than the transport.
> > If I were in your shoes I would patch the MH source and recompile, but
> > that's because I compile it from source to begin with. Is this
> > feasible for you?
>
> well, yeah it's of course feasible, but then it's one more locally-
> hacked thing to manage across Ubuntu distro upgrades, so I'd rather
> not.
Fair enough. I can't help but wonder if SMTP on a port other than 25
has been an issue for other users. It might be worth my while making
it configurable in the next release of nmh (whenever I or someone else
gets around to it).
Cheers,
- Joel
=JeffH
> "=JeffH" <Jeff.Hod...@neustar.biz> writes:
> > Hey Joel, thanks again for all the help. I got it working -- yeehaw.
>
> Excellent. :) If what you now have is reliable and correct (and it
> should be) then it's much better than running your own MTA.
yeah. I've had to hack sendmail.cf a little bit way back in the dark
ages and don't wish to have to do that again/anymore.
> > On Dec 20, 6:22 pm, Joel Reicher <j...@panacea.null.org> wrote:
>
> > > If they both require SASL auth then perhaps it would be easier to use
> > > port 26 and skip the use of TLS and OpenSSL.
> I agree that encrypted connections are better, but the problem with
> email, as you probably know, is that it works with relaying rather
> than a sender-to-recipient connection.
yep.
> IMHO S/MIME is the correct solution to securing email, because it
> secures the message rather than the transport.
agreed wrt S/MIME, but I'd still also use a stronly-mutually-auth'd
connection for submission and retrieval.
> > well, yeah it's of course feasible, but then it's one more locally-
> > hacked thing to manage across Ubuntu distro upgrades, so I'd rather
> > not.
>
> Fair enough. I can't help but wonder if SMTP on a port other than 25
> has been an issue for other users.
"users of nmh et al" you mean I guess.
> It might be worth my while making
> it configurable in the next release of nmh (whenever I or someone else
> gets around to it).
yep, that'd be good.
thanks again,
=JeffH