Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Qmail: users

How to use wildcard subdomains with Qmail? Please help!

 

 

Qmail users RSS feed   Index | Next | Previous | View Threaded


olaf.spaarmann at googlemail

May 13, 2009, 1:12 PM

Post #1 of 4 (1619 views)
Permalink
How to use wildcard subdomains with Qmail? Please help!

Hi,

I'm having the folling scenario: I want people to be able to send
mails to support [at] anything . All mails should go to one
mailbox (support). anything.domain.com should be really any valid
subdomain, without having to add them manually. So I'm looking for
support@*.domain.com

At the beginning I got this error when trying to send mails:

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

So I added

.domain.com

to /var/qmail/control/rcpthosts

After that I got:

"Sorry. Although I'm listed as a best-preference MX or A for that host,
it isn't in my control/locals file, so I don't treat it as local.
(#5.4.6)"

So I figured I had to add something in the /var/qmail/control/locals
file. I tried a lot of different things but eventually realised that
here wildcards are not allowed.

I'm not sure what to do now. I don't want to disable the locals file
and turn the server into an open rely. But I definitly need wildcard
subdomains. It is also no real option to add the needed subdomains to
the locals file. They will be many and change often.

I'm not an administrator nor a qmail expert. I'm just a Rails
developer trying to set up a testing enviroment. So please be patient.

Thank you very much for your help!

Olaf


kyle-qmail at memoryhole

May 13, 2009, 3:09 PM

Post #2 of 4 (1520 views)
Permalink
Re: How to use wildcard subdomains with Qmail? Please help! [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wednesday, May 13 at 10:12 PM, quoth Olaf Spaarmann:
> I'm having the folling scenario: I want people to be able to send
> mails to support [at] anything . All mails should go to one
> mailbox (support).

Okay.

> anything.domain.com should be really any valid subdomain, without
> having to add them manually.

How do you define "valid"?

> So I added
>
> .domain.com
>
> to /var/qmail/control/rcpthosts

Yup, that's step 1.

> After that I got:
>
> "Sorry. Although I'm listed as a best-preference MX or A for that host,
> it isn't in my control/locals file, so I don't treat it as local.
> (#5.4.6)"

<rant>
You know, administration via error message is usually a bad plan. I
don't mean this in a mean way, but you're relying on software error
messages to give you full and complete information about what your
options are. They almost never do. I strongly suggest reading some of
the documentation; its very good, and you'll get a much better idea of
what you're doing and why.

Writing to a mailing list and saying, essentially, "I'm trying to do
something unusual, and even though I know someone went to the time to
write the documentation so that people like me could figure this stuff
out, I can't be bothered to read it. Can you solve my problem for me?
If your response sounds too much like documentation, I may not read it
either, and I'll probably get offended instead, but please try to
satisfy me anyway." doesn't usually earn you too many friends.

I'm gonna try to help you, but don't get offended if I seem brusque.
</rant>

> So I figured I had to add something in the /var/qmail/control/locals
> file. I tried a lot of different things but eventually realised that
> here wildcards are not allowed.

Correct, wildcards aren't allowed in locals.

Is that what you want? You want support@*.example.com to be considered
a LOCAL mailbox? What about the other addresses, like
foo@*.example.com?

The first option that occurs to me is to use control/virtualdomains.
You can use wildcards there, such as:

.example.com:foo

That will make qmail accept email addressed to *@*.example.com, and
will treat it as if it were addressed to foo-*@*.example.com. It would
be relatively easy to then put a file named .qmail-support in foo's
home directory to handle all support@ emails. And then you can create
a file named .qmail-default to handle the non-support messages in
whatever way you see fit.

Is that about what you're looking for?

~Kyle
- --
If Mr. Einstein doesn't like the natural laws of the universe, let him
go back to where he came from.
-- Robert Benchley (1889-1945)
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKC0T/AAoJECuveozR/AWeewgP/0JIVVYY494zZZb/soFiJOed
Fb7gZcYr9Z9tZZ+l0wUff3xXotkJl+09x1V+KLJFLL6W21Jlj9n0NTX+UGcHDdsK
3hWe9AylFBfil+Qr9vgdGDOVyxQ7oOG9/dSblN/dQeleJqL3OBqD64hNRSXSsqhD
oMrCIO13l9iDR1tSOIzFRSqg9MGBsDwOwqgolVGp1uTrlRst38uf4cImxSQ3UuAY
GxJc/K5gqHzHsYuVMVdkbinxoqCSM4G0C8DcRi3TbJbm4mp5UKbCETV80t5QVIS4
w0r68hGyhWuLYy4LPO+Sz4gxh1rhiONWgTT4zNxED52twmf453QRzCw53emL64S0
jVBhdCSSSwuGSqo9iV1TFR8Pvmba7JNlwSaC3hz5vqkth3IjUtkR3IPqFS1DOnN0
zo5GX25gkZr/KLx7IUSb3mr4sRN7W4A08+Y35v+3zrJDwBG3xtS59lj5l1iU8PS2
V0aALnp9DHva/DC8AyFk83L+McCUFbDr3G1axCa+w77+aMqcblLxkBUQydRo7vsP
lc9nW2BjP3j01ZyDOoSrk78YpIwpE+JYjfgdME3H4etcRwrAbQNNgs8l9LptAGoS
ijfUfZ4AtGHtBwA1stdqEOOWOwSSqX/cvGjpE8tBhspJsPWqFHq51NVU/hXTQBBc
7pwPdstWkrDt8Q0Au+On
=Yw57
-----END PGP SIGNATURE-----


olaf.spaarmann at googlemail

May 13, 2009, 11:37 PM

Post #3 of 4 (1515 views)
Permalink
Re: How to use wildcard subdomains with Qmail? Please help! [In reply to]

Thanks for your help!

I understand very well that one should read the documentation first
and I probably feel the same when people ask stupid questions in a
domain I know a lot about. But I read a lot and still didn't find a
solution. I know too little about server administration and even
though I might understand some things, I'm still in the dark. So
please excuse me for asking here.

I already tried to add something like

.example.com:foo

to control/virtualdomains. After that qmail accepted the message first
but didn't know where to put it. So it didn't work.

But thanks to your tip I will look into the documentation again to
understand how to make qmail accept these messages (with a .qmail-
support file).

Another question: Do you think it is generally a bad idea to allow all
subdomains? Because theoretically I also could write a script that
adds the desired domains to control/locals. It's just more of a hassle
for a testing enviroment.

Best,
Olaf



Am 14.05.2009 um 00:09 schrieb Kyle Wheeler:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Wednesday, May 13 at 10:12 PM, quoth Olaf Spaarmann:
>> I'm having the folling scenario: I want people to be able to send
>> mails to support [at] anything . All mails should go to one
>> mailbox (support).
>
> Okay.
>
>> anything.domain.com should be really any valid subdomain, without
>> having to add them manually.
>
> How do you define "valid"?
>
>> So I added
>>
>> .domain.com
>>
>> to /var/qmail/control/rcpthosts
>
> Yup, that's step 1.
>
>> After that I got:
>>
>> "Sorry. Although I'm listed as a best-preference MX or A for that
>> host,
>> it isn't in my control/locals file, so I don't treat it as local.
>> (#5.4.6)"
>
> <rant>
> You know, administration via error message is usually a bad plan. I
> don't mean this in a mean way, but you're relying on software error
> messages to give you full and complete information about what your
> options are. They almost never do. I strongly suggest reading some of
> the documentation; its very good, and you'll get a much better idea of
> what you're doing and why.
>
> Writing to a mailing list and saying, essentially, "I'm trying to do
> something unusual, and even though I know someone went to the time to
> write the documentation so that people like me could figure this stuff
> out, I can't be bothered to read it. Can you solve my problem for me?
> If your response sounds too much like documentation, I may not read it
> either, and I'll probably get offended instead, but please try to
> satisfy me anyway." doesn't usually earn you too many friends.
>
> I'm gonna try to help you, but don't get offended if I seem brusque.
> </rant>
>
>> So I figured I had to add something in the /var/qmail/control/locals
>> file. I tried a lot of different things but eventually realised that
>> here wildcards are not allowed.
>
> Correct, wildcards aren't allowed in locals.
>
> Is that what you want? You want support@*.example.com to be considered
> a LOCAL mailbox? What about the other addresses, like
> foo@*.example.com?
>
> The first option that occurs to me is to use control/virtualdomains.
> You can use wildcards there, such as:
>
> .example.com:foo
>
> That will make qmail accept email addressed to *@*.example.com, and
> will treat it as if it were addressed to foo-*@*.example.com. It would
> be relatively easy to then put a file named .qmail-support in foo's
> home directory to handle all support@ emails. And then you can create
> a file named .qmail-default to handle the non-support messages in
> whatever way you see fit.
>
> Is that about what you're looking for?
>
> ~Kyle
> - --
> If Mr. Einstein doesn't like the natural laws of the universe, let him
> go back to where he came from.
> -- Robert Benchley (1889-1945)
> -----BEGIN PGP SIGNATURE-----
> Comment: Thank you for using encryption!
>
> iQIcBAEBCAAGBQJKC0T/AAoJECuveozR/AWeewgP/0JIVVYY494zZZb/soFiJOed
> Fb7gZcYr9Z9tZZ+l0wUff3xXotkJl+09x1V+KLJFLL6W21Jlj9n0NTX+UGcHDdsK
> 3hWe9AylFBfil+Qr9vgdGDOVyxQ7oOG9/dSblN/dQeleJqL3OBqD64hNRSXSsqhD
> oMrCIO13l9iDR1tSOIzFRSqg9MGBsDwOwqgolVGp1uTrlRst38uf4cImxSQ3UuAY
> GxJc/K5gqHzHsYuVMVdkbinxoqCSM4G0C8DcRi3TbJbm4mp5UKbCETV80t5QVIS4
> w0r68hGyhWuLYy4LPO+Sz4gxh1rhiONWgTT4zNxED52twmf453QRzCw53emL64S0
> jVBhdCSSSwuGSqo9iV1TFR8Pvmba7JNlwSaC3hz5vqkth3IjUtkR3IPqFS1DOnN0
> zo5GX25gkZr/KLx7IUSb3mr4sRN7W4A08+Y35v+3zrJDwBG3xtS59lj5l1iU8PS2
> V0aALnp9DHva/DC8AyFk83L+McCUFbDr3G1axCa+w77+aMqcblLxkBUQydRo7vsP
> lc9nW2BjP3j01ZyDOoSrk78YpIwpE+JYjfgdME3H4etcRwrAbQNNgs8l9LptAGoS
> ijfUfZ4AtGHtBwA1stdqEOOWOwSSqX/cvGjpE8tBhspJsPWqFHq51NVU/hXTQBBc
> 7pwPdstWkrDt8Q0Au+On
> =Yw57
> -----END PGP SIGNATURE-----


kyle-qmail at memoryhole

May 14, 2009, 12:23 PM

Post #4 of 4 (1523 views)
Permalink
Re: How to use wildcard subdomains with Qmail? Please help! [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thursday, May 14 at 08:37 AM, quoth Olaf Spaarmann:
> I understand very well that one should read the documentation first
> and I probably feel the same when people ask stupid questions in a
> domain I know a lot about. But I read a lot and still didn't find a
> solution.

That's very fair, and I can respect that. The only reason I jumped on
the "read the documentation" thing up front was because it *appeared*
that you had not read the documentation, and were instead using the
error messages as a kind of on-line step-by-step configuration howto.

> I already tried to add something like
>
> .example.com:foo
>
> to control/virtualdomains. After that qmail accepted the message first
> but didn't know where to put it. So it didn't work.

Ahh, you didn't mention that. You were close!

In order to understand how the virtualdomains system works, you have
to understand qmail's address extension scheme. Here's the basics:

Let's assume a very basic LWQ setup where the machine has only one
domain (example.com) and all the users are system users (e.g. home
directories in /home/$USERNAME). If I have a user (say, "me") on this
system, it's clear that mail addressed to me [at] example will be
delivered according to /var/qmail/control/defaultdelivery unless the
user does more specific setup (e.g. I create a ~/.qmail file). What is
not always clear is that mail addressed to me-foo [at] example is also
considered valid. I (the user) can tell qmail to deliver that mail
differently by creating a ~/.qmail-foo file. In this case, "foo" is
called the "extension". I can also use wildcards, by using the
"special" extension, "default". Thus, a ~/.qmail-default file
specifies how to handle the delivery of messages addressed to
me-*@example.com. With me so far?

Now, virtualdomains work by prepending things to the local part of the
email address. For example, if I added example2.com to rcpthosts and
then added example2.com:bar to virtualdomains, qmail will accept all
mail addressed to example2.com email addresses. When it does so, it
will prepend the address with "bar-", so mail addressed to
whatever [at] example2 is treated like it was addressed to
bar-whatever [at] example2 See how that fits nicely with the extension
scheme? So, if I specify example2.com:me in virtualdomains, then the
"me" user is responsible for all example2.com email addresses. For
example, email addressed to foo [at] example2 would be treated as if it
was addressed to me-foo [at] example2, which would be handled by a
~me/.qmail-foo file. Of course, wildcards here work as expected, so it
could also be handled by a ~me/.qmail-default file if the .qmail-foo
file doesn't exist.

Does that make sense?

> Another question: Do you think it is generally a bad idea to allow
> all subdomains?

Nah; I do that a lot. You just have to be aware that qmail doesn't do
any sort of verification of the existence of the subdomain.

~Kyle
- --
Reality is that which, when you stop believing in it, doesn't go away.
-- Philip K. Dick
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKDG+7AAoJECuveozR/AWeobcP/1KJxj2LBCqEJdPJM3iaYjJV
+4oL/bp1wgKZOYGknXFe7ZxiTlqnsj/29en7M/mj7Fgxf5eF4EYOJPH6Ubo9tYbr
9u42y5PkkHo0/QgcEkoqH9pnIvRCfcnQqCpL3F+Mneh3dZOGzfYeoUEdxnSDChuo
YsGN5PWgwNNZLGt1qmd7gFpdlVSv6aS67V2DU5UdXxhYFhc4fFYWW7XLjssK9kQt
vmpMVo4xK0XuiXyZ7rxNm3BVhxJqmOsV/JWYJaUS4xNpb6LiADVtkJ2+VFTlAIO/
KNriK34UX0yp7AcKknkS4/uW7dvFnzVCWANUWEqHRFGyBqFqKy9PejtMquIyGNBF
sKlIF0yWycAv1yXDlnjDtgDsfDKw9QLCdKgW/l9pHtXkliWagbTTqyV6ybTlx2f3
yO/1k66T6I0gC7iyEcJscuRkNmvQ6AGqXMNxFnyIZ9sUWh1L/2q6n3529yqB7JNg
m+oKAs6scSWCAdbeBmveYictaqc313ePWwHhENd196pjjmvO3pvR+SPN3zhFeGqH
crZOXAVcvG/y7tvw9mnK4CBux4TOE0rBzxDH/WfKajVYIcWPKgtFRjYQnux3fqWx
3HxJmjpKegx2n/iu0ZwtcbWXyZFtnojgBR/iTm4zmpxLPgONXXJkKtPUJcjjY3QI
vQpbSycajp6neWwQR1I9
=o5RE
-----END PGP SIGNATURE-----

Qmail users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.