Using https://wiki.alpinelinux.org/wiki/Setting_up_postfix_with_virtual_domains <https://wiki.alpinelinux.org/wiki/Setting_up_postfix_with_virtual_domains> as a bit of a tutorial, I got one of my domains switched over to being a virtual domain and was able to send and receive email for a user on the domain I transferred.
Do I have to have the users setup now both in my postgresql database and also in the /etc/postfix/virtual_mailbox_maps file? That would seem redundant. Is there a way to use virtual domains and have all the user info stored in my postgresql database? Thanks! Austin Witmer > On Jun 18, 2022, at 7:42 PM, Viktor Dukhovni <postfix-us...@dukhovni.org> > wrote: > > On Sat, Jun 18, 2022 at 04:26:09PM -0600, Austin Witmer wrote: > >>>> mydestination = $myhostname, sunlightmail.net, mail, localhost.localdomain, >>>> localhost, encryptedmail.info, animaswoodcraft.com, animascreations.com, >>>> appalachianmeats.com, mcmennonitechurch.org, thefabshop.net, >>>> postal22.com, >>>> rollingpastures.net >> >> I am using virtual users in a postgresql database, so how do I >> properly setup virtual domains instead of listing them after >> mydestination? >> >> When I added "virtual_mailbox_domains = example.com >> <http://example.com/>” instead of listing the domain after >> mydestination, incoming emails to users in that domain were rejected. >> How can I use virtual_mailbox_domains in conjunction with the users in >> my postgre database? > > You'll need to read BASIC_CONFIGURATION_README, > STANDARD_CONFIGURATION_README and VIRTUAL_README. And likely the > Postfix book by Ralf and Patrick. > > The short, but insufficient, version is that for > "virtual_mailbox_domains" users also need to be listed in > "virtual_mailbox_maps", even if the RHS is ignored because delivery is > via some delivery agent other the virtual(8) in Postfix. > > This message is too short to be a virtual mailbox hosting tutorial for > Postfix + Dovecot. Though a comparatively simple setup is possible. > >>>> sender_bcc_maps = hash:/etc/postfix/regexp_sender_bcc >>>> smtp_destination_concurrency_failed_cohort_limit = 10 >>>> smtp_destination_concurrency_limit = 1 >>>> smtp_destination_rate_delay = 1s >> >> A friend of mine advised me to use the final three lines to avoid >> problems when sending to yahoo accounts. > > If this is just "@yahoo.com" users (I guess there are still some of > these left), then a dedicated transport for yahoo might be better. > But if you send so little mail that concurrency is rare, the global > setting may be sufficient, though needlessly slow at times. > >>> Do you really need this as a global default? >>> >>>> smtp_tls_cert_file = >>>> /etc/letsencrypt/live/mail.sunlightmail.net/fullchain.pem >>>> smtp_tls_key_file = /etc/letsencrypt/live/mail.sunlightmail.net/privkey.pem >>> >>> Why do you need a TLS client certificate issued by Let's Encrypt? >>> What receiving system expects this? >> >> I have no idea! I put this in when following some tutorial. > > Take these out. > >>>> smtps inet n - - - - smtpd >>>> -o syslog_name=postfix/smtps >>>> -o smtpd_tls_wrappermode=yes >>>> -o smtpd_sasl_auth_enable=yes >>>> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >>>> -o milter_macro_daemon_name=ORIGINATING >>>> -o content_filter=gpgit-pipe >>>> -o cleanup_service_name=subcleanup >>> >>> Where is the override of "recipient restrictions" (and relay >>> restrictions). This should be identical to the submission service >>> modulo "wrapper mode". >> >> Are you saying I should add the following line to the submission service? >> >> -o >> smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject > > And then set all the other lists empty. Or make it > "smtpd_relay_restrictions" and set all the others empty. The stock > master.cf file that ships with Postfix source has: > > submission inet n - n - - smtpd > -o syslog_name=postfix/submission > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o smtpd_tls_auth_only=yes > -o smtpd_reject_unlisted_recipient=no > # Instead of specifying complex smtpd_<xxx>_restrictions here, > # specify "smtpd_<xxx>_restrictions=$mua_<xxx>_restrictions" > # here, and specify mua_<xxx>_restrictions in main.cf (where > # "<xxx>" is "client", "helo", "sender", "relay", or "recipient"). > -o smtpd_client_restrictions= > -o smtpd_helo_restrictions= > -o smtpd_sender_restrictions= > -o smtpd_relay_restrictions= > -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject > -o milter_macro_daemon_name=ORIGINATING > > It does not matter which of "recipient" or "relay" restrictions you > set for submission, just explicit set all the others empty, this should > even include "smtpd_data_restrictions" and "smtpd_end_of_data_restrictions". > The goal is to make submission (outbound email from your users) insensitive > to ad-hoc anti-spam rules applied to inbound main in main.cf. > > Once you have configured "submission" correction, apply exactly the same > settings to the port 465 TLS-wrapped service, with just the addition of: > > -o smtpd_tls_wrappermode=yes > > and a change of the syslog_name: > > -o syslog_name=postfix/submissions > > -- > Viktor.
