Scott Sharkey wrote:
Hi Brian,
I'm editing this to make it a bit shorter.
Brian Evans - Postfix List wrote:
Scott Sharkey wrote:
Brian Evans - Postfix List wrote:
Scott Sharkey wrote:
We need your 'postconf -n' to give more hints about a correct setup.
(with virtual_ maps explained too)
see below:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
Note: in a virtual setting, these are never referenced (for domains in
Actually, these are used for the lists.xxx.com domains, which are
mailman-domains, that I am now putting through local. No effect on the
dovecot or virtual domains though, I agree. And alias_maps now has
hash:/var/lib/mailman/data/aliases as well. I was hoping to avoid
that using the python-to-mailman.py script, but the flaw in
that plan is that you still have to have a map somewhere with
the valid addresses, so it seems pointless. I've gone back to
marking these as local domains.
this is ok. I personally use virtual for mailman but I do have "helper"
local domains (mostly localhost).
local_recipient_maps = $virtual_mailbox_maps, $virtual_alias_maps,
$alias_maps, hash:/etc/postfix/relay_recipient_map
dropped the relay_recipient map, but questions remain (see below)
no, drop evertything but $alias_maps. don't mix domain classes.
local_recipient_maps is for users in mydestination.
besides, $virtual_alias_maps is never needed in any recipient map,
because it is always used.
local_transport = dovecot
put this back to local for the list domains (which are the only local
mail accounts).
you'll have to read about domain classes
http://www.postfix.org/ADDRESS_CLASS_README.html
once you understand this, you'll have no problem playing the games you
like.
mailbox_size_limit = 0
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = $transport_maps
This does not look right to me. Do NOT mix virtual and mydestination.
This should list mail domains that are local to the machine.
If you do not need it, use the default. This will pick up things like
cron jobs and pass it to dovecot.
You are correct. I've redefined this to 'localhost', $myhostname, and a
map of the "list" domains. (select domain where domain = %s and
transport = 'local')
myhostname = mail.linuxunlimited.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
relay_domains = proxy:mysql:/etc/postfix/mysql_relay_domain_map.cf
relay_domains with no relay_recipient_maps parameter? This is not the
best way to handle this.
What is? -- I have no way to determine the actual users on the relay
domain... I'm not actually using any relay domains, now that I've
moved the mailman lists to local... But theoretically, I could
be a backup MX for someone. How do I create/manage a list of
THEIR recipients... I was under the impression that I would NOT,
just accept all and deliver to them, but I can see the flaw in
that plan... Not planning on using this, at least not right now,
so I may just turn it off (came with postfixadmin setup)
take a look at
http://www.postfix.org/BACKSCATTER_README.html
In the past, it was ok to queue a message and then bounce it because the
recipient does not exist. This is no more acceptable (because there is
no way to know whether the sender is not forged).
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unauth_pipelining,
check_policy_service inet:127.0.0.1:10031,
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_non_fqdn_hostname,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client sbl.spamhaus.org,
permit
dsbl is dead and gone, you con combine the other lists into 1..
zen.spamhaus.org incorporates cbl.abuseat.org, njabl.org, sbl and also
their pbl. (recommended and saves DNS query resources)
njabl is not included in zen. only njabl proxy list is part of xbl
(which is included in zen).
yeah, that was copied from an old mail server, and I haven't gotten
around to updating this part yet... one step at a time!!! <grin>
Fixed now. I had read about zen, but had not dug into the details yet.
transport_maps = proxy:mysql:/etc/postfix/mysql_transport_map.cf
Is this trip really necessary?
Not sure... I have dovecot, local, vacation, and potentially relay
transports, loaded via postfixadmin/mysql. The dovecot domains are
virtual, the mail list domains local, vacation and relay are
special cases. How do I set the "default" transport to dovecot?
you should avoid using sql for transport_maps (as well as for domains
lists). if you really want to manage transports via a UI that uses
mysql, you can still dump the db to a cdb (or hash if you don't want to
install cdb).
virtual_gid_maps = static:2000
virtual_mailbox_base = /home/virtual
virtual_uid_maps = static:2000
These options will be ignored after dovecot takes over.
Yeah, right. But I started with a different virtual setup, so these
are just leftovers. I can probably kill them.
you don't need to. while I use dovecot, I have a working postfix config
(so that disabling dovecot doesn't result in a disaster).
All of the virtual_ maps point to mysql tables, but the relevant part
(I think) is that the transport entry is "virtual" for most of them
(some are set to mailman for mailing list domains, and I think maybe
one is set to virtual for the autoreply function).
No virtual_mailbox_domains?
Good catch. I had actually defined the .cf file to look them up, but
forgot to set this. Fixed now. And actually, the transports are now
"dovecot" - that was the initial error that prompted my posting...
since dovecot is our default transport, you don't need to have entries
returing dovecot, except when you need to override a different result.
It seems to me that the documentation was not clear and you tried to
invent your own ways or followed a poor HOWTO.
WORSE! I'm trying to follow about 10 howto's, since the doc's are
nowhere near clear enough (lots of theory, very little practical
application, it seems!)
The best docs are on www.postfix.org (and they are also available as man
pages). Most of the howtos out there are of bad quality, if not worst.
Besides the postfix site, the Book of Postfix is a very good reading.
If you find that something in the docs isn't clear or not detailed
enough, it would be good to say so (please give enough details). this
way the docs can be improved. of course, if you are good at writing, ...
And no one howto is doing exactly what I want.
So, I'm trying to understand, and also to marry up various pieces from
different people to get what I want, which is, admittedly, kinda complex.
I'm trying to use postfix, dovecot with sieve, managesieve, quota,
postfixadmin to manage the domains, mailman for lists, dspam, clamav and
the dovecot-antispam plugin, roundcube webmail.
don't marry them. make them work together. just for info, I use postfix,
dovecot (and courier!), maildrop, sieve, mailman, amavisd-new (with
clamav and SA), roundcube, in a "virtual" setup with mysql (some tables
are dumped). I've tried dspam some time ago but as I don't have
performance issues, I prefer SA (mostly because users don't train
anything. I actually rely on postfix access more than on SA).
I think I've got it all
working except dspam/clamav/dovecot plugin. I'm working one step at
a time, and trying to understand it all when I'm done. Been working on
it slowly for about 2 months now.
I'm familiar (though not expert) with most of these tools, but getting
them all playing nice together is a bitch!
Any other suggestions/comments would be most appreciated. Right now,
it's a test server that I can do what I want with - no live domains yet.
But I gotta get it going pretty soon now...
for clamav, you can use clamsmtp or amavisd-new. if perl is ok for your
setup, amavisd-new has many other features (amavsid-new is a perl
daemon, so there is no fork/exec per message).
