# qmail question - allowing relay from local LAN? [SOLVED]

## trellis

I'm a complete qmail newbie, but I've managed to get qmail working, the only problem is I want to allow relaying from addresses on my local lan. 

I have added the necessary lines to /etc/tcp.smtp, e.g.: 

x.x.x.x:allow,RELAYCLIENT="",RBLSMTPD=""

Rebuilt the database (the comment at the top of tcp.smtp explaining how to do this is totally wrong, BTW) , and restarted svscan, and even rebooted the entire box!

Still getting the error that "host is not in rcpthosts" when trying to relay. 

What have I screwed up?Last edited by trellis on Wed Feb 16, 2005 10:19 pm; edited 1 time in total

----------

## cselkirk

When you say addresses do you mean all address on the subnet? I see in the above rules you have "x.x.x.x:allow" which would define one host, the "x.x.x.x".

If this is not what you want then the following maybe what you are looking for:

```
192.168.:allow,RELAYCLIENT=""
```

Similarly for whatever class subnet you happen to be using.

Also, you say the comment at the top of tcp.smtp is wrong, I can't verify that as my tcp.smtp didn't come with a comment, anyhow, incase this happens to be something you are running foul of here is what it should be:

```
tcprules tcp.smtp.cdb tcp.smtp.tmp < tcp.smtp
```

Similarly for other *tcp.${SERVICE}, and restart svscan.

HTH

----------

## trellis

Thanks for that. 

I have a /29 subnet, and couldn't find any examples dealing with subnets so I thought it would be safer to enumerate all the addresses (there are only 6 of them!) 

It definitely did rebuild the database (I checked the time stamp), so I'm now wondering whether it matters where the "allow" lines appear in the input file? I put them right at the end - will this work?

----------

## cselkirk

tcpserver will use the first rule it finds (begining with the top most rule I believe). eg:

```
192.168.1.1:allow,RELAYCLIENT=""

192.168.1.2:deny
```

So if the $TCPREMOTEIP is 192.168.1.1 it will match the first rule, and the connection will be allowed, and if the $TCPREMOTEIP is 192.168.1.2 it will be denied.

A rule like ":deny" would tell tcpserver to drop all connections that aren't handled by more specific rules.

You can abreviate the address range in a number of ways (as I showed above with the 192.168.:allow example) you can give a range in a similar manner, eg:

```
192.168.1.1-10:allow,RELAYCLIENT=""
```

This would allow relaying from 192.168.1.1 to 192.168.1.10 only.

I think perhaps your rules are correct, at least from the snippits you've posted this would seem the case. I'm almost tempted to think that your *.cdb's are not read by tcpserver. I would check to see where tcpserver is reading it's cdb's from ..

```
% grep cdb /service/qmail-smtpd/run
```

In my case they are read from /etc/tcprules.d. I would check this is the case WRT your install (older qmail ebuilds used /etc for storing the cdb).

BTW, I was quite wrong in saying that you need to restart svscan as tcpserver re-reads the *.cbd on each connection (what was I thinking).

HTH and let me know how you get on ..

----------

## cselkirk

Forgot to mention that you can check the rules in your cdb with the following:

```
TCPREMOTEIP=192.168.1.1 tcprulescheck /etc/tcprules.d/tcp.smtp.cdb
```

The output should show if 192.168.1.1 has the environment variable RELAYCLIENT="" set. I would run this for the IP of the mailserver itself and a client IP you expect should be able to relay.

HTH

----------

## trellis

Many thanks for your help, but still no luck, unfortunately  :Sad: 

```

qmail-smtpd # grep cdb run

    /usr/bin/tcpserver ${TCPSERVER_OPTS} -x /etc/tcp.${SERVICE}.cdb \

etc # TCPREMOTEIP=<ip-address> tcprulescheck /etc/tcp.smtp.cdb

rule <ip-address>:

set environment variable RELAYCLIENT=

set environment variable RBLSMTPD=

allow connection

```

where <ip-address> is an IP address on my subnet from which I am attempting to relay via qmail. 

All looks perfect, yet when I attempt to relay mail to anywhere other than those domains set up in rcpthosts, I get the following error: 

```

sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)

```

Now, to me that suggests either that RELAYCLIENT has not been set, or that the smtp daemon is ignoring RELAYCLIENT. 

But I'm stuck as to why it isn't working - it all looks fine to me:? 

Very odd.

----------

## cselkirk

OK, well at least we know your rules are in order .. hehe.

I'm inclinded to agree with your appraisal, however I should ask the obvious question.

So, /var/qmail/control/rcpthosts contains a valid FQDN? And that FQDN is the machines name (qualified by reverse DNS lookup)?

----------

## cselkirk

After a little digging I come accross this. So, your not the only person witht this particular problem. It is possible the tcpserver is broken (at least under some installs), aggressive CFLAGS perhaps?

I'm less inclined to think it's the compile process, but perhaps. Have you checked bugs.gentoo.org?

----------

## cselkirk

Just a thought, I wonder if this is related to the +ipv6 bug.

Try re-mergeing sys-apps/ucspi-tcp with -ipv6.

```
emerge -p -v sys-apps/ucspi-tcp
```

You should see +ipv6 .. so we'll disable via package.use

```
echo "sys-apps/ucspi-tcp -ipv6" >> /etc/portage/package.use

emerge sys-apps/ucspi-tcp

/etc/init.d/svscan restart
```

HTH

----------

## trellis

I have checked bugs.gentoo.org, but couldn't find any relating specifically to this problem (although I couldn't think of a search term to achieve less than 200 results!) 

Should I raise a new bug?

----------

## cselkirk

 *trellis wrote:*   

> I have checked bugs.gentoo.org, but couldn't find any relating specifically to this problem (although I couldn't think of a search term to achieve less than 200 results!)

 

Try the search term "ipv6" .. I'm almost certain this is the issue. I would first try re-merging with USE="-ipv6" and test relaying from the clients listed in your cdb's, that is before opening a new bug.

----------

## trellis

Thanks - will try that, but which packages should I re-merge? Should I un-merge them first? Will I lose my configs?

----------

## cselkirk

I'm sorry, I completly omited to say which packge, "sys-apps/ucspi-tcp". And, no you don't need to unmerge and there are no configuration files that come with the package to etc-update.

----------

## trellis

many thanks! It is busy emerging as I write this...  :Smile: 

(Being of a semi-paranoid nature, I backed up my config files anyway!)

----------

## Bojan

I hope this will help ... I had similar problems with qmail when I was trying to enable relaying mail for LAN users. 

It turned out that I've made a mistake in FQDN section of /var/qmail/control/servercert.cnf

Perhaps it is worth re-checking that ...

----------

## trellis

 :Laughing:   It worked! 

Looks like it was associated with ipv6. 

Many thanks for all your help, cselkirk ! 

Thanks to you, I now have a fully working qmail server  :Very Happy: 

----------

## cselkirk

Ahh good .. now to turn you into the spam kings .. hehe

The bug has been reported, but it's probably a good idea to file another bug WRT the guide as the issue should probably be mentioned there.

Good your up and working ...

----------

## trellis

The guide I was working to was the Virtual domains qmail/courier-imap one, but I didn't bother with courier-imap - just used qmail's own pop3d. This guide didn't mention configuring relaying in this way - I made it up  :Smile: 

----------

## cselkirk

Still, the Guide should probably mention this as a gotcha. uspci-tcp is a component/dependency of qmail and so anyone installing qmail on gentoo will encounter this problem. Not only if relaying, tcpserver looses the ability to understand ipv4 addressing. Fortunatly tcpservers default behavior is only to allow relaying when explictly defined and even an empty cdb will still only mean ":allow".

I wasn't saying you specificly need to report it but the guides author should probably get a heads up.

----------

## cmoad

I have done everything on this forum and I am still having problems.  I can receive mail and send to a local account but weird things happen when I try to send to a remote account.  First of all, everything acts as if it works fine.  The qmail-smtpd log acts as if the mail was processed fine.  The weird thing I am seeing is a spawned process that is not doing anything.

If I send an email from cmoad@mydomain.com to cmoad@gmail.com for example, I see a process named:

 *Quote:*   

> qmail-remote gmail.com cmoad@mydomain.com cmoad@gmail.com

 

This process never goes away!

Any ideas?

Thanks for the help.

----------

## j-m

 *cmoad wrote:*   

> 
> 
> Any ideas?
> 
> 

 

Sure...

```

ditch qmail

emerge postfix

```

I hate to do this but I really have to say that qmail without those loads of third-party patches is missing the basic functionality of modern MTA. All the stuff is messy and unnecessarily complex and therefore prone to errors and problems. It´s just about time to say goodbye...  :Twisted Evil: 

----------

## cmoad

Haha!  Did you post this exact response in another thread?  I swear I saw it there too.  One question to you though, is the gentoo guide, http://www.gentoo.org/doc/en/virt-mail-howto.xml, a good one to follow?

----------

## j-m

 *cmoad wrote:*   

> One question to you though, is the gentoo guide, http://www.gentoo.org/doc/en/virt-mail-howto.xml, a good one to follow?

 

Yes, it works very well. This one is also nice...  :Wink: 

----------

## cselkirk

 *j-m wrote:*   

> I hate to do this but I really have to say that qmail without those loads of third-party patches is missing the basic functionality of modern MTA. All the stuff is messy and unnecessarily complex and therefore prone to errors and problems. It´s just about time to say goodbye... :twisted:

 

Nonsense. Would you say the Linux kernel is "missing basic functionality" due to the fact that third party patches are applied? Take a look at any of the *-sources ebuilds and the number of patches available via other "third parties", and why stop there .. the number of ebuilds that don't get patches applied would probably be in quite a distinct minority.

The fact that qmail is patched by vendors says absolutly nothing about its functioning as an MTA. 

As to "messy and unnecessarily complex" this is simply a matter of your opinion, and as such I won't bother commenting on.

----------

## j-m

 *cselkirk wrote:*   

> 
> 
> Nonsense. Would you say the Linux kernel is "missing basic functionality" due to the fact that third party patches are applied? Take a look at any of the *-sources ebuilds and the number of patches available via other "third parties", and why stop there .. the number of ebuilds that don't get patches applied would probably be in quite a distinct minority.
> 
> 

 

Plain vanilla qmail does not contain any of those patches. Please look at the ebuild and the obnoxious number of patches it downloads and applies for you. You would have to do all the work yourself, if you downloaded vanilla qmail from its (largely unmaintained) homepage. Without those patches, the package is basically unuseable. Think of this like if you downloaded vanilla kernel and would have to patch it with ext2/ext3. Now if you could look at postfix ebuild and compare. This is really funny.

E.g., qmail is unable to reject email when the mailbox (local or virtual) does not exist a puts it into mailqueue!!! It won´t just do it until a third party patch is applied. OMG. You really think that this is a sane software design? I don´t. It´s a hodgepodge mess.  :Mad: 

----------

## cselkirk

 *j-m wrote:*   

> Plain vanilla qmail does not contain any of those patches.

 

If it contained these patches (or rather incorporated them) then there would be no need for the ebuild to patch, thats what patching is dude. I never claimed otherwise, I simply pointed out that this is not such an alien procedure. You had stated that without "loads of third-party patches [qmail] is missing the basic functionality of modern MTA", and I pointed out that this is not something specific to qmail, many many other ebuilds are also patched during install (in fact the great majority of them.)

 *j-m wrote:*   

> Please look at the ebuild and the obnoxious number of patches it downloads and applies for you. You would have to do all the work yourself, if you downloaded vanilla qmail from its (largely unmaintained) homepage.

 

Thats why I prefer to use a packaging system. Besides, this is not something specific to qmail, patching is prolific within the *nix world, and again the great majority of packages on a gentoo system are patched. And if you think that qmail is excessive ITR take a look at glibc or gcc.

 *j-m wrote:*   

> Without those patches, the package is basically unuseable. Think of this like if you downloaded vanilla kernel and would have to patch it with ext2/ext3. Now if you could look at postfix ebuild and compare. This is really funny.

 

I am not going to get into a postfix versus qmail debate with you, however much you might want it.

 *j-m wrote:*   

> It´s a hodgepodge mess.

 

Again, your opinion.

----------

## j-m

OK, ending this debate. Software should be useable as-is when downloaded from vendor homepages - qmail is not. The current "design" is simply insane. It´s like: OK, I need this, others have had this for years. Oh sure, grab it from my homepage. And what about that feature, it really should be in there. Wait, John Doe has something like that on his web on Geocities. Try grabbing that... 

Necessary patches should make it to mainstream releases of the software or the maintainers should come up with better ones. Leaving the software intact and relying on those patches you can Google for somewhere is crazy do-it-yourself-we-authors-are-simply-lazy-to-maintain-and-develop-this-package approach. All right, if so, declare clear and loud that it as abandonware and R.I.P. 

P.S. And please don´t compare this with glibc or gcc, that is ridiculous, pure demagogy. How on earth can you compare such complex packages with MTA?

----------

## ElForesto

I was having the same problem as the original post, and I solved it the first time by adding -ipv6 to my USE flags. It just happened again a few moments ago, and I resolved it by copying my tcp.smtp.cdb file to /etc/tcprules.d instead of leaving it in /etc. I felt like the rug had been pulled out from underneath me when I found that. What's especially odd is that it stopped functioning even though I hadn't installed any new packages between the time it was working and the time it stopped working. Weird.

----------

