Re: bounce notify class
Dominic Raferd: > ?I am deluged with messages in the postmaster mailbox reporting failed > smtpd transactions for spammers trying to send to non-existent recipients > on our domain?, which postfix quite rightly rejects (i.e. not listed in > virtual_alias_maps). These are smtpd transaction reports not bounces, but > they are sent automatically to $bounce_notice_recipient as part of the > bounce error class. This is 'by design'; Incorrect. By default, Postfix does not send postaster notification for rejected mail. The default setting is: notify_classes = resource, software You have added 'bounce' to that list. It you don't want such email, then don't set notify_classes to send such email. Wietse
Re: bounce notify class
On 12 November 2017 at 10:57, Postmaster wrote: > You should neither ignore your Postfix bounces (called Local/synchronous > bounces) nor generated by other providers (called Remote/ Asynchronous > bounces). Both should be processed correctly and not be retried if its > related to mailbox/user does not exist. It is one of the important factor > that affects your email deliverability and IPs/ Domains reputation. > > Hope it helps. > > Thanks. > > On Wed, Nov 8, 2017 at 3:05 PM, Dominic Raferd > wrote: > >> >> >> On 8 November 2017 at 08:34, Alex JOST wrote: >> >>> Am 07.11.2017 um 14:54 schrieb Dominic Raferd: >>> I want to turn off the the bounce error class to reduce clutter in my postmaster mailbox, but don't want to miss something important. The bounce error class is defined ( http://www.postfix.org/postconf.5.html#notify_classes) as: 'Send the postmaster copies of the headers of bounced mail, and send transcripts of SMTP sessions when Postfix rejects mail.' I understand the second of these (and receive many of them, which I don't want) but not the first (and don't seem to receive any). What are 'copies of the headers of bounced mail' - would this be mail that has been bounced by Postfix (not interesting to me) or mail bounced by an onward mailserver (interesting to me - but maybe this is covered by the 2bounce error class)? >>> No, only bounces of outgoing mails. For us that's mainly bounces because >>> of misspelled e-mail addresses (connection timeout and mailbox unavailable). >> >> >> Thanks Alex. With that info I have worked out (using a subtle difference >> in the 'from' address in my configuration) which error messages are due to >> '2bounce' error class and which ones are from other classes (most likely >> 'bounce'). >> >> IMO it would be helpful if Postfix added a header to any mail triggered >> by an error identifying what error class(es) triggered it, or would this >> break some RFC? >> > > > I am deluged with messages in the postmaster mailbox reporting failed smtpd transactions for spammers trying to send to non-existent recipients on our domain, which postfix quite rightly rejects (i.e. not listed in virtual_alias_maps). These are smtpd transaction reports not bounces, but they are sent automatically to $bounce_notice_recipient as part of the bounce error class. This is 'by design'; however I don't want to see these (why would I? and the info is in the log anyway), while I do want to see other messages generated as part of the bounce error class, since these can be significant. It is surprising to me that there is no way of turning off one without turning off the other. (My workaround is a script that automatically marks the transaction reports as 'read'.)
Re: Virtual mailbox domains vs relay domains
> On Nov 12, 2017, at 6:15 AM, Tom Marcoen wrote: > >>> Losing recipient validation is NOT an advantage. Either way, >>> you need to have a table of valid recipients to avoid backscatter. >> >> An alternative to a static table is dynamic recipient verification. >> This uses a cache with proactive refresh. >> http://www.postfix.org/ADDRESS_VERIFICATION_README.html >> >>Wietse > > That is exactly what Peer Heinlein also uses in his book but what I > forgot to mention. I like this idea as it better isolates your DMZ > server than when you have your DMZ server access your MySQL database. > > So am I correct that the general population would recommend/prefer > virtual mailbox domains over relay domains in this situation? Real-time access to the full recipient table (be it via LDAP or SQL) is more reliable/predictable than a partial cache. Accessing and caching the data via SMTP/LMTP is perhaps a lower attack surface than the LDAP or MySQL protocols, but not by much. My personal preference in such a situation is to use LDAP or SQL. With LDAP you can spin-up a replica service that is colocated in the DMZ. -- Viktor.
Re: Virtual mailbox domains vs relay domains
Tom Marcoen: > So am I correct that the general population would recommend/prefer > virtual mailbox domains over relay domains in this situation? Yes, virtual_mailbox_domains is for final destinations including LMTP, relay_domains for forwarding to MTAs. Peer may have written some of his text before Postfix virtual_mailbox_domains support was widely available. Wietse
Re: Virtual mailbox domains vs relay domains
On 10 November 2017 at 22:59, Viktor Dukhovni wrote: > >> On Nov 10, 2017, at 8:22 AM, Tom Marcoen wrote: >> >> Last week however, I was reading a book on Dovecot written by Peer >> Heinlein and he says that if you put a Postfix server in front of >> Dovecot you should use 'relay_domains' for these domains, combined >> with 'transport_maps'. > > This is not necessary. LMTP is not SMTP, and you're not relaying > the mail. And even if you were, the destination is not a store- > and-forward MTA, but a mailstore. So it is not unreasonable to > model the associated domain as a virtual mailbox domain. This makes sense. I'm not really relaying the email so perhaps a virtual mailbox domain makes more sense than a relay domain. Peer Heinlein also wrote a (very thick) book on Postfix but alas it's only in German so I will have to translate it before I can read it. On 11 November 2017 at 14:32, Wietse Venema wrote: > Viktor Dukhovni: >> > perhaps more importantly, what is the recommended way of sending >> > emails from Postfix to Dovecot? The advantage of Peer's method is that >> > you can place the Postfix server in a DMZ and it does not need access >> > to your MySQL/... database for username information. >> >> Losing recipient validation is NOT an advantage. Either way, >> you need to have a table of valid recipients to avoid backscatter. > > An alternative to a static table is dynamic recipient verification. > This uses a cache with proactive refresh. > http://www.postfix.org/ADDRESS_VERIFICATION_README.html > > Wietse That is exactly what Peer Heinlein also uses in his book but what I forgot to mention. I like this idea as it better isolates your DMZ server than when you have your DMZ server access your MySQL database. So am I correct that the general population would recommend/prefer virtual mailbox domains over relay domains in this situation?
