Noel, Thanks again so much for all the great advice. I have since worked in your changes (I have omitted the relay_recipients_maps for now, as I have to device a scheme to synchronize my alias table between various domains).
Here is my currenet postconf -n, any other pointers would be great. I will update the article I wrote next week to reflect these changes once I'm sure it all works as expected. Thanks again everybody else that helped too! biff = no broken_sasl_auth_clients = no command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib64/postfix data_directory = /var/lib/postfix debug_peer_level = 1 disable_vrfy_command = yes home_mailbox = .maildir/ html_directory = /usr/share/doc/postfix-2.6.5/html mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 20480000 mydomain = example.com myhostname = foo.example.com mynetworks = 127.0.0.0/8 mynetworks_style = host newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.5/readme recipient_delimiter = + relay_domains = pgsql:/etc/postfix/pgsql/pgsql-relay-domains-maps.cf #relay_recipient_maps = pgsql:/etc/postfix/pgsql/pgsql-relay-recipient_maps.cf sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_banner = $myhostname ESMTP NO UCE smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client bl.spamcop.net smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = reject_invalid_hostname smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_policy_service inet:127.0.0.1:2525, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = no smtpd_sasl_local_domain = smtpd_sasl_security_options = noplaintext, noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_tls_CAfile = /etc/ssl/certs/cacert.org.pem smtpd_tls_auth_only = no smtpd_tls_cert_file = /etc/postfix/ssl/smtp.example.com_server.pem smtpd_tls_key_file = /etc/postfix/ssl/smtp.example.com_privatekey.pem smtpd_tls_loglevel = 0 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes soft_bounce = no tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550 virtual_alias_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-alias-maps.cf virtual_gid_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-gid-maps.cf virtual_mailbox_base = /var/vmail virtual_mailbox_domains = pgsql:/etc/postfix/pgsql/pgsql-virtual-mailbox-domains.cf virtual_mailbox_limit_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-mailbox-limit-maps.cf virtual_mailbox_limit_override = yes virtual_mailbox_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-mailbox-maps.cf virtual_maildir_extended = yes virtual_maildir_limit_message = "Sorry, the recipients mailbox is currently full. Please try again later." virtual_overquota_bounce = no virtual_trash_count = no virtual_trash_name = ".Trash" virtual_uid_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-uid-maps.cf Noel Jones wrote: > On 4/23/2010 6:10 AM, oliver wrote: >> On Thu, 22 Apr 2010 19:06:59 -0500, Noel Jones<njo...@megan.vbhcs.org> >> wrote: >>> On 4/22/2010 6:17 PM, Oliver Schinagl wrote: >>>> Here's what I have in my postconf now: >>>> mydomain = example.com >>>> myhostname = foo.example.com >>>> mynetworks_style = host >>> >>> OK, you're not defining mynetworks, permit_mynetworks should >>> only allow your host's IPs. That's fine. >> >> I simply assumed, it's probably best to allow no one but localhost to >> mail >> unauthorized. > > If that's your intention, it's probably better to explicitly state: > mynetworks = 127.0.0.1 > > Most people also list their local network here, but that's not a > requirement. > >> >>> >>>> relay_domains = pgsql:/etc/postfix/pgsql/pgsql-relay-domains-maps.cf >>> >>> Using relay_domains without relay_recipient_maps is strongly >>> discouraged. Your queue will get clogged with undeliverable >>> mail and eventually you'll be blacklisted as a backscatter source. >>> >> I went looking up relay_recipient_maps and from what I gather, all the >> users that are in my user table on the other end would have to be here as >> well? This basically means my database backend would/could be >> identical/synchronized then with just the backupmx flag on the domain >> reversed? > > Yes, the recipient list needs to be shared. > > But really, the idea of third-party backup MX is long dead. Better to > not offer the service to others nor use it yourself. > Without very close cooperation between you and the other party, one of > you is going to be a backscatter source. > >> I can understand this working in my specific setup, where I admin >> both servers, but what if I would be a backupmx for a domain where I >> do not >> know the users from? E.g. My friend runs his own mailserver, and he likes >> me to be his backupmx; I'm perfectly fine with that, but I rather not >> have >> to keep his userbase in sync with my userbase, or did I completly >> missunderstand? I saw specifying @domain is bad, what about a catchall? >> *...@backupmxdomain.com or are those identical in that sense? Or am I >> completely missing the point on this one. > > If you accept mail for some other system, and then they refuse it, it > makes you a backscatter source. > http://en.wikipedia.org/wiki/Backscatter_%28e-mail%29 > http://www.postfix.org/BACKSCATTER_README.html#wtf > This is about when you're a victim of backscatter, but you really don't > want to be the source -- you will get blacklisted. > > If the remote system will never reject or bounce back mail you send > them, I suppose you don't need a recipient list. But there is at least > some evidence that systems that accept catch-all addresses are spam > magnets. > > If the receiving system rejects unknown recipients during SMTP, you can > let postfix build a list of known recipients for you. > http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient > but this doesn't help if the remote system rejects or bounces back mail > it thinks is spam. > > >> >> Also, re-reading it again, postfix will look up the string, but >> doesn't use >> the result, e.g. something like select * from backupmxtable where >> domain=%u; would result in a positive hit and all mailboxes from that >> domain, but that would also make me become a source of backscatter mail >> (what is that anyway)? I would assume that my postfix server would accept >> the mail, then forward it to the other host and deliver it there. > > The problems start when the other host either rejects mail, or bounces > it back to you. You must not allow that as a normal occurrence. An > occasional bounce is probably unavoidable, but you should do whatever > you can to avoid them. > > >> >> >>>> smtpd_banner = $myhostname NO UCE ESMTP >>> >>> That must be >>> smtpd_banner = $myhostname ESTMP comments... >>> >> I assume the order matters here? I figured the NO UCE bit would be >> totally >> useless and totally ignored anyway, but hey, it would be there for all to >> see. > > ESTMP must be the second field, you can put whatever else after that. I > suppose the notice might do some good if you decide to sue a spammer > someday. > > >> >>>> smtpd_client_restrictions = permit_mynetworks, >>>> permit_sasl_authenticated, permit_mx_backup, reject_rbl_client >>>> zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client >>>> bl.spamcop.net >>> >>> "permit_mx_backup" is evil and disabling your RBL lookups. >>> >> Ah! now we're onto something. But why? is it filling in more then my >> backup >> mx domains here? I assume setting up relay_domains (properly) as above >> allows mail from my backups to arrive normally without consulting >> smtpd_client_restrictions? > > permit_mx_backup also implies permit_auth_destination. No checks make > sense after that other than "reject" -- the only mail that will still be > processed at this point are unauth relay attempts. > http://www.postfix.org/postconf.5.html#permit_mx_backup > > But really, the idea of a third-party backup MX is long dead, killed by > spammers. Better to not offer the service to others nor use it yourself. > > >>>> smtpd_recipient_restrictions = permit_mynetworks, >>>> permit_sasl_authenticated, permit_mx_backup, check_policy_service >>>> inet:127.0.0.1:2525, reject_unauth_destination >>> >>> Remove permit_mx_backup, it's disabling all your other checks. >>> >> As above, I don't understand how here either :) > > See above. > > >>>> smtpd_sasl_security_options = noanonymous >>> >>> Caution, this setting allows plain text passwords to be sent >>> unencrypted. Safer (but harder for testing and maybe less >>> compatible): >>> smtpd_sasl_security_options = noplaintext, noanonymous >>> smtpd_sasl_tls_security_options = noanonymous >>> >>> >> Would base64 encoded usernames/passwords count? I'm not sure what >> roundcube >> does in that regard, then again, it doesn't matter as it is running >> locally >> anyway; and it has an option to properly login when sending messages >> remotly I belive. > > Plain-text does not always mean human-readable. Base64 text is > trivially decoded and is considered plain text. > > > -- Noel Jones
