SMTP-AUTH with no unauthenticated submission on certain ports?

Sorry if some people see this twice - I was having a posting problem
with my other news provider and this didn't make it out very far.

I'm trying to get a mail submission port (port 587) going on my Qmail
install. I have the SMTP-AUTH patch (I believe it's 0.31) running just
fine on my current install listening on port 25, and I know the
tcpserver steps to make another instance listen on port 587. My
question is, how do I have the qmail-smtp daemon only accept mail
(destined for local or remote) if the client connects with SMTP-AUTH?
Right now if a non-authenticated client connects they can send mail to
any domain in rctphosts, which kind of defeats the purpose of this
whole exercise. I know about the suggestion of running a second set of
binaries but frankly that's a little unwieldy for my purposes and I
don't intend to use it. I know the SMTP AUTH patch I'm using sets
$TCPREMOTEINFO with the authenticated user and I do have the QMAILQUEUE
patch applied, so would it behoove me to write something that sits
between qmail-smtp and qmail-queue and 550s every piece of mail that is
sent by an unauthenticated user? Or is there some tcpserver magic that
I don't know about that would tell qmail-smtpd to not even finish the
transaction unless $TCPREMOTEINFO is set to something other than "" by
the time MAIL FROM:/RCPT TO: is specified? Or even something along
similar lines? I'm open to anything but the less it involves patching
and/or running duplicate copies of very similar binaries the better.
Unless of course this functionality can be added into a future version
of a patch that pretty much everyone is using already, ergo the
SMTP-AUTH patch for example, then I'm all for it. I'm never going to
not be applying certain patches, my worry is when I start getting
patches on top of patches that things begin to break down.

Thanks in advance!

ckalin@brookfield.net wrote:

> Sorry if some people see this twice - I was having a posting problem
> with my other news provider and this didn't make it out very far.
>
> I'm trying to get a mail submission port (port 587) going on my Qmail
> install. I have the SMTP-AUTH patch (I believe it's 0.31) running just
> fine on my current install listening on port 25, and I know the
> tcpserver steps to make another instance listen on port 587. My
> question is, how do I have the qmail-smtp daemon only accept mail
> (destined for local or remote) if the client connects with SMTP-AUTH?
> Right now if a non-authenticated client connects they can send mail to
> any domain in rctphosts, which kind of defeats the purpose of this
> whole exercise. I know about the suggestion of running a second set of
> binaries but frankly that's a little unwieldy for my purposes and I
> don't intend to use it. I know the SMTP AUTH patch I'm using sets
> $TCPREMOTEINFO with the authenticated user and I do have the QMAILQUEUE
> patch applied, so would it behoove me to write something that sits
> between qmail-smtp and qmail-queue and 550s every piece of mail that is
> sent by an unauthenticated user? Or is there some tcpserver magic that
> I don't know about that would tell qmail-smtpd to not even finish the
> transaction unless $TCPREMOTEINFO is set to something other than "" by
> the time MAIL FROM:/RCPT TO: is specified? Or even something along
> similar lines? I'm open to anything but the less it involves patching
> and/or running duplicate copies of very similar binaries the better.
> Unless of course this functionality can be added into a future version
> of a patch that pretty much everyone is using already, ergo the
> SMTP-AUTH patch for example, then I'm all for it. I'm never going to
> not be applying certain patches, my worry is when I start getting
> patches on top of patches that things begin to break down.
>
> Thanks in advance!
>


First there is no tcpserver magic that can be employed since the
TCPREMOTEINFO gets sets with the authenticated user's name when the user
authenticates which is within the qmail-smtpd binary and not within the
tcpserver. TCPREMOTEINFo also gets set by tcpserver if you have it set t
o resolve the connecting IPs.

Using the same binary as you indicate will break the functionality of
your mail server. i.e. by patching qmail-smtpd to achieve the
restriction you seek for port 587 will result in your mail server
rejecting emails from remote locations destined to port 25.

You of course can patch qmail-smtpd in such a way that if a particular
environment variable is defined to check the state of TCPREMOTEINFO and
reject the sender if the variable is not set. You would then define the
variable within the run command for the port 587 instance.

AK

ckalin@brookfield.net wrote:

>
> I'm trying to get a mail submission port (port 587) going on my Qmail
> install. I have the SMTP-AUTH patch (I believe it's 0.31) running just
> fine on my current install listening on port 25, and I know the
> tcpserver steps to make another instance listen on port 587. My
> question is, how do I have the qmail-smtp daemon only accept mail
> (destined for local or remote) if the client connects with SMTP-AUTH?


I found a patch that looks like it's supposed to do this. I haven't
installed or tested it.

http://www.aripollak.com/wiki/Main/QmailMSP

It looks like it sets a new env variable for the copy of qmail-smtpd
that's running on port 587, and then adds code to qmail-smtpd to check
for that variable and behave differently. I haven't looked at the code
to see exactly what it does when that variable is set, but the doc seems
to say that it accepts only authenticated connections.

It also says that it requires your qmail to be patched with the netqmail
and toaster patches, which I haven't installed. I'm not sure what those
patches do or why they're necessary for this one, but that's what it
says.

If you're brave enough to try it, let us know how it works.

In article <msimpson-AA2722.14340921122005@sunsite.dk>,
Matt Simpson <msimpson@uky.edu> wrote:

> I found a patch that looks like it's supposed to do this. I haven't
> installed or tested it.
>
> http://www.aripollak.com/wiki/Main/QmailMSP

I looked around a little more, because I didn't want to install the
"toaster" patch that this one needs, because it adds a bunch of stuff I
don't want, and seems to require the installation of vpopmail, which I
don't use and don't want to install just to make a patch work.

I don't think all the toaster patch functions are necessary for this
patch, and it could probably be re-worked to fit on top of a simpler
SMTP-Auth patch, but I'm not that familiar with patch instructions.

Then I found the mother lode ... a different toaster
http://www.godshell.com/toaster/toaster-0.1.html

This is a site with very detailed instructions for setting up a qmail
"toaster" (I'm not sure what that term means, but it seems popular),
including a mail-submission agent (MSA) with SMTP auth. Again, this
looks like way more than I really need, but it's a little easier to pick
out the parts I want.

The MSA auth stuff seems to need only the patches for netqmail,
tls/smtp, and the qmail smtp plugin patch, qmail-spp.

I'd never heard of qmail-spp before, so I looked it up
http://qmail-spp.sourceforge.net/
and Wow!!!

It basically adds plugin support to qmail-smtpd so that you can write
your own programs to get control at plugin points and do what you want,
limited only by your own imagination. There are some plugins provided
on the qmail-spp site, but not one to require Auth checking. But that
plugin is provided back on the toaster page above.

Basically, the plugin code reads a conf file to tell it which plugins to
use. So you use a different conf file for the port 587 server. In the
toaster instructions, this is done by using tcprules to set the
SPPCONFFILE env. variable. I'm not sure, but I think this might be a
little more complicated than necessary. I think it could just be set in
the execution script. Also, I don't understand why it uses a rule to
set the variable only for client ip addresses beginning with 127. I
would think that on the 587 port, you would want it set for everybody.
If there's some good reason for setting it only for 127.x.x.x, I assume
that's why they're setting it via tcprules instead of hardcoding it in
the script. But I still can't figure out why this is necessary. In
fact, it looks like just the opposite of what you would want. Maybe I'm
missing something.