gmane.mail.nullmailer

nullmailer out-of-service problem

Uffe Jakobsen — 2013-04-19T20:36:41


Hi,

I want to report an issue that I found on one of our clients running 
nullmailer.

The client system is running FreeBSD - and it seems that the system 
owner  have performed an OS and package upgrade while was nullmailer 
running. The user/owner remembers that he specificly answered _NO_ when 
prompted if he would like to shutdown nullmailer while the nullmailer 
package was upgraded - an error from his side.

Now comes the interesting part - at some point during this operation 
nullmailer have coredumped - either during kernel or base OS upgrade or 
during ports/package refresh - I cannot say for sure.

At some point during this operation nullmailer have left a corefile 
called smtp.core in the /var/spool/nullmailer/queue/ directory - which 
is current dir for the nullmailer-send daemon. FreeBSD by default saves 
any core to the current dir of the process. Why it is named "smtp.core" 
I do not know - I havent consulted the sources yet. But it could have 
been the smtp protocol plugin that coredumped

Multiple messages per connection

Bruce Guenter — 2013-04-18T18:29:15

With the reports several people have been giving about nullmailer and
large queues, I have started to wonder about sending multiple messages
per connection.

For those that manage systems that end up sending large batches of
messages in short time frames, how important is this kind of thing? Does
opening one connection per message cause big problems or is it not so
big a deal since they are not opened in parallel?

Re: Announcing nullmailer version 1.13

Bruce Guenter — 2013-04-18T18:25:38

I've made improvements on reporting errors opening config files, but:


The program that could not be executed is given on the previous line.


The trigger file path is listed in the man page for nullmailer-queue.

Re: One more security issue I found

Steve Litt — 2013-04-18T04:45:11

On Wed, 17 Apr 2013 21:52:39 -0600
Bruce Guenter <bruce< at >untroubled.org> wrote:




Excellent! I like the troubleshooting convenience of being able to
temporarily declare and use another protocol executable, but was worried
about security. You and Sean have pointed out why I have little to
worry about.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

Re: Announcing nullmailer version 1.13

Bruce Guenter — 2013-04-18T03:56:11

I'm not sure which they you are now referring to. In any case,
nullmailer was not designed to manage a large queue. Ideally, it should
not exhibit major CPU loading issues, but it *is* completely
single-threaded, which greatly limits its ability to deal with large
numbers of messages.


Bingo.

Re: One more security issue I found

Bruce Guenter — 2013-04-18T03:52:39

The assumption being left unstated here is that an attacker could either
write to the "remotes" file or into libexec/nullmailer. I see little
reason to leave either of these writable to anything other than the
superuser (ie root), mooting this whole discussion.


No. I explicitly want to avoid anything like that to prevent issues with
adding a new protocol (QMTP? Mail over HTTP POST? I don't know)

Now, I can see it being useful to forbid "/" in the protocol name,
simply for sanity purposes, but even that seems pointless given that
root could just put a symlink in there.

IOW preventing root from shooting himself in the foot is futile.

Re: One more security issue I found

Sean MacLennan — 2013-04-18T02:51:20

On Wed, 17 Apr 2013 22:21:33 -0400
Steve Litt <slitt< at >troubleshooters.com> wrote:


Don't you need to be root to write the remotes file? Or can't you at
least set it up so only root has write access? I believe nullmailer
itself only needs read access.

If the attacker already has root access.... you are in trouble
anyway ;)

Cheers,
   Sean

One more security issue I found

Steve Litt — 2013-04-18T02:21:33

Hi Bruce,

I might as well mention one other thing I found that might possibly be a
security issue: The fact that whatever protocol is enunciated in
remotes is called as an executable in libexec/nullmailer/, without any
kind of sanity checking. For instance, I made a shellscript that prints
out arguments, environment vars, and stdin, at
libexec/nullmailer/myscript.sh, and then in remotes I set the protocol
to myscript.sh, and when I sent an email, it printed out args,
environment vars, and stdin.

Of course, this is a spectacular troubleshooting opportunity, and for
that reason I like it. But I worry that it could be a security problem
in some situations. Would it be better for nullmailer-send to throw an
error if the protocol isn't smtp or qmqp? Would the extra security of
doing that exceed the limitations to flexibility and troubleshooting?
If so, would the place to check for that be in either
send.cc->exec_protocol(),  send.cc->remote::remote() or
send.cc->load_remotes()?

Thanks,

SteveT

Steve Litt

Re: Announcing nullmailer version 1.13

Steve Litt — 2013-04-18T01:21:21

On Wed, 17 Apr 2013 17:14:53 -0600
Bruce Guenter <bruce< at >untroubled.org> wrote:


LOL, and also they were confident that a bunch of huge or misconfigured 
messages wouldn't slow the constantly spinning program (nullmailer-send)
down to a crawl.


I'll help in any way I can.


I'm not sure what you mean by FD 3, but if you mean:

stdin => 0
stdout => 1
stderr => 2
FD 3 => 3

then that sounds like an excellent idea, always assuming that there's
no way for someone else on that machine to somehow intercept file
handle 3. Your way also eliminates the problem of correctly
permissioning that extra file. I should have thought of that myself :-)

One slight problem might be that if somebody manages to replace
libexec/nullmailer/smtp with something that reads file handle 3, he
gets the password. But probably, if he's able to replace
libexec/nullmailer/smtp, there are bigger problems on that server.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performa

Re: Announcing nullmailer version 1.13

Bruce Guenter — 2013-04-17T23:14:53

They were thinking of systems that are always connected, ie on a LAN.
That's all I can figure.


No, it's no different. I will work on that angle.


... and this is where you say "what were you thinking?" :) Yes, this is
primarily because nullmailer was targeted at single-user systems, where
revealing this password has effectively no security implications. Having
said that, it could be done better.


I'm not to thrilled about having another configuration file to populate.
I would rather pass in the login credentials configured in the same file
(in "remotes") but passed in some way other than the command line or
environment. What comes immediately to mind is to pass the settings in
on a pipe, say on FD 3. Does that make sense?

Re: Announcing nullmailer version 1.13

Steve Litt — 2013-04-16T11:25:26

Hi Bruce,

First, thanks so much for Nullmailer. I couldn't get the other SMTP
pushers to work, and from what I hear, a lot of them don't have queues
(what WERE they thinking?).

I've found Nullmailer very difficult to troubleshoot because the error
messages don't include the names of the expected files, such as these:


*    Sending failed: Could not exec program
*    Could not load the config
*    Could not open trigger file: Permission denied

Does 1.13 print out the filename of whatever couldn't be exec'ed,
loaded or opened? If so, I need to change my online Nullmailer
documentation.

Also, Nullmailer 1.12 had a security problem on multiuser machines
because the password of the target SMTP server is visible with the ps
command as an argument to libexec/smtp. Passing it as an environment
variable wouldn't be any better, because it would be discoverable
at /proc/smtp_pid/environ. What would work very well would be, within
the etc/nullmailer/remotes file, instead of:

--pass=literal_password

instead to do

Announcing nullmailer version 1.13

Bruce Guenter — 2013-04-15T14:52:40

Version 1.13 of nullmailer is now available at:
http://untroubled.org/nullmailer/

See the documentation there for more details,
or join the mailing list by sending an email to:
        nullmailer-subscribe< at >lists.untroubled.org

A web-browsable archive of the mailing list is available at:
http://lists.untroubled.org/?list=nullmailer
-------------------------------------------------------------------------------
nullmailer
Simple relay-only mail transport agent
Bruce Guenter <bruce< at >untroubled.org>
Version 1.13
2013-04-15

This is nullmailer, a sendmail/qmail/etc replacement MTA for hosts which
relay to a fixed set of smart relays.  It is designed to be simple to
configure, secure, and easily extendable.

A mailing list has been set up to discuss this package.  To subscribe,
send an email to:
nullmailer-subscribe< at >lists.untroubled.org
A mailing list archive is available at:
http://lists.untroubled.org/?list=nullmailer

Development versions of < at >PACKAGE< at > are available at GitHub:
        https://github.com/bru

Announcing nullmailer version 1.12

Bruce Guenter — 2013-04-04T22:12:50

Version 1.12 of nullmailer is now available at:
http://untroubled.org/nullmailer/

See the documentation there for more details,
or join the mailing list by sending an email to:
        nullmailer-subscribe< at >lists.untroubled.org

A web-browsable archive of the mailing list is available at:
http://lists.untroubled.org/?list=nullmailer
-------------------------------------------------------------------------------
nullmailer
Simple relay-only mail transport agent
Bruce Guenter <bruce< at >untroubled.org>
Version 1.12
2013-04-04

This is nullmailer, a sendmail/qmail/etc replacement MTA for hosts which
relay to a fixed set of smart relays.  It is designed to be simple to
configure, secure, and easily extendable.

A mailing list has been set up to discuss this package.  To subscribe,
send an email to:
nullmailer-subscribe< at >lists.untroubled.org
A mailing list archive is available at:
http://lists.untroubled.org/?list=nullmailer

This package is Copyright(C) 2013 Bruce Guenter, and may be copied
according to the GNU G

Re: Ubuntu + Nullmailer tutorial

Bruce Guenter — 2013-03-25T21:14:06

Cool, thanks for the publicity.

Re: Is this intentional ?

Bruce Guenter — 2013-03-25T20:34:56

Yes. It's effectively coercion to a bool where there is no implicit
conversion available. In particular, the "mystring" type has no implicit
conversion to any type (to avoid programming errors), but does have an !
operator to test if the string is empty.

Is this intentional ?

Uffe Jakobsen — 2013-03-25T10:42:08




Hi,

I do know that this construction works - but is it intentional ?

https://github.com/bruceg/nullmailer/blob/master/src/smtpd.cc#L165

   if (!!param)
     return respond(resp_no_param);

/Uffe

Ubuntu + Nullmailer tutorial

Mikko Ohtamaa — 2013-03-25T08:28:27

Hi,

I wrote this tutorial when setting up Nullmailer for Ubuntu 12.04:

http://opensourcehacker.com/2013/03/25/using-nullmailer-and-mandrill-for-your-ubuntu-linux-server-outboud-mail/

You may find it useful.


Cheers and thanks for the great project,
Mikko

Re: Using nullmailer-smtpd for localhost:25

Mikko Ohtamaa — 2013-03-24T11:56:49

Hi,


On 24 March 2013 01:21, Bruce Guenter <bruce< at >untroubled.org> wrote:


Thank you for clarification! I'll look into options, but maybe this time I
just make those web apps talk directly to the master SMTP server.

Also sorry for using the wrong list address when posting the question.

Re: Multiple Admin Addresses

Bruce Guenter — 2013-03-14T16:15:10

No, *here* is the patch. Forgot to attach it again.

Re: Multiple Admin Addresses

Bruce Guenter — 2013-03-14T16:14:32

In fact, here's an untested patch, if you want to test. I'll add a
self-test in a bit and push it out to github.

Re: Multiple Admin Addresses

Bruce Guenter — 2013-03-14T15:01:28

config.h is generated by the configure script.

The simplest approach is actually going to be to just do something like:

adminaddr = adminaddr.subst(',', '\n')

immediately after reading it in main. The value of adminaddr is written
directly out to the message file, which uses newlines to separate
addresses. As such, turning commas into newlines will separate them.

The *best* way to do it would be to use config_readlist and then parse
it back into a single string with newlines, but that will break existing
configurations that have comments following the first line of adminaddr.