Il 06/03/2012 20:37, Eric Shubert ha scritto:
On 03/06/2012 10:44 AM, Tonix (Antonio Nati) wrote:
Il 06/03/2012 18:29, Eric Shubert ha scritto:
Would you suggest we be using the
#define CHKUSER_ENABLE_USERS_EXTENSIONS
by default? It seems to me we should, as the "-anything" extension is
a standard part of qmail (unless I'm mistaken). If we should, can it
be enabled with an environment variable, or is it strictly a #define
setting?
Extensions are used for TMDA (I don't know if it is still used), ezml
maling lists, mailman lists, user extensions.
chkuser has different options:
- user extensions
- mailman lists
- ezmlm lists
you do not need user extension if you are in normal situations (I have
only ezmlm lists enabled).
You need the user extension if you use TMDA or in cases in which you
want to receive extensions.
In this case, chkuser checks for recipient existance, and if fails tries
again shifting towards left (using '-' as token to search).
With ezmlm and mailman lists enabled, it checks if recipient is
associated to a ezmlm/mailman list, and in such a case it accepts
extensions for that recipient.
Thanks for the great explanation Tonino. That clears things up for me.
I still have a couple questions though.
What's the down side of enabling user extensions? qmail provides this
capability by default. It seems to me that QMT should as well. No?
This is up to you.
With extensions DJB probably wanted to extend recipients possibilities,
giving different address (i.e. eric, eric-test, eric-lab, eric-sales)
and handle ezmlm extensions (ezmlm works heavily with extensions).
In my situation, extensions are not needed, and I prefer to keep a
'standard' situation (only real account/aliases/lists work).
Other situations may be different.
Regarding mailman extensions, I have a QMT host running mailman with
chkuser's mailman extensions disabled. This domain also has a catchall
account. If I were to set catchall to bounce, I would also need to
enable mailman list extensions for mailman to continue to work. Correct?
Yes, correct.
Catchall does not benefit of chkuser capabilities, while user-extensions
or mailman features do.
If I understand correctly, applying this setting would fix Russ's
problem. Or I suppose he could set a catchall account. Correct?
catchall is to be avoided if possible, as it accept always any recipient
and does not give any advantage to traffic/workload.
It should be used when you setup a new domain (coming from another ISP)
on which you don't know which accounts exist. So, for some time, you
accept all recipients and create accounts as you understand which
accounts are needed. At end of all you kill the catchall feauture and
enable 'bouncing'.
While I understand your scenario for when it should be used, I
disagree that it should be avoided if possible. That may be the case
for a service provider which has hundreds if not thousands of
accounts, but not in all cases.
I agree, it depends on situations. In my case, when a user need an
extension, he adds an alias.
I suggest only expert people should use catchall, as no error message is
sent back, so senders are not notified about not existing recipients.
In situations where a domain is more private, a catchall account
allows a large degree of flexibility regarding how email addresses are
used. For instance, when I shop at SomeStore and they want my email
address, I give them [email protected], and the mail is
delivered. I then typically set up a forward for that address to a
real account once I receive an email to that address in my catchall
account. If I happen to start receiving spam to that address, I can
discontinue use of that address by adding to the badmailto file, or if
I'm in a bad mood, forward the spam back to the store who I gave the
address to. :) BL, the catchall account saves me from having to
remember to create a forward for every email address I happen to hand
out. As is the case so many time, one size does not fit all. ;)
It is true, but in this situation you are not really using chkuser, as
any recipient is accepted for your domain.
You (system manager) may change badmailfrom, but normal users or
qmailadmin administrators cannot.
As conseguence, all spam messages become real traffic instead of being
stopped at SMTP level.
I didn't mean to suggest using a catchall account was a good solution
to this problem, only a quick and dirty workaround.
I suggest to create aliases if cases are a few, otherwise enable user
extensions.
I'm not seeing much of a down side to enabling all 3 of these settings
by default. What is the down side in your view? I'm inclined to change
the QMT default configuration to allow all 3 by default, which brings
QMT in line with qmail's default behavior. However I certainly
wouldn't do this without consulting you, as well as anyone else who'd
like to chime in on this.
It is pretty normal to enable all three. This will let you avoid
catchall accounts (unless there are other reasons to have catchall).
Also, I'm under the impression that there is no environment variable
which can control this functionality, and that changes can only be
made by rebuilding. Is this correct?
Yes, it is correct. It is a compilation switch.
I though it could be a system behaviour. Making it domain based would
mean to add other configuration files, which I'd love to avoid.
Ciao!
Tonino
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it [email protected]
------------------------------------------------------------
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
