[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> syntax/behaviuor of virtual_alias_maps
On Sun, Jan 21, 2024 at 11:35:39PM +0100, Simon Hoffmann via Postfix-users wrote: > > DO NOT use the deprecated "virtual_domains" parameter, it mixes > > classification of domains with address mappings. > > I have read that and I thought I understood it. Simply put, use "virtual_alias_domains" to enumerate any virtual alias domains, and "virtual_alias_maps". DO NOT reply on the backwards-compatible (with Postfix 1.x 20+ years ago) default value of "virtual_alias_domains": virtual_alias_domains = $virtual_alias_maps Instead, set "virtual_alias_domains" explicitly, either empty or a non-empty list of such domains. > I have also read http://www.postfix.org/VIRTUAL_README.html and this states > that with > virtual alias mode I can have the same local part in an email address and > deliver > them to different unix users, You're not reading on its own merit, rather letting your prior expectations obscure the message. Try to forget everything you know about the OpenSMTP virtual table as a model of what virtual mappings do, all you should carry forward is an understanding of the functionality of the individual lines that you want to translate in a suitable manner to Postfix. The Postfix virtual(5) table is *very* different, and to avoid confusion, on this list, lets reserve virtual table for the Postfix version, and your OpenSMTPd configuration file is just some file with lines that implement various behaviours which you'll want to match one line at a time... Note: 0. The virtual(5) mapping applies to ALL envelope recipient addresses, regardless of address class. The domainpart does not need to be listed in virtual_alias_domains! 1. The virtual(5) table is a 1-to-many mapping of input rfc822 recipient addresses to output *addresses*. Nothing you put on the RHS of the *Postfix* virtual(5) file directly causes deliveryu to some file or to a user, or causes a recipient to be rejected... 2. virtual(5) is JUST a one-to-many address mapping. 3. On the RHS, bare "localpart" addresses with no domain part are implicity rewritten to "localpart@$myorigin" 4. The mapping is recursive! Each RHS value is again subject to virtual(5) rewriting, until there's no match, or an address maps to itself (after appening @$myorigin if necessary). 5. Input adresses with a domain part that matches "$myorigin" that don't match as-is, are retried with just the localpart as a lookup key, but the termination check (self-mapping) is based on the full input address. Sepately, Postfix supports virtual_alias_domains, which cannot hold any directly deliverable mailboxes, instead, each address in such a domain must be rewritten to some list of addresses in other domains. > but i can still use local unix users. You want to see "unix users" on the RHS of the table, but what's there are email address localparts, that get an implicit domain when none is explicitly specified. > The first method on that page does not allow me to route > localp...@domain1.com to a different user than localp...@domain2.org This is wrong. You can map any address to some list of addresses. With virtual(5), just write: us...@domain1.com us...@domain.org > (with the exact same localpart) and the third mode on that page does > not use unix users and their home directory to store mails but just a > directory structure, which is also not what i want. With virtual_mailbox_domains you can indeed to deliver to logical users that aren't tied to system accounts. You may need to get a copy of the Postfix book by Patrick Koetter and Ralph Hildebrandt and spend a few days reading the background topics. You need to understand local(8) delivery, and virtual(8) delivery or delivery via an LDA or LMTP to some appropriate mail store. > > It is best to not use the same terminology for two different things. > > Instead let go of the old terminology and focus on function. > > The file that maps an email address to a unix user or another email address > in OpenSMTPd > is literally stated in the config with the keyword "virtual". This is actually a big part of the problem. You need to let go of the diea that these serve the same function. They don't. > > Actually to simon@$myorigin, which may or may not go to the UNIX user, > > depending on how that's handled. > > With the information from http://www.postfix.org/VIRTUAL_README.html I > understand > that this line means that this email address is delivered to the unix user on > the > RHS. Why would I need to specify a domain on the RHS if i want the unix user > simon to > get the mail? No. It is delivered to wherever that address happens to be routed, which depends on the tran
[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> syntax/behaviuor of virtual_alias_maps
Dnia 21.01.2024 o godz. 23:35:39 Simon Hoffmann via Postfix-users pisze: > I have also read http://www.postfix.org/VIRTUAL_README.html and this > states that with virtual alias mode i can have the same local part in an > email address and deliver them to different unix users, but i can still > use local unix users. If you have for example domains example1.com, example2.com and example3.com, one of them (say example1.com) can be your "main" domain where you use unix users as mail destinations, ie. use...@example1.com. You DON'T put any addresses in that domain in virtual_alias_maps, you just list that domain in mydestination= parameter in main.cf. The other two domains, example2.com and example3.com, will be virtual domains. You DON'T list them in mydestination=, but you can handle addresses in virtual domains in two different ways. First, you can put the addresses in virtual_alias_table, and redirect the mail addressed to virtual users either to real unix users on your system OR to remote users on another server. Of course the following should work (if not, then you have done something wrong): usern...@example2.comsomeuser usern...@example3.comotheruser and redirect mail sent to "usern...@example2.com" to user "someuser" on your system, and mail sent to "usern...@example3.com" (the same localpart) to another user "otheruser". The second option is to have virtual mailboxes, where mail is just delivered to some place in the filesystem and you have arranged some method for your virtual users to pick it up (eg. via Dovecot). You list the domain in virtual_mailbox_domains=, and use virtual_mailbox_maps (and possibly other related parameters like eg. virtual_mailbox_base) to specify location of the individual mailboxes like: u...@example4.com /vbox/example4/user I'm using such a setup, with all three kinds of domains (a "real" one, virtual alias and virtual mailbox) and everything works as intended. > The first method on that page does not allow me to route > localp...@domain1.com to a different user than localp...@domain2.org (with > the exact same localpart) By "first method" do you refer to the section "As simple as can be: shared domains, UNIX system accounts". Yes, in that case you just have two fully equivalent domains, both listed in mydestination=. Each unix user, by definition, "belongs" to ALL domains listed in mydestination=. > and the third mode on that page does not use > unix users and their home directory to store mails but just a directory > structure, which is also not what i want. This is the virtual mailbox example mentioned above. So you need the second one: "Postfix virtual ALIAS example: separate domains, UNIX system accounts", as Viktor already explained to you. > The file that maps an email address to a unix user or another email > address in OpenSMTPd is literally stated in the config with the keyword > "virtual". The Postfix equivalent is virtual_alias_maps. > With the information from http://www.postfix.org/VIRTUAL_README.html I > understand that this line means that this email address is delivered to > the unix user on the RHS. Why would I need to specify a domain on the RHS > if i want the unix user simon to get the mail? You don't have to. You have to remember that because virtual aliasing is done in the cleanup(8) process, and mail whose RHS is "simon" is then passed to local(8) process for delivery, it may be subject to further aliasing in that process, according to alias_maps table (whose default value is /etc/aliases). So if you have defined in your virtual_alias_table: usern...@domain2.com simon and in your /etc/aliases file: simon extu...@example.net then the mail will be effectively forwarded to extu...@example.net, and not delivered to local user simon (but the same applies to all mail addressed to local user simon, regardless of the origin). -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> syntax/behaviuor of virtual_alias_maps
Viktor Dukhovni via Postfix-users wrote: > On Sun, Jan 21, 2024 at 07:21:26PM +0100, Simon Hoffmann via Postfix-users > wrote: > > > The old virtual_domains file just lists all domains (one per line), and can > > directly be used in > > virtual_alias_domains. > > You're going about this the wrong way, by tryign to translate low-level > artefacts from one system to somewhat related, but different low-level > artefacts in Postfix. Instead you need to implement a functional at a > higher layer. > > Postfix support virtual alias rewriting (for all envelope recipient > addresses), and virtual alias domains (which make rewriting mandatory, > since there are no actual mailbox recipients in the domain, just aliases > to mailboxes in *other* domains). > > You need to read and understand: > > - ADDRESS_CLASS_README > - ADDRESS_REWRITING_README > - The virtual(5) manpage > - The postconf(5) descriptions of: > * virtual_alias_domains > * virtual_alias_maps > > DO NOT use the deprecated "virtual_domains" parameter, it mixes > classification of domains with address mappings. I have read that and I thought I understood it. I have also read http://www.postfix.org/VIRTUAL_README.html and this states that with virtual alias mode i can have the same local part in an email address and deliver them to different unix users, but i can still use local unix users. The first method on that page does not allow me to route localp...@domain1.com to a different user than localp...@domain2.org (with the exact same localpart) and the third mode on that page does not use unix users and their home directory to store mails but just a directory structure, which is also not what i want. > > > However, in my virtual aliases table on OpenSMTPd, I have the following > > line-types > > It is best to not use the same terminology for two different things. > Instead let go of the old terminology and focus on function. The file that maps an email address to a unix user or another email address in OpenSMTPd is literally stated in the config with the keyword "virtual". > > > si...@simonhoffmann.net simon > > > > The first line is obvious. Mail addressed to the email address is delivered > > to the > > UNIX user. > > This is an address mapping, best practice is to also specify a domain on > the RHS, which by default gets qualified with "@$myorigin", but if you > have a specific domain in mind, specify it here. > > Actually to simon@$myorigin, which may or may not go to the UNIX user, > depending on how that's handled. With the information from http://www.postfix.org/VIRTUAL_README.html I understand that this line means that this email address is delivered to the unix user on the RHS. Why would I need to specify a domain on the RHS if i want the unix user simon to get the mail? Or is specifying @$myhostname the actual (and only?) way to tell postfix to deliver to the local user? With that in mind, i am using sieve rules in dovecot and require the mails to be delivered to dovecot via lmtp. Upon reading the docs again just now it seems that i have to use virtual domains mode and virtual_mailbox_domains and virtual_mailbox_maps to be able to use virtual_transport, which in my understanding is the only way to hand mail off to dovecot. I think i just broke my brain and need to pause for a few weeks before trying to understand the config again ^^ The site also states to add the domain to the virtal_alias_domains, by the way. Is the documentation wrong? > > > @list.simonhoffmann.net simon > > > > The second line is also obvious, as this is a catchall for a domain. In > > Postfix this > > has also the lowest priority so I don't break my current alias file. > > Catchalls are best avoided. If you have a specific list of valid > addresses, best to specify each one. Well for one i am lazy and dont want to edit my map all the time. :) Secondly, aside from getting more spam (which i can live with), why is it best to avoid a catchall? > > > simon simon > > > For the third line, the documenation under > > http://www.postfix.org/virtual.5.html > > specifies > > You're looking at the wrong documentation, that line from OpenSMTPD, What would be the right documentation? Above you asked me to read virtual(5)... > what is supposed to achieve? Then figure out whether it is needed, > and how to get equivalent *functionality* (not syntax) from Postfix. > > > So I am not sure if this would work and the third line would be an accepted > > line or > > if I need to replace this line with a user@domain line for every virtual > > d
[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> syntax/behaviuor of virtual_alias_maps
On Sun, Jan 21, 2024 at 07:21:26PM +0100, Simon Hoffmann via Postfix-users
wrote:
> The old virtual_domains file just lists all domains (one per line), and can
> directly be used in
> virtual_alias_domains.
You're going about this the wrong way, by tryign to translate low-level
artefacts from one system to somewhat related, but different low-level
artefacts in Postfix. Instead you need to implement a functional at a
higher layer.
Postfix support virtual alias rewriting (for all envelope recipient
addresses), and virtual alias domains (which make rewriting mandatory,
since there are no actual mailbox recipients in the domain, just aliases
to mailboxes in *other* domains).
You need to read and understand:
- ADDRESS_CLASS_README
- ADDRESS_REWRITING_README
- The virtual(5) manpage
- The postconf(5) descriptions of:
* virtual_alias_domains
* virtual_alias_maps
DO NOT use the deprecated "virtual_domains" parameter, it mixes
classification of domains with address mappings.
> However, in my virtual aliases table on OpenSMTPd, I have the following
> line-types
It is best to not use the same terminology for two different things.
Instead let go of the old terminology and focus on function.
> si...@simonhoffmann.net simon
>
> The first line is obvious. Mail addressed to the email address is delivered
> to the
> UNIX user.
This is an address mapping, best practice is to also specify a domain on
the RHS, which by default gets qualified with "@$myorigin", but if you
have a specific domain in mind, specify it here.
Actually to simon@$myorigin, which may or may not go to the UNIX user,
depending on how that's handled.
> @list.simonhoffmann.net simon
>
> The second line is also obvious, as this is a catchall for a domain. In
> Postfix this
> has also the lowest priority so I don't break my current alias file.
Catchalls are best avoided. If you have a specific list of valid
addresses, best to specify each one.
> simon simon
> For the third line, the documenation under
> http://www.postfix.org/virtual.5.html
> specifies
You're looking at the wrong documentation, that line from OpenSMTPD,
what is supposed to achieve? Then figure out whether it is needed,
and how to get equivalent *functionality* (not syntax) from Postfix.
> So I am not sure if this would work and the third line would be an accepted
> line or
> if I need to replace this line with a user@domain line for every virtual
> domain.
What is the "simon" entry supposed to achieve? How does it augment the
functionality of the first line?
> nore...@simonhoffmann.net /dev/null
> The fourth line in the old alias file silently discard a mail.
Postfix virtual(5) aliases are (rfc822) address-to-address mappings.
You cannot use "/dev/null" or similar here. That's a feature of local
aliases(5). But far better:
valias:
nore...@simonhoffmann.net noreply@discard.invalid
transport:
discard.invalid discard:silently
master.cf
# Should already have a "discard" transport
> OpenSMTPd allows the right hand site to be either a unix user, a
> different email address or simply a path to a file to which it will
> append the new email.
That's what local aliases do in Postfix, but best to avoid the legacy
Sendmail-compatible local delivery agent as much as possible. Use it
only for outbound delivery to mailing lists, where "owner-alias" and
":include:/member-file", ... are useful features.
For address-to-address rewriting use virtual(5).
> Thus /dev/null on the right hand site would mark the email as
> successfully received to the sending server, but then discards the
> mail internally. Is this possible with postfix as well?
See above.
> s...@simonhoffmann.net error:550 no spam here!
>
> Lastly, the fifth line bounces the email with the given error code and
> the given message. I have used this to disable specific address on an
> otherwise catch all domain. The spam example above is only an example,
> I have used this for address that were previously used but are not any
> longer and I would like the sender to know that this address is no
> longer in use. Is something like this possible as well?
This goes in the transport(5) file, better as:
s...@simonhoffmann.net error:5.1.1 Mailbox unavailable
and/or an access(5) table with "check_recipient_access":
main.cf:
indexed = ${default_database_type}:${config_directory}/
transport_maps = ${indexed}transport
smtpd_recipient_restrictions =
check_recipient_access ${indexed}rcpt-access,
permit_mynetworks,
reject_unauth_destination,
...
rcpt-access:
s...@simonho
[pfx] Preparation of switch from OpenSMTPd to Postfix -> syntax/behaviuor of virtual_alias_maps
Hey all, I found a second topic where I am not sure how postfix behaves. The old virtual_domains file just lists all domains (one per line), and can directly be used in virtual_alias_domains. However, in my virtual aliases table on OpenSMTPd, I have the following line-types si...@simonhoffmann.net simon @list.simonhoffmann.net simon simon simon nore...@simonhoffmann.net /dev/null s...@simonhoffmann.net error:550 no spam here! The first line is obvious. Mail addressed to the email address is delivered to the UNIX user. The second line is also obvious, as this is a catchall for a domain. In Postfix this has also the lowest priority so I don't break my current alias file. With the following lines however, I am not sure if this is possible with postfix. For the third line, the documenation under http://www.postfix.org/virtual.5.html specifies user address, address, ... Redirect mail for user@site to address when site is equal to $myorigin, when site is listed in $mydestination, or when it is listed in $inet_interfaces or $proxy_interfaces. The virtual domain however is not part of either myorigin or mydestination, and is abviously not an IP address so inet/proxy_interfaces does not apply either. So I am not sure if this would work and the third line would be an accepted line or if I need to replace this line with a user@domain line for every virtual domain. The fourth line in the old alias file silently discard a mail. OpenSMTPd allows the right hand site to be either a unix user, a different email address or simply a path to a file to which it will append the new email. Thus /dev/null on the right hand site would mark the email as successfully received to the sending server, but then discards the mail internally. Is this possible with postfix as well? Lastly, the fifth line bounces the email with the given error code and the given message. I have used this to disable specific address on an otherwise catch all domain. The spam example above is only an example, I have used this for address that were previously used but are not any longer and I would like the sender to know that this address is no longer in use. Is something like this possible as well? And then I have read the following in the documentation: /etc/postfix/virtual: virtual-alias.domainanything (right-hand content does not matter) The virtual-alias.domain anything entry is required for a virtual alias domain. Without this entry, mail is rejected with "relay access denied", or bounces with "mail loops back to myself". Do I understand it correctly that this is only necessary if I do not use virtual_alias_domains? If I use this separate file to specify only the domain names, this line is not needed in the alias mapping file, right? Thanks for your help! Cheers, Simon signature.asc Description: PGP signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On Mon, May 08, 2023 at 12:33:31PM +1000, Sean Gallagher via Postfix-users wrote: > > [ Yes, one could also craft "classless" access(5) tables, ... and rely > >only on explicit transport(5) table entries, opting out of all the > >taxonomy that makes it easier to reason about Postfix mail routing, > >but this is not a good idea, and users advanced enough to do that > >aren't the audience for the README tutorials. ] > > With all due respect, there is no "advanced user" documentation, the > advanced users are reading the READMEs just like everyone else - or the > source code. The "advanced users" are doing OK between the README tutorials, the postconf(5) parameter docs and the source code. There's also the book by Patrick and Ralf as well as the O'Reilly book. One thing that's under-documented from an advanced user perspective is: - String, hostname and address match lists. - Which parameters are match lists and of which type. The description of match lists could be in DATABASE_README, with references from the various parameters as appropriate. Care to contribute some text? -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Viktor Dukhovni via Postfix-users writes: > (...) > [ Yes, one could also craft "classless" access(5) tables, ... and rely > only on explicit transport(5) table entries, opting out of all the > taxonomy that makes it easier to reason about Postfix mail routing, > but this is not a good idea, and users advanced enough to do that > aren't the audience for the README tutorials. ] Hellow Viktor, I strongly agree with you, thanks! Sincerely, Byung-Hee from South Korea -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On 5/05/2023 11:52 am, Sean Gallagher via Postfix-users wrote: While Wietse has his word processor open, I'd like to share a few of my greatest misdirects in my evolving understanding of Postfix. To quote a like minded individual I simply want to help others avoid my points of confusion, in the belief I am not a uniquirely incapable or unintelligent reader. 1) virtual_alias_maps is not only applied to virtual_alias_domains, but to _all_ domains that Pf receives mail for. http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in this respect. I really wish I had understood this earlier, it would have saved a lot of time. 2) macros in main.cf. There is a comment in the default master.cf https://github.com/vdukhovni/postfix/blob/master/postfix/conf/master.cf: # specify "smtpd__restrictions=$mua__restrictions" # here, and specify mua__restrictions in main.cf (where # "" is "client", "helo", "sender", "relay", or "recipient"). # Instead of specifying complex smtpd__restrictions here, It took too long to realize that these mua__restrictions are not builtin names but macro names, invented as required. This ability to create macros in main.cf should be documented. At the start of the http://www.postfix.org/postconf.5.html man page is a section on file syntax. That would seem an appropriate place to document this functionality. Sean. This list has become too much of a distraction for me. It seems well intentioned feedback on how to improve is not really welcomed here. I joined this list to report a bug, which has now been fixed. Many thanks Wietse. So now I am done. I thank the Postfix developers for a great product and apologize to those whose time I have wasted with my misguided posts. Warmest regards to All. Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
[ Yes, one could also craft "classless" access(5) tables, ... and rely only on explicit transport(5) table entries, opting out of all the taxonomy that makes it easier to reason about Postfix mail routing, but this is not a good idea, and users advanced enough to do that aren't the audience for the README tutorials. ] With all due respect, there is no "advanced user" documentation, the advanced users are reading the READMEs just like everyone else - or the source code. -- This email has been checked for viruses by AVG antivirus software. www.avg.com ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On Mon, May 08, 2023 at 11:00:55AM +1000, Sean Gallagher via Postfix-users wrote: > check_rcpt_maps() in smtpd_check.c first looks for the recipient in > rcpt_canon_mapsand virt_alias_maps, that's the class-less part. Then it > classifies the recipient domain and checks the relevant recipient table > - that's the class-full part. One could also turn off recipient validation entirely, and Postfix would still have meaninful address classes, because these are the basis of transport resolution and relay control. Adding a recipient to virtual_alias_maps DOES NOT make Postfix accept mail for the recipient from untrusted senders, for that the domain would have to be listed in one of the address classes matched by permit_auth_destination. [ Yes, one could also craft "classless" access(5) tables, ... and rely only on explicit transport(5) table entries, opting out of all the taxonomy that makes it easier to reason about Postfix mail routing, but this is not a good idea, and users advanced enough to do that aren't the audience for the README tutorials. ] -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On 8/05/2023 10:19 am, Wietse Venema via Postfix-users wrote: Sean Gallagher via Postfix-users: ADDRESS_CLASS_README: The most misleading place for me was the ADDRESS_CLASS_README For "The virtual alias domain class" it says: "Valid recipient addresses are listed with the virtual_alias_maps parameter" which is of course true, but there is nothing special about the virtual alias domain class in that respect. After reading that readme, one could be forgiven for thinking that the virtual_alias_maps would not be applied to the other domain classes. The virtual_alias_maps parameter should at least be mentioned in the recipient address text of the other domain class explanations. Perhaps another less confusing way to document it would be to describe a "class-less" mode of operation that uses just the virtual_alias_maps and transport_maps, and go on to say that class-full and class-less routing can co-exist. sorry, that class-less idea ignores the REQUIREMENT for recipient address validation. The Postfix SMTP server MUST accept only recipient addresses match the recipient table for their address class. I'm not suggesting any new functionality. I'm only describing how Pf currently works, to the best of my knowledge. check_rcpt_maps() in smtpd_check.c first looks for the recipient in rcpt_canon_mapsand virt_alias_maps, that's the class-less part. Then it classifies the recipient domain and checks the relevant recipient table - that's the class-full part. You _could_ (not saying it's a good idea) configure Pf with $mydestination, $virtual_alias_domains, $virtual_mailbox_domains and $relay_domains all empty and rely only on $virtual_alias_maps and $transport_maps and have a perfectly functional and secure system. i.e. the fully class-less path. Anyway, it was just an idea - not meant to be provocative. Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On Mon, May 08, 2023 at 09:55:28AM +1000, Sean Gallagher via Postfix-users
wrote:
> Q: how would an entry in virtual_alias_maps like
> localpart@$virtual_alias_domains localpart@$virtual_alias_domains be
> handled?
> A: It would stay in $virtual_alias_domains and be handed to
> {$transport_maps, $default_transport} ???
No. It is handed to the "error" transport, which will bounce the
recipient.
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Sean Gallagher via Postfix-users:
> ADDRESS_CLASS_README:
>
> The most misleading place for me was the ADDRESS_CLASS_README
>
> For "The virtual alias domain class" it says:
> "Valid recipient addresses are listed with the virtual_alias_maps
> parameter"
> which is of course true, but there is nothing special about the virtual
> alias domain class in that respect. After reading that readme, one could
> be forgiven for thinking that the virtual_alias_maps would not be
> applied to the other domain classes.
>
> The virtual_alias_maps parameter should at least be mentioned in the
> recipient address text of the other domain class explanations.
>
> Perhaps another less confusing way to document it would be to describe a
> "class-less" mode of operation that uses just the virtual_alias_maps and
> transport_maps, and go on to say that class-full and class-less routing
> can co-exist.
sorry, that class-less idea ignores the REQUIREMENT for recipient
address validation. The Postfix SMTP server MUST accept only
recipient addresses match the recipient table for their address
class.
> ADDRESS_REWRITING_README:
> Resolve address to section
>
> I think the virtual_alias_domain should be in both tables.
Sorry, that is wrong. At this point in message processing, there
are NO RECIPIENTS in a virtual alias domain.
By definition, all valid recipients in a virtual alias domain are
rewritten to a different domain class. Any addresses that are still
in a virtual alias domain are returned as 'user unknown'.
> Q: how would an entry in virtual_alias_maps like
> localpart@$virtual_alias_domains localpart@$virtual_alias_domains be
> handled? A: It would stay in $virtual_alias_domains and be handed to
> {$transport_maps, $default_transport} ???
No, absolutely not. Again, at this point there are NO recipients
in a virtual alias domain.
By definition, all valid recipients in a virtual alias domain are
rewritten to a different domain class. Any addresses that are still
in a virtual alias domain are returned as 'user unknown'.
I'll stop here.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
ADDRESS_CLASS_README:
The most misleading place for me was the ADDRESS_CLASS_README
For "The virtual alias domain class" it says:
"Valid recipient addresses are listed with the virtual_alias_maps
parameter"
which is of course true, but there is nothing special about the virtual
alias domain class in that respect. After reading that readme, one could
be forgiven for thinking that the virtual_alias_maps would not be
applied to the other domain classes.
The virtual_alias_maps parameter should at least be mentioned in the
recipient address text of the other domain class explanations.
Perhaps another less confusing way to document it would be to describe a
"class-less" mode of operation that uses just the virtual_alias_maps and
transport_maps, and go on to say that class-full and class-less routing
can co-exist.
ADDRESS_REWRITING_README:
Resolve address to section
I think the virtual_alias_domain should be in both tables.
The first to show that this is a Postfix 2.0 feature and also to link to
the virtual_alias_domains parameter and to exhaustively document the
possible input domains. The delivery method for Virtual alias can be
stated as "Not Applicable".
Q: how would an entry in virtual_alias_maps like
localpart@$virtual_alias_domains localpart@$virtual_alias_domains be
handled? A: It would stay in $virtual_alias_domains and be handed to
{$transport_maps, $default_transport} ???
The second table should include Virtual Alias to again, exhaustively
document the possible inputs. Transport sources and next hop sources are
the same as Default domain class ???.
As far as I can tell, the only difference between virtual_alias_domains
and the default domain class, is that virtual_alias_domains will bounce
recipients not in virtual_alias_maps or canonical_maps? Please correct me.
Sean.
On 8/05/2023 12:38 am, Wietse Venema via Postfix-users wrote:
Matus UHLAR - fantomas via Postfix-users:
I looked at docs (*README) and haven't found any.
I'd still prefer to explicitly note that virtual_alias_maps are applied
even for non-local e-mail
...you use "all email deliveries", I wonder if something like
"all emails processed (even non-local deliveries)" wouldn't be better.
Whether that helps depends on the reader's point of view. Som readers
e might be helped more with:
...all email deliveries (even local)...
Better, the virtual(5) text says
...all local, all virtual, and all remote...
which helps readers with all points of view.
I'll make this similar in virtual(5), aliases(5), 2x in postconf(5),
and 2x in ADDRESS_REWRITING_README.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Matus UHLAR - fantomas via Postfix-users: > I looked at docs (*README) and haven't found any. > > I'd still prefer to explicitly note that virtual_alias_maps are applied > even for non-local e-mail > ...you use "all email deliveries", I wonder if something like > "all emails processed (even non-local deliveries)" wouldn't be better. Whether that helps depends on the reader's point of view. Som readers e might be helped more with: ...all email deliveries (even local)... Better, the virtual(5) text says ...all local, all virtual, and all remote... which helps readers with all points of view. I'll make this similar in virtual(5), aliases(5), 2x in postconf(5), and 2x in ADDRESS_REWRITING_README. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On 05.05.23 11:52, Sean Gallagher via Postfix-users wrote: >While Wietse has his word processor open, I'd like to share a few of >my greatest misdirects in my evolving understanding of Postfix. > >To quote a like minded individual > >I simply want to help others avoid my points of confusion, in the belief I >am not a uniquirely incapable or unintelligent reader. > >1) virtual_alias_maps is not only applied to virtual_alias_domains, >but to _all_ domains that Pf receives mail for. >http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in >this respect. I really wish I had understood this earlier, it would >have saved a lot of time. Matus UHLAR - fantomas via Postfix-users: I had this problem too and I think that explicitly stating something like: On 05.05.23 10:34, Wietse Venema via Postfix-users wrote: The problem is that this information exists in some places but not all places where aliasling is discussed. This should not be a problem. New text for postconf(5): virtual_alias_maps (default: $virtual_maps) Optional lookup tables with aliases that apply for all email deliveries, unlike alias_maps that apply only for local(8) delivery. [...] alias_maps (default: see "postconf -d" output) Optional lookup tables with aliases that apply only for local(8) delivery, unlike virtual_alias_maps which apply for all email deliveries. [...] New text for ADDRESS_CLASS_README: Virtual aliasing Note: virtual aliasing (virtual_alias_maps) applies for all email deliveries, unlike local aliasing (alias_maps) which applies only to local(8) delivery. Local alias database Note: local aliasing (alias_maps) applies only for local(8) delivery, unlike virtual aliasing (virtual_alias_maps) which applies for all email deliveries. Are there any other placs that need to bve updated? I looked at docs (*README) and haven't found any. I'd still prefer to explicitly note that virtual_alias_maps are applied even for non-local e-mail ...you use "all email deliveries", I wonder if something like "all emails processed (even non-local deliveries)" wouldn't be better. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Due to unexpected conditions Windows 2000 will be released in first quarter of year 1901 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Matus UHLAR - fantomas via Postfix-users: > On 05.05.23 11:52, Sean Gallagher via Postfix-users wrote: > >While Wietse has his word processor open, I'd like to share a few of > >my greatest misdirects in my evolving understanding of Postfix. > > > >To quote a like minded individual > > > >I simply want to help others avoid my points of confusion, in the belief I > >am not a uniquirely incapable or unintelligent reader. > > > >1) virtual_alias_maps is not only applied to virtual_alias_domains, > >but to _all_ domains that Pf receives mail for. > >http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in > >this respect. I really wish I had understood this earlier, it would > >have saved a lot of time. > > I had this problem too and I think that explicitly stating something like: The problem is that this information exists in some places but not all places where aliasling is discussed. New text for postconf(5): virtual_alias_maps (default: $virtual_maps) Optional lookup tables with aliases that apply for all email deliveries, unlike alias_maps that apply only for local(8) delivery. [...] alias_maps (default: see "postconf -d" output) Optional lookup tables with aliases that apply only for local(8) delivery, unlike virtual_alias_maps which apply for all email deliveries. [...] New text for ADDRESS_CLASS_README: Virtual aliasing Note: virtual aliasing (virtual_alias_maps) applies for all email deliveries, unlike local aliasing (alias_maps) which applies only to local(8) delivery. Local alias database Note: local aliasing (alias_maps) applies only for local(8) delivery, unlike virtual aliasing (virtual_alias_maps) which applies for all email deliveries. Are there any other placs that need to bve updated? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On 05.05.23 11:52, Sean Gallagher via Postfix-users wrote: While Wietse has his word processor open, I'd like to share a few of my greatest misdirects in my evolving understanding of Postfix. To quote a like minded individual I simply want to help others avoid my points of confusion, in the belief I am not a uniquirely incapable or unintelligent reader. 1) virtual_alias_maps is not only applied to virtual_alias_domains, but to _all_ domains that Pf receives mail for. http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in this respect. I really wish I had understood this earlier, it would have saved a lot of time. I had this problem too and I think that explicitly stating something like: virtual_alias_maps (if set) expansion is applied to all recipient addresses, even if they aren't local, so this way it's possible to redirect mail for remote recipients would help much. Also, mentioning the main difference between virtual_alias_maps (applied at input) and alias_maps (applied at delivery, supporting :include:, pipe and file destinations just as owner- prefix) would be nice to have. Especially since it's advised to move address expansion from aliases to virtual_alias_maps when possible to avoid double deliveries for problematic destinations. 2) macros in main.cf. There is a comment in the default master.cf https://github.com/vdukhovni/postfix/blob/master/postfix/conf/master.cf: # specify "smtpd__restrictions=$mua__restrictions" # here, and specify mua__restrictions in main.cf (where # "" is "client", "helo", "sender", "relay", or "recipient"). # Instead of specifying complex smtpd__restrictions here, It took too long to realize that these mua__restrictions are not builtin names but macro names, invented as required. This ability to create macros in main.cf should be documented. At the start of the http://www.postfix.org/postconf.5.html man page is a section on file syntax. That would seem an appropriate place to document this functionality. agree. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Quantum mechanics: The dreams stuff is made of. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
While Wietse has his word processor open, I'd like to share a few of my greatest misdirects in my evolving understanding of Postfix. To quote a like minded individual I simply want to help others avoid my points of confusion, in the belief I am not a uniquirely incapable or unintelligent reader. 1) virtual_alias_maps is not only applied to virtual_alias_domains, but to _all_ domains that Pf receives mail for. http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in this respect. I really wish I had understood this earlier, it would have saved a lot of time. 2) macros in main.cf. There is a comment in the default master.cf https://github.com/vdukhovni/postfix/blob/master/postfix/conf/master.cf: # specify "smtpd__restrictions=$mua__restrictions" # here, and specify mua__restrictions in main.cf (where # "" is "client", "helo", "sender", "relay", or "recipient"). # Instead of specifying complex smtpd__restrictions here, It took too long to realize that these mua__restrictions are not builtin names but macro names, invented as required. This ability to create macros in main.cf should be documented. At the start of the http://www.postfix.org/postconf.5.html man page is a section on file syntax. That would seem an appropriate place to document this functionality. Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: DKIM signing after virtual_alias_maps
On Sat, Dec 17, 2022 at 11:32:18PM +0100, Michael Ströder wrote: > I've added DKIM signing with this config snippet: DKIM signs the message headers and body. > But I also have simple mail group expansion with virtual alias maps: The virtual(5) table rewrites only the message envelope. -- Viktor.
DKIM signing after virtual_alias_maps
HI! I've added DKIM signing with this config snippet: # DKIM signing milter_default_action = accept milter_protocol = 6 smtpd_milters = unix:/run/opendkim/opendkim.socket non_smtpd_milters = unix:/run/opendkim/opendkim.socket That's working fine for me in case of sending simple mails. But I also have simple mail group expansion with virtual alias maps: virtual_alias_maps = proxy:ldap:/etc/postfix/ldap_list_aliases-nisMailAlias.cf,proxy:ldap:/etc/postfix/ldap_virtual.cf So DKIM signing happens *before* list expansion which seems wrong. Any way to fix this without running multiple instances of smtpd? Ciao, Michael.
Re: virtual_mailbox_maps & virtual_alias_maps
Tuesday, February 22, 2022, 11:27:30 AM, post...@ptld.com wrote: >> There doesn't appear to be a way to say "here is user and this is his >> email address". It seems to be assumed that user "Fred" will have an >> email >> address of "fred@..." and no way to override that. > That is not how dovecot works. Dovecot goes "here is this authenticated user > and they are allowed to view mail in this inbox/directory". > You specify in config how someone is authenticated then you tell config the > path to the mbox or maildir/ that user can access. > Dovecot doesn't see email addresses, it just see's authenticated users. > Id doesn't care if you were authenticated by the username "f...@domain.com" > or "fredIsCool". > The email exist only in your mind, to dovecot it's just a string to match > with a password. > Mail doesn't "belong" to or is "owned" by an email address. > You can take mail files out of one maildir/ path and dump them into someone > else's maildir/ and now that 2nd person can access those emails. > In the config, you normally would say something like "f...@domain.com" has > access to "/var/spool/mail/domain.com/fred/" > Or "f...@domain.com" has access to "/home/fred/mail/" depending how you set > your system up. > You can just as easy say "fredIsCool" has access to > "/var/spool/mail/domain.com/fred/" > If you want to give fred someone else's mailbox you can say "f...@domain.com" > has access to "/var/spool/mail/domain.com/bob/" and next time fred logs in he > will see bob's emails. Just remember, the concept of email addresses is only > in your mind. Dovecot simply maps "authenticated user" to a directory of your > choice set in config. > Now if you just do the bare minimum of telling dovecot the path to the files > **IS** the name of authenticated user, then sure the path would obviously be > the same as the named used to login. > But you can get more complicated, for example using SQL, one column has the > username "fred" or "f...@domain.com" and another column can be the path to > his emails. Then you are not limited to the path having to match the > username. You might also be able to hard code names and paths in flat files > without having to setup a database. Thank you so much for that explanation. That separation is sort of what I expected originally. Don't know how/why I went down the path I did. Now I need to backtrack and see what I need to change. Thanks again, Phil
Re: virtual_mailbox_maps & virtual_alias_maps
> There doesn't appear to be a way to say "here is user and this is his > email address". It seems to be assumed that user "Fred" will have an > email > address of "fred@..." and no way to override that. That is not how dovecot works. Dovecot goes "here is this authenticated user and they are allowed to view mail in this inbox/directory". You specify in config how someone is authenticated then you tell config the path to the mbox or maildir/ that user can access. Dovecot doesn't see email addresses, it just see's authenticated users. Id doesn't care if you were authenticated by the username "f...@domain.com" or "fredIsCool". The email exist only in your mind, to dovecot it's just a string to match with a password. Mail doesn't "belong" to or is "owned" by an email address. You can take mail files out of one maildir/ path and dump them into someone else's maildir/ and now that 2nd person can access those emails. In the config, you normally would say something like "f...@domain.com" has access to "/var/spool/mail/domain.com/fred/" Or "f...@domain.com" has access to "/home/fred/mail/" depending how you set your system up. You can just as easy say "fredIsCool" has access to "/var/spool/mail/domain.com/fred/" If you want to give fred someone else's mailbox you can say "f...@domain.com" has access to "/var/spool/mail/domain.com/bob/" and next time fred logs in he will see bob's emails. Just remember, the concept of email addresses is only in your mind. Dovecot simply maps "authenticated user" to a directory of your choice set in config. Now if you just do the bare minimum of telling dovecot the path to the files **IS** the name of authenticated user, then sure the path would obviously be the same as the named used to login. But you can get more complicated, for example using SQL, one column has the username "fred" or "f...@domain.com" and another column can be the path to his emails. Then you are not limited to the path having to match the username. You might also be able to hard code names and paths in flat files without having to setup a database.
Re: virtual_mailbox_maps & virtual_alias_maps
* Phil Biggs: > There doesn't appear to be a way to say "here is user and this is his > email address". It seems to be assumed that user "Fred" will have an > email address of "fred@..." and no way to override that. https://doc.dovecot.org/configuration_manual/authentication/user_database_extra_fields/ might be what you are looking for. -Ralph
Re: virtual_mailbox_maps & virtual_alias_maps
Tuesday, February 22, 2022, 8:58:32 AM, Jaroslaw Rafa wrote: > Dnia 22.02.2022 o godz. 08:00:44 Phil Biggs pisze: >> >> This is the thing that I could not figure out from the Dovecot >> documentation - mapping between Dovecot login names and mailboxes. > As far as I understand, Dovecot "userdb" specifies this: > https://doc.dovecot.org/configuration_manual/authentication/user_databases_userdb/ Thanks, yes, I read that and lots of other Dovecot docs many, many times. I also searched the Dovecot mail archive without success. There doesn't appear to be a way to say "here is user and this is his email address". It seems to be assumed that user "Fred" will have an email address of "fred@..." and no way to override that. -- Cheers, Phil
Re: virtual_mailbox_maps & virtual_alias_maps
Dnia 22.02.2022 o godz. 08:00:44 Phil Biggs pisze: > > This is the thing that I could not figure out from the Dovecot > documentation - mapping between Dovecot login names and mailboxes. As far as I understand, Dovecot "userdb" specifies this: https://doc.dovecot.org/configuration_manual/authentication/user_databases_userdb/ -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: virtual_mailbox_maps & virtual_alias_maps
Monday, February 21, 2022, 11:23:11 PM, Jaroslaw Rafa wrote: > Dnia 21.02.2022 o godz. 13:09:19 Alexey Shpakovsky pisze: >> On Mon, February 21, 2022 12:59, Jaroslaw Rafa wrote: >> > >> > The part I am wondering about is exactly "Dovecot accepts". As far as I >> > know, Dovecot does not need to "accept" anything, because it does not >> > receive mail. >> >> > At least that's how I always used it :). >> >> I believe that's how most of us configure it, indeed! >> >> >> But Dovecot also has an LMTP server: >> https://doc.dovecot.org/configuration_manual/protocols/lmtp_server/ >> (LMTP is like SMTP, just lighter) > Yes, but the OP did not state that he uses Dovecot in LMTP mode. If this is > the case, he should make it clear, because this is not typical use case. I do apologize. I thought I had mentioned using LMTP but really should have included all of this anyway: virtual_mailbox_domains = pjb.cc virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox virtual_alias_maps = hash:/usr/local/etc/postfix/virtual virtual_transport = lmtp:unix:/var/spool/postfix/private/dovecot-lmtp And: smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unlisted_recipient, permit -- Cheers, Phil
Re: virtual_mailbox_maps & virtual_alias_maps
Monday, February 21, 2022, 10:59:10 PM, Jaroslaw Rafa wrote: > Dovecot comes into play only when user logs in to IMAP account. It keeps its > own mapping between login names (which do not need to be email addresses, > they can be just any names) and mailboxes corresponding to these users. > User logs in using some name and gets access to a particular mailbox. > That's all what Dovecot does. This is the thing that I could not figure out from the Dovecot documentation - mapping between Dovecot login names and mailboxes. That's why I went down the alias path in postfix. It seemed to me that Dovecot login names and email addresses had to match. That is, user logging in from an MUA as "fred@my.domain" (with POP3) could not retrieve email sent to mb123456@my.domain FWIW, no Dovecot user has a Unix account. -- Cheers, Phil
Re: virtual_mailbox_maps & virtual_alias_maps
On 2022-02-20 01:49, Phil Biggs wrote: I have virtual_mailbox_maps in use with reject_unlisted _recipent and use virtual_alias_maps to translate a validated address into a single matching address for the corresponding dovecot user. For example: /usr/local/etc/postfix/vmailbox validu...@example.com whatever /usr/local/etc/postfix/vuser validu...@example.com dovecotu...@example.com In my case, these two tables will always match on the LHS. Just wondering whether there any reason not to use the virtual _alias table for both purposes? It would make synchronisation with the dovecot users DB just a little easier. virtual_mailbox_maps = hash:/usr/local/etc/postfix/vuser virtual_alias_maps = hash:/usr/local/etc/postfix/vuser Seems to me that someone asking this is probably receiving mail for a very small number of users and domains, and therefore, virtual(8) mailbox delivery might not be the best choice. http://www.postfix.org/BASIC_CONFIGURATION_README.html local(8) delivery (to Unix system users) has many features lacking in virtual mailbox delivery. For example, ~.forward files and user control of delivery of recipient_delimiter tagged mail. I make extensive use of this feature. As for the question itself, keep in mind, virtual_mailbox_maps only apply to domains in virtual_mailbox_domains, whereas virtual(5) alias mapping is done for every address, regardless of class. (Offer void where taxed or prohibited, or in cases of receive_override_options disabling address mapping.) (Mail sent directly to dovecotu...@example.com should be rejected.) That's actually a second question. Two ways, basically. You can ensure the address does not exist in the recipient maps for your chosen address class. Or, you can use a check_recipient_access restriction to reject for that address in smtpd(8). -- http://rob0.nodns4.us/
Re: virtual_mailbox_maps & virtual_alias_maps
Dnia 21.02.2022 o godz. 13:09:19 Alexey Shpakovsky pisze: > On Mon, February 21, 2022 12:59, Jaroslaw Rafa wrote: > > > > The part I am wondering about is exactly "Dovecot accepts". As far as I > > know, Dovecot does not need to "accept" anything, because it does not > > receive mail. > > > At least that's how I always used it :). > > I believe that's how most of us configure it, indeed! > > > But Dovecot also has an LMTP server: > https://doc.dovecot.org/configuration_manual/protocols/lmtp_server/ > (LMTP is like SMTP, just lighter) Yes, but the OP did not state that he uses Dovecot in LMTP mode. If this is the case, he should make it clear, because this is not typical use case. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: virtual_mailbox_maps & virtual_alias_maps
Dnia 21.02.2022 o godz. 22:30:31 Phil Biggs pisze: > > Dovecot only accepts email for addresses for which it has a matching user > account. As you say, it is just used a message store. However, I wasn't able > to find a way to have a dovecot user receive mail addressed to any address > other than one that matched the login "user" name. I also couldn't face the > prospect of manually changing the login user in the MUA for every account. The part I am wondering about is exactly "Dovecot accepts". As far as I know, Dovecot does not need to "accept" anything, because it does not receive mail. Programs external to Dovecot, which Dovecot knows nothing about (like Postfix) are receiving mail and delivering it directly to mailboxes accessed (also) by Dovecot, using their own mappings (virtual_mailbox_maps in case of Postfix). Dovecot itself is not involved in the process and does not need to "receive" anything. At least that's how I always used it :). Dovecot comes into play only when user logs in to IMAP account. It keeps its own mapping between login names (which do not need to be email addresses, they can be just any names) and mailboxes corresponding to these users. User logs in using some name and gets access to a particular mailbox. That's all what Dovecot does. In other words, you need a mapping email@address->mailbox in Postfix and another mapping, login_name->mailbox in Dovecot. I still see no need for aliases here. Unless you want mail for several different email addresses to be delivered to the same mailbox, in that case you would need virtual_alias_maps mapping email@address1->destination@address, email@address2->destination@address etc., and virtual_mailbox_maps mapping destination@address->mailbox. Is that your case? But this still doesn't have anything to do with Dovecot "accepting" any email addresses, because Dovecot just provides access to a mailbox. Once you properly log in, you have access to all messages stored in the mailbox, regardless of what email addresses they were sent to. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: virtual_mailbox_maps & virtual_alias_maps
Monday, February 21, 2022, 9:08:41 PM, Jaroslaw Rafa wrote: > Dnia 21.02.2022 o godz. 13:10:45 Phil Biggs pisze: >> >> - emails sent to (external) validuser@ addresses are validated >> as present in virtual_mailbox_maps >> - validuser@ addresses are translated to (internal) dovecotuser@ >> via virtual_alias_maps >> - only dovecotuser@ addresses are accepted by dovecot >> - emails originally addressed to dovecotuser@ addresses are rejected > Just asking: how do you deliver mail to Dovecot so that it needs to know and > accept any email addresses? Dovecot doesn't receive nor send mail (from what > I know), it only provides access to mailboxes. If Postfix knows to what > mailbox it should deliver the mail addressed to particular user (and that's > what should be provided by virtual_mailbox_maps), then it's only Dovecot's > thing to provide coordination between user's login and the correct mailbox. > So for me virtual_alias_maps seems completely unneccessary in your case. What > funtion exactly does it provide here? Dovecot only accepts email for addresses for which it has a matching user account. As you say, it is just used a message store. However, I wasn't able to find a way to have a dovecot user receive mail addressed to any address other than one that matched the login "user" name. I also couldn't face the prospect of manually changing the login user in the MUA for every account. The internal dovecot user accounts are more "human-readable" (e.g., ml-postfix-users@...) but the external email addresses used by those accounts are almost all of the format mbyymmdd@... (long story). virtual_mailbox_maps only validates an external address as deliverable. virtual_alias_maps rewrites the external address to the corresponding internal address that matches the dovecot user account/mailbox. -- Cheers, Phil
Re: virtual_mailbox_maps & virtual_alias_maps
Dnia 21.02.2022 o godz. 13:10:45 Phil Biggs pisze: > > - emails sent to (external) validuser@ addresses are validated > as present in virtual_mailbox_maps > - validuser@ addresses are translated to (internal) dovecotuser@ > via virtual_alias_maps > - only dovecotuser@ addresses are accepted by dovecot > - emails originally addressed to dovecotuser@ addresses are rejected Just asking: how do you deliver mail to Dovecot so that it needs to know and accept any email addresses? Dovecot doesn't receive nor send mail (from what I know), it only provides access to mailboxes. If Postfix knows to what mailbox it should deliver the mail addressed to particular user (and that's what should be provided by virtual_mailbox_maps), then it's only Dovecot's thing to provide coordination between user's login and the correct mailbox. So for me virtual_alias_maps seems completely unneccessary in your case. What funtion exactly does it provide here? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: virtual_mailbox_maps & virtual_alias_maps
Monday, February 21, 2022, 5:04:59 AM, Matus UHLAR - fantomas wrote: > On 20.02.22 18:49, Phil Biggs wrote: >>I have virtual_mailbox_maps in use with reject_unlisted_recipent and use >>virtual_alias_maps to translate a validated address into a single matching >>address for the corresponding dovecot user. > virtual_alias_maps map any address (even non-local one) to one or more > addresses: > http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual > virtual_mailbox_maps map addresses in virtual domains into pathnames where > mailboxes are located: > http://www.postfix.org/virtual.8.html > so, they have quite different usage. >> For example: >> >>/usr/local/etc/postfix/vmailbox >>validu...@example.com whatever >> >>/usr/local/etc/postfix/vuser >>validu...@example.com dovecotu...@example.com >> >>In my case, these two tables will always match on the LHS. >> >>Just wondering whether there any reason not to use the virtual_alias table for >>both purposes? It would make synchronisation with the dovecot users DB just a >>little easier. > you don't need synchronization, and you apparently don't need > virtual_alias_maps in this case. >>virtual_mailbox_maps = hash:/usr/local/etc/postfix/vuser >>virtual_alias_maps = hash:/usr/local/etc/postfix/vuser >> >>(Mail sent directly to dovecotu...@example.com should be rejected.) > you must take care of this differently. Thanks for the reply, Matus. Perhaps I didn't explain this very well. I read the linked documents many times before doing what I have and the current configuration works as I expected: - emails sent to (external) validuser@ addresses are validated as present in virtual_mailbox_maps - validuser@ addresses are translated to (internal) dovecotuser@ via virtual_alias_maps - only dovecotuser@ addresses are accepted by dovecot - emails originally addressed to dovecotuser@ addresses are rejected Perhaps this is not the intended use but it certainly works. The question was about whether there might be a problem with using the same hash table for both virtual_mailbox_maps and virtual_alias_mapps. That would mean I only need to update the virtual_alias_maps and the dovecot 'users' DB, which must be in sync. -- Cheers, Phil
Re: virtual_mailbox_maps & virtual_alias_maps
On 20.02.22 18:49, Phil Biggs wrote: I have virtual_mailbox_maps in use with reject_unlisted_recipent and use virtual_alias_maps to translate a validated address into a single matching address for the corresponding dovecot user. virtual_alias_maps map any address (even non-local one) to one or more addresses: http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual virtual_mailbox_maps map addresses in virtual domains into pathnames where mailboxes are located: http://www.postfix.org/virtual.8.html so, they have quite different usage. For example: /usr/local/etc/postfix/vmailbox validu...@example.com whatever /usr/local/etc/postfix/vuser validu...@example.com dovecotu...@example.com In my case, these two tables will always match on the LHS. Just wondering whether there any reason not to use the virtual_alias table for both purposes? It would make synchronisation with the dovecot users DB just a little easier. you don't need synchronization, and you apparently don't need virtual_alias_maps in this case. virtual_mailbox_maps = hash:/usr/local/etc/postfix/vuser virtual_alias_maps = hash:/usr/local/etc/postfix/vuser (Mail sent directly to dovecotu...@example.com should be rejected.) you must take care of this differently. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "To Boot or not to Boot, that's the question." [WD1270 Caviar]
virtual_mailbox_maps & virtual_alias_maps
I have virtual_mailbox_maps in use with reject_unlisted_recipent and use virtual_alias_maps to translate a validated address into a single matching address for the corresponding dovecot user. For example: /usr/local/etc/postfix/vmailbox validu...@example.com whatever /usr/local/etc/postfix/vuser validu...@example.com dovecotu...@example.com In my case, these two tables will always match on the LHS. Just wondering whether there any reason not to use the virtual_alias table for both purposes? It would make synchronisation with the dovecot users DB just a little easier. virtual_mailbox_maps = hash:/usr/local/etc/postfix/vuser virtual_alias_maps = hash:/usr/local/etc/postfix/vuser (Mail sent directly to dovecotu...@example.com should be rejected.) -- Many thanks, Phil
Re: recipient_delimiter and virtual_alias_maps
On 31.07.21 20:55, Wietse Venema wrote: > Please also provide output from > > postconf -P There is only syslog and submission stuff in postconf -P. The true problem seems to have been that I didn't delete the verify_cache.db after changing the virtual alias map. - Florian.
Re: recipient_delimiter and virtual_alias_maps
Please also provide output from postconf -P I suspect that you have virtual alias mapping disabled in some message delivery path (with receive_override_options = no_address_mappings). Wietse
recipient_delimiter and virtual_alias_maps
Hi,
I am currently slightly confused by the interaction between
recipient_delimiter and virtual_alias_maps. I have a test setup with
recipient_delimiter = +
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_transport = lmtp:unix:private/dovecot-lmtp
a virtual domain "domain" and an alias
alias@domain real@domain
and I reject_unverified_recipients
The strange thing is:
If postfix receives a mail for real@domain, it delivers it to dovecot
user real@domain.
If postfix receives a mail for real+foo@domain, it delivers it to
dovecot user real@domain.
If postfix receives a mail for alias@domain, it delivers it to dovecot
user real@domain.
If postfix receives a mail for alias+foo@domain, recipient verification
fails with: [private/dovecot-lmtp] said: 550 5.1.1
User doesn't exist: alias@domain (in reply to RCPT TO command).
Is the last one expected behavior?
This is with the debian buster version 3.4.14-0+deb10u1 of postfix.
Regard, Florian.
# postconf -n # sorry for stupid thunderbird linebreaks
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
delay_warning_time = 2h
inet_interfaces = all
inet_protocols = all
luser_relay = florian
mailbox_size_limit = 0
message_size_limit = 5000
milter_connect_macros = j {daemon_name} v {if_name} _
mydestination = mail, mail.domain, localhost
myhostname = mail.domain
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_address_preference = ipv4
smtp_body_checks = pcre:/etc/postfix/smtp_body_checks
smtp_sasl_type = dovecot
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_cert_file = /etc/ssl/certs/server.pem
smtp_tls_key_file = /etc/ssl/private/server.key
smtp_tls_loglevel = 2
smtp_tls_security_level = encrypt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname
smtpd_milters = unix:spamass/spamass.sock
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_unknown_helo_hostname, reject_unknown_reverse_client_hostname,
reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org,
reject_rhsbl_reverse_client dbl.spamhaus.org, reject_rhsbl_helo
dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org,
reject_unverified_recipient
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_cert_file = /etc/ssl/certs/server.pem
smtpd_tls_key_file = /etc/ssl/private/server.key
smtpd_tls_loglevel = 2
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_domains = domain domain2
virtual_mailbox_limit = 0
virtual_transport = lmtp:unix:private/dovecot-lmtp
Re: per domain ldap virtual_alias_maps
On 04/06/2021 12:10, Viktor Dukhovni wrote: > On Fri, Jun 04, 2021 at 10:53:25AM +0300, Kapetanakis Giannis wrote: > >> I want to separate the ldap configuration to be different per domain. >> I was thinking something like this, but this recursion does not work: >> >> The reason is that the ldap search_base might be different per domain (no >> common parent) and sometimes on a different ldap server. >> >> Is this somehow possible? > > For a modest number of such domains, the solution is: > > proxy:ldap:domain1.cf, proxy:ldap:domain2.cf, ..., proxy:ldap:domainN.cf > > where "domain.cf" contains: > > domain = domain.example > server = ... > search_base = ... > query = ... > > As documented, the "domain = " setting will efficiently locally limit > queries to just the domain in question, without contacting the > underlying server. See: > > http://www.postfix.org/ldap_table.5.html > > Note also that the search base supports "%[1-9]" and "%d" substitution > strings, so if the server pool is common, and the search base is > uniformly constructed from the domain names, you can use a single > table with a domain-dependent search base to support multiple similar > domains. > > Note, queries must then all be of the form "localpart@domain.example". > Queries for inputs that are just a domain part (or just a user name) > will be ignored. > That's it !!! I saw the domain setting while reading ldap_table(5) but I probably need a 2nd coffee :) I use search_base substitutions for domains on same server but now I now want to use a different server. thanks, I'll try the domain limit. G
Re: per domain ldap virtual_alias_maps
On Fri, Jun 04, 2021 at 10:53:25AM +0300, Kapetanakis Giannis wrote: > I want to separate the ldap configuration to be different per domain. > I was thinking something like this, but this recursion does not work: > > The reason is that the ldap search_base might be different per domain (no > common parent) and sometimes on a different ldap server. > > Is this somehow possible? For a modest number of such domains, the solution is: proxy:ldap:domain1.cf, proxy:ldap:domain2.cf, ..., proxy:ldap:domainN.cf where "domain.cf" contains: domain = domain.example server = ... search_base = ... query = ... As documented, the "domain = " setting will efficiently locally limit queries to just the domain in question, without contacting the underlying server. See: http://www.postfix.org/ldap_table.5.html Note also that the search base supports "%[1-9]" and "%d" substitution strings, so if the server pool is common, and the search base is uniformly constructed from the domain names, you can use a single table with a domain-dependent search base to support multiple similar domains. Note, queries must then all be of the form "localpart@domain.example". Queries for inputs that are just a domain part (or just a user name) will be ignored. -- Viktor.
per domain ldap virtual_alias_maps
Hi, My virtual_alias_maps looks like this: virtual_alias_maps = hash:/etc/postfix/virtual, ldap:/etc/postfix/ldap-aliases.cf I want to separate the ldap configuration to be different per domain. I was thinking something like this, but this recursion does not work: virtual_alias_maps = hash:/etc/postfix/virtual, hash:/etc/postfix/ldap_virtual_maps where ldap_virtual_maps is like @example1.com ldap:/etc/postfix/example1_aliases.cf @example2.com ldap:/etc/postfix/example2_aliases.cf The reason is that the ldap search_base might be different per domain (no common parent) and sometimes on a different ldap server. Is this somehow possible? regards, Giannis ps. the documentation on http://www.postfix.org/postconf.5.html#virtual_alias_maps says: Note: these lookups are recursive. This is where I got the idea, but I'm not sure what is means.
Re: virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)
On 18.01.21 12:45, Daniel Caillibaud wrote: >After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems to be ignored >(mail to aliases address are bounced with "user unknown"), and I don't find why… Le 18/01/21 à 13:13, Matus UHLAR - fantomas a écrit : you turned on: >receive_override_options = no_address_mappings and while amavisd worked as post-queue filter, thus received mail and sent back through port 10024 where virtual aliases were xpanded, rspamd workd as milter, thus does not send back to postfix. On 18.01.21 14:52, Daniel Caillibaud wrote: Thanks a lot for pointing this out ! (it was necessary with amavis to avoid double mail on aliases, no mapping before amavis and receive_override_options=no_unknown_recipient_checks,no_header_body_checks precised in master cf for the 2nd treatment by postfix on the way back) I use it on port 10024. That way, amavis knows real recipients. Also, I use amavisd-milter on mail received on port 25. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows."
Re: virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)
Le 18/01/21 à 13:13, Matus UHLAR - fantomas a écrit : > On 18.01.21 12:45, Daniel Caillibaud wrote: > >After switching to rspamd (was amavis+spamassassin), virtual_alias_maps > >seems to be ignored > >(mail to aliases address are bounced with "user unknown"), and I don't find > >why… > > you turned on: > >receive_override_options = no_address_mappings > > and while amavisd worked as post-queue filter, thus received mail and sent > back through port 10024 where virtual aliases were xpanded, rspamd workd as > milter, > thus does not send back to postfix. Thanks a lot for pointing this out ! (it was necessary with amavis to avoid double mail on aliases, no mapping before amavis and receive_override_options=no_unknown_recipient_checks,no_header_body_checks precised in master cf for the 2nd treatment by postfix on the way back) -- Daniel Le café est un breuvage qui fait dormir, quand on n'en prend pas. Alphonse Allais
Re: virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)
On 18.01.21 12:45, Daniel Caillibaud wrote:
After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems
to be ignored
(mail to aliases address are bounced with "user unknown"), and I don't find why…
you turned on:
receive_override_options = no_address_mappings
and while amavisd worked as post-queue filter, thus received mail and sent
back through port 10024 where virtual aliases were xpanded, rspamd workd as
milter,
thus does not send back to postfix.
1) Before (all is fine with virtual_alias_maps)
content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 3
smtpd_milters =
unix:run/opendkim/opendkim.sock,unix:run/opendmarc/opendmarc.sock
non_smtpd_milters = $smtpd_milters
milter_connect_macros = j
2) after (virtual_alias_maps ignored)
# content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 6
milter_default_action = tempfail
smtpd_milters = inet:localhost:11332
non_smtpd_milters = $smtpd_milters
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
Here is a log of a mail ok with 1)
postfix/pickup[25504]: 18D8F222ED4: uid=0 from=
postfix/cleanup[27187]: 18D8F222ED4:
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
opendkim[5572]: 18D8F222ED4: DKIM-Signature field added (s=mail, d=sesamath.net)
postfix/qmgr[25505]: 18D8F222ED4: from=, size=654, nrcpt=1
(queue active)
postfix/smtpd[27196]: 4822622194E: client=localhost[127.0.0.1]
postfix/cleanup[27187]: 4822622194E:
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
postfix/qmgr[25505]: 4822622194E: from=, size=1483,
nrcpt=1 (queue active)
amavis[20707]: (20707-14) Passed CLEAN {RelayedInbound}, [127.0.0.1]
-> , Message-ID:
<20210118105545.18d8f222...@mail.sesamath.net>, mail_id: kvP9WKxhumWJ, Hits: -1.791, size:
988, queued_as: 4822622194E, 211 ms
postfix/smtp[27192]: 18D8F222ED4: to=, orig_to=,
relay=127.0.0.1[127.0.0.1]:10024, delay=0.28, delays=0.07/0/0/0.21, dsn=2.0.0, status=sent
(250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4822622194E)
postfix/qmgr[25505]: 18D8F222ED4: removed
postfix/pipe[27197]: 4822622194E: to=,
orig_to=, relay=dovecot, delay=0.15, delays=0.03/0/0/0.12,
dsn=2.0.0, status=sent (delivered via dovecot service)
postfix/qmgr[25505]: 4822622194E: removed
and the same test ko with 2)
postfix/pickup[24882]: 6DD04222ED4: uid=0 from=
postfix/cleanup[24914]: 6DD04222ED4:
message-id=<20210118103925.6dd04222...@mail.sesamath.net>
postfix/qmgr[24883]: 6DD04222ED4: from=, size=383, nrcpt=1
(queue active)
postfix/pipe[24920]: 6DD04222ED4: to=, orig_to=,
relay=dovecot, delay=0.14, delays=0.09/0.01/0/0.05, dsn=5.1.1, status=bounced (user unknown)
postfix/bounce[24922]: 6DD04222ED4: sender non-delivery notification:
87950222EDA
postfix/qmgr[24883]: 6DD04222ED4: removed
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I intend to live forever - so far so good.
virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)
Hi,
After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems
to be ignored
(mail to aliases address are bounced with "user unknown"), and I don't find why…
1) Before (all is fine with virtual_alias_maps)
content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 3
smtpd_milters =
unix:run/opendkim/opendkim.sock,unix:run/opendmarc/opendmarc.sock
non_smtpd_milters = $smtpd_milters
milter_connect_macros = j
2) after (virtual_alias_maps ignored)
# content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 6
milter_default_action = tempfail
smtpd_milters = inet:localhost:11332
non_smtpd_milters = $smtpd_milters
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
All others lines are identicals, especially
virtual_alias_maps =
mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-sympa-virtual_alias_maps.cf
Any clue ?
Thanks
Here is a log of a mail ok with 1)
postfix/pickup[25504]: 18D8F222ED4: uid=0 from=
postfix/cleanup[27187]: 18D8F222ED4:
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
opendkim[5572]: 18D8F222ED4: DKIM-Signature field added (s=mail, d=sesamath.net)
postfix/qmgr[25505]: 18D8F222ED4: from=, size=654, nrcpt=1
(queue active)
postfix/smtpd[27196]: 4822622194E: client=localhost[127.0.0.1]
postfix/cleanup[27187]: 4822622194E:
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
postfix/qmgr[25505]: 4822622194E: from=, size=1483,
nrcpt=1 (queue active)
amavis[20707]: (20707-14) Passed CLEAN {RelayedInbound}, [127.0.0.1]
-> , Message-ID:
<20210118105545.18d8f222...@mail.sesamath.net>, mail_id: kvP9WKxhumWJ, Hits:
-1.791, size: 988, queued_as: 4822622194E, 211 ms
postfix/smtp[27192]: 18D8F222ED4: to=, orig_to=,
relay=127.0.0.1[127.0.0.1]:10024, delay=0.28, delays=0.07/0/0/0.21, dsn=2.0.0,
status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued
as 4822622194E)
postfix/qmgr[25505]: 18D8F222ED4: removed
postfix/pipe[27197]: 4822622194E: to=,
orig_to=, relay=dovecot, delay=0.15,
delays=0.03/0/0/0.12, dsn=2.0.0, status=sent (delivered via dovecot service)
postfix/qmgr[25505]: 4822622194E: removed
and the same test ko with 2)
postfix/pickup[24882]: 6DD04222ED4: uid=0 from=
postfix/cleanup[24914]: 6DD04222ED4:
message-id=<20210118103925.6dd04222...@mail.sesamath.net>
postfix/qmgr[24883]: 6DD04222ED4: from=, size=383, nrcpt=1
(queue active)
postfix/pipe[24920]: 6DD04222ED4: to=, orig_to=,
relay=dovecot, delay=0.14, delays=0.09/0.01/0/0.05, dsn=5.1.1, status=bounced
(user unknown)
postfix/bounce[24922]: 6DD04222ED4: sender non-delivery notification:
87950222EDA
postfix/qmgr[24883]: 6DD04222ED4: removed
Just in case, the full postconf -n
1)
alias_maps = hash:/etc/aliases
anvil_rate_time_unit = 60s
append_dot_mydomain = no
biff = no
bounce_template_file = /etc/postfix/bounce_templates.cf
broken_sasl_auth_clients = yes
compatibility_level = 2
content_filter = amavis:[127.0.0.1]:10024
default_destination_concurrency_limit = 5
default_destination_rate_delay = 1s
default_destination_recipient_limit = 30
delay_warning_time = 1h
dovecot_destination_recipient_limit = 1
header_checks = pcre:/etc/postfix/header_checks.pcre
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
laposte_destination_concurrency_limit = 1
laposte_destination_rate_delay = 1s
laposte_destination_recipient_limit = 1
milter_connect_macros = j
milter_protocol = 3
mydestination = $myhostname
mydomain = sesamath.net
myhostname = mail.sesamath.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.0.0/16
mynetworks_style = subnet
myorigin = $mydomain
non_smtpd_milters = $smtpd_milters
readme_directory = /usr/share/doc/postfix
receive_override_options = no_address_mappings
recipient_delimiter = _
relay_domains = $mydestination
relayhost =
sender_dependent_relayhost_maps =
regexp:/etc/postfix/sender_dependent_relayhost_maps.regexp
slow_destination_concurrency_limit = 2
slow_destination_recipient_limit = 5
smtp_generic_maps = hash:/etc/postfix/smtp_generic_maps.hash
smtp_tls_fingerprint_digest = sha256
smtp_tls_loglevel = 2
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 30
smtpd_client_recipient_rate_limit = 30
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
reject_unknown_reverse_client_hostname reject_unknown_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_milters =
unix:run/opendkim/opendkim.sock,unix:run/opendmarc/opendmarc.sock
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated
reject_unauth_destination reject_unknown_recipient_domain
reject_non_fqdn_recipient reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client psbl.surriel.com check
Re: virtual_alias_maps with both: regexp and mysql
> Am 09.01.2021 um 13:25 schrieb Leonardo Rodrigues : > > Em 09/01/2021 06:25, Frank Röhm escreveu: >> I would put then: >> >> /^.*@mydomain.tld$/ fr...@mydomain.tld >> >> Would that be correct? >> I don’t want to just test it, it is a productive mailserver. >> >> > > Never actually tried it, bur first thing that cames to my mind is "why > not let MySQL solve the regexp itself, instead of postfix"? > > https://dev.mysql.com/doc/refman/8.0/en/regexp.html > What is the advantage? And how would be my setting then? Another table?
Re: virtual_alias_maps with both: regexp and mysql
Em 09/01/2021 06:25, Frank Röhm escreveu: I would put then: /^.*@mydomain.tld$/ fr...@mydomain.tld Would that be correct? I don’t want to just test it, it is a productive mailserver. Never actually tried it, bur first thing that cames to my mind is "why not let MySQL solve the regexp itself, instead of postfix"? https://dev.mysql.com/doc/refman/8.0/en/regexp.html -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it
virtual_alias_maps with both: regexp and mysql
Hallo I wonder if I could add a regexp rule to my virtual_alias_maps so I could realize wildcard addresses, like: somew...@mydomain.tld > fr...@mydomain.tld At the moment I have: virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf and with RegEx I would write: virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf,regexp:/etc/postfix/aliases_regex.cf as I can read in: https://superuser.com/questions/353488/regex-multiple-catch-all-setup-in-postfix In: /etc/postfix/aliases_regex.cf I would put then: /^.*@mydomain.tld$/ fr...@mydomain.tld Would that be correct? I don’t want to just test it, it is a productive mailserver. Thanks, frank — My postfix config files: /etc/postfix/mysql-virtual-alias-maps.cf user = myuser password = mypassword hosts = 127.0.0.1 dbname = mymailserverdb query = SELECT destination FROM view_aliases WHERE email='%s' /etc/postfix/mysql-email2email.cf user = myuser password = mypassword hosts = 127.0.0.1 dbname = mymailserverdb query = SELECT email FROM view_users WHERE email='%s' Postfix Version: 3.3.0-1ubuntu0.3 on Ubuntu 18.04.05 LTS
Re: virtual_alias_maps doesn't require domains to be in virtual_alias_domains
Fred Morris: > With postfix 3.3.1 it appears that mappings in virtual_alias_maps are > honored without the domains being listed in virtual_alias_domains. Just > want to confirm that this is correct and intended behavior going forward. The first sendence in the manpage says: The optional virtual(5) alias table rewrites recipient addresses for all local, all virtual, and all remote mail destinations. Secrets from Postfix documentation unleashed. Wietse
virtual_alias_maps doesn't require domains to be in virtual_alias_domains
With postfix 3.3.1 it appears that mappings in virtual_alias_maps are honored without the domains being listed in virtual_alias_domains. Just want to confirm that this is correct and intended behavior going forward. Thanks in advance... -- Fred Morris
Re: Delivering to virtual_alias_maps only?
On Sat, Oct 10, 2020 at 05:15:37PM +0200, Marek Kozlowski wrote:
> Is it possible to accept mail if the recipients address is found in
> virtual_alias_maps and reject in all other cases? Let's imagine I have
> two entries for virtual_alias_maps:
Following http://www.postfix.org/MULTI_INSTANCE_README.html#quick
mydestination =
local_transport = error:5.1.1 Mailbox unavailable
alias_database =
alias_maps =
local_recipient_maps =
Then:
indexed = ${default_database_type}:${config_directory}/
myorigin = example.com
virtual_mailbox_domains = example.com, example.net, ...
# You could instead use LMTP to deliver to Dovecot's or similar
# LMTP server. In this case, virtual_mailbox_maps RHS value is
# not significant, any non-empty value indicates a valid user.
# Also in the same case, the uid and gid maps are not used.
#
virtual_transport = virtual
virtual_mailbox_maps = ${indexed}vmbox
# Set uid/gid to IMAP server account
virtual_mailbox_uid_maps = static:12345
virtual_mailbox_gid_maps = static:12345
Tables:
vmbox:
# Set path layout to match IMAP server configuration
us...@example.com /var/spool/virtual/example.com/user1/
us...@example.net /var/spool/virtual/example.net/user2/
You could of course add an intermediate mapping via virtual(5), and have
just a single virtual mailbox domain, with the various domains in
virtual alias domains, and something "virtual.invalid" as the mailbox
domain, but it is not clear that the indirection is needed in your
case.
--
Viktor.
Re: Delivering to virtual_alias_maps only?
Wietse Venema: > Marek Kozlowski: > > :-) > > > > Must be simple... but I missed it. > > The answer is in http://www.postfix.org/ADDRESS_CLASS_README.html. > > If you don't want to receive and deliver email for the local class, > set local_recipient_maps to empty, or set the local_transport to > "error:email to this domain is not permitted". Note: this means you can't have virtual aliases that have a 'local' recipient on the right-hand side. Wietse > Ditto for other classes: the relay class or the virtual class. > > Wietse >
Re: Delivering to virtual_alias_maps only?
Marek Kozlowski: > :-) > > Must be simple... but I missed it. The answer is in http://www.postfix.org/ADDRESS_CLASS_README.html. If you don't want to receive and deliver email for the local class, set local_recipient_maps to empty, or set the local_transport to "error:email to this domain is not permitted". Ditto for other classes: the relay class or the virtual class. Wietse
Delivering to virtual_alias_maps only?
:-) Must be simple... but I missed it. I asked for it in the context on LDAP but I think I may simplify my question: Is it possible to accept mail if the recipients address is found in virtual_alias_maps and reject in all other cases? Let's imagine I have two entries for virtual_alias_maps: smi...@one.of.my.domainssmithj jonesj@my.other.domain jonesj and I have local users: smithj and jonesj. I'd like emails to smi...@one.of.my.domains jonesj@my.other.domain to be delivered but emails to: jon...@one.of.my.domains smithj@my.other.domain to be rejected. Unfortunately if an email is originating from my system it is delivered in all cases :-( Best regards, Marek smime.p7s Description: S/MIME Cryptographic Signature
Re: PostgreSQL virtual_mailbox_domain lookups fail, but virtual_alias_maps work just fine, help?
David Reagan: > Thanks. Switching the query to the default '%s' and making sure I didn't > have 'result_format' set fixed it. The postmap query works. > > Is the fact that %d won't work in this context documented anywhere? I > didn't see anything in http://www.postfix.org/pgsql_table.5.html or any > of the other docs I was reading. The query is a domain NOT AN EMAIL ADDRESS: http://www.postfix.org/postconf.5.html#virtual_mailbox_domains Quote: This parameter expects the same syntax as the mydestination configuration parameter. The %d requires AN EMAIL ADDRESS: http://www.postfix.org/pgsql_table.5.html Quote: When the input key is an address of the form user@domain, %d is replaced by the SQL quoted domain part of the address. Otherwise, the query is suppressed and returns no results. wietse > - David > > On 8/8/20 7:48 PM, Viktor Dukhovni wrote: > > On Sat, Aug 08, 2020 at 06:42:16PM -0700, David Reagan wrote: > > > >> By key you mean use 'raygun.zat' instead of 'k...@raygun.zat'? > > The former is the lookup key that Postfix asks the lookup table to find. > > > >> Also, if you look at the query, I use '%d'. So, unless I'm > >> misunderstanding the docs, postfix will replace that with 'raygun.zat' > >> even if it gets 'k...@raygun.zat'. > > That's your mistake. You can ONLY use %d with tables whose lookup keys > > are email addresses (localpart@domain). When the lookup key is already > > just the domain, the %d expansion will not find any domain, and will > > skip the lookup. > > > > You're confused about the layering. The table driver interprets %d, > > but the virtual_mailbox_domains feature uses domain-only keys. > > >
Re: PostgreSQL virtual_mailbox_domain lookups fail, but virtual_alias_maps work just fine, help?
Thanks. Switching the query to the default '%s' and making sure I didn't have 'result_format' set fixed it. The postmap query works. Is the fact that %d won't work in this context documented anywhere? I didn't see anything in http://www.postfix.org/pgsql_table.5.html or any of the other docs I was reading. - David On 8/8/20 7:48 PM, Viktor Dukhovni wrote: On Sat, Aug 08, 2020 at 06:42:16PM -0700, David Reagan wrote: By key you mean use 'raygun.zat' instead of 'k...@raygun.zat'? The former is the lookup key that Postfix asks the lookup table to find. Also, if you look at the query, I use '%d'. So, unless I'm misunderstanding the docs, postfix will replace that with 'raygun.zat' even if it gets 'k...@raygun.zat'. That's your mistake. You can ONLY use %d with tables whose lookup keys are email addresses (localpart@domain). When the lookup key is already just the domain, the %d expansion will not find any domain, and will skip the lookup. You're confused about the layering. The table driver interprets %d, but the virtual_mailbox_domains feature uses domain-only keys.
Re: PostgreSQL virtual_mailbox_domain lookups fail, but virtual_alias_maps work just fine, help?
On Sat, Aug 08, 2020 at 06:42:16PM -0700, David Reagan wrote: > By key you mean use 'raygun.zat' instead of 'k...@raygun.zat'? The former is the lookup key that Postfix asks the lookup table to find. > Also, if you look at the query, I use '%d'. So, unless I'm > misunderstanding the docs, postfix will replace that with 'raygun.zat' > even if it gets 'k...@raygun.zat'. That's your mistake. You can ONLY use %d with tables whose lookup keys are email addresses (localpart@domain). When the lookup key is already just the domain, the %d expansion will not find any domain, and will skip the lookup. You're confused about the layering. The table driver interprets %d, but the virtual_mailbox_domains feature uses domain-only keys. -- Viktor.
Re: PostgreSQL virtual_mailbox_domain lookups fail, but virtual_alias_maps work just fine, help?
Thanks for the response. By key you mean use 'raygun.zat' instead of 'k...@raygun.zat'? I did try that. The output that gave was the same, just no 'postmap: dict_pgsql_lookup: retrieved 1 rows' line. Also, if you look at the query, I use '%d'. So, unless I'm misunderstanding the docs, postfix will replace that with 'raygun.zat' even if it gets 'k...@raygun.zat'. - David On 8/8/20 3:54 PM, Noel Jones wrote: On 8/8/2020 1:52 PM, David Reagan wrote: Hey all, I'm working on configuring a mailserver that uses a PostgreSQL database for virtual information. The database is managed by Vimbadmin. I think I've found at least part of the problem. The virtual_mailbox_domains setting likely isn't getting the correct output when it is checking for an authorized domain. I say that because when I run postmap -q on the alias file, it returns 1. Not 0. == root@32cdc5546306:/# postmap -vq 'k...@raygun.zat' pgsql:/run/secrets/postfix_db_virt_domains_maps 2>&1 That's the wrong key. virtual_mailbox_domains uses the domain for the key. raygun.zat in this example. http://www.postfix.org/postconf.5.html#virtual_mailbox_domains Verbose output is rarely needed with postfix, the regular command gives you all the info you need to debug the vast majority of problems. -- Noel Jones
Re: PostgreSQL virtual_mailbox_domain lookups fail, but virtual_alias_maps work just fine, help?
On 8/8/2020 1:52 PM, David Reagan wrote: Hey all, I'm working on configuring a mailserver that uses a PostgreSQL database for virtual information. The database is managed by Vimbadmin. I think I've found at least part of the problem. The virtual_mailbox_domains setting likely isn't getting the correct output when it is checking for an authorized domain. I say that because when I run postmap -q on the alias file, it returns 1. Not 0. == root@32cdc5546306:/# postmap -vq 'k...@raygun.zat' pgsql:/run/secrets/postfix_db_virt_domains_maps 2>&1 That's the wrong key. virtual_mailbox_domains uses the domain for the key. raygun.zat in this example. http://www.postfix.org/postconf.5.html#virtual_mailbox_domains Verbose output is rarely needed with postfix, the regular command gives you all the info you need to debug the vast majority of problems. -- Noel Jones
PostgreSQL virtual_mailbox_domain lookups fail, but virtual_alias_maps work just fine, help?
Hey all, I'm working on configuring a mailserver that uses a PostgreSQL database for virtual information. The database is managed by Vimbadmin. I think I've found at least part of the problem. The virtual_mailbox_domains setting likely isn't getting the correct output when it is checking for an authorized domain. I say that because when I run postmap -q on the alias file, it returns 1. Not 0. == root@32cdc5546306:/# postmap -vq 'k...@raygun.zat' pgsql:/run/secrets/postfix_db_virt_domains_maps 2>&1 postmap: name_mask: all postmap: name_mask: host postmap: inet_addr_local: configured 3 IPv4 addresses postmap: inet_addr_local: configured 0 IPv6 addresses postmap: been_here: 127.0.0.1/32: 0 postmap: been_here: 192.168.112.4/32: 0 postmap: been_here: 192.168.111.11/32: 0 postmap: mynetworks_core: 127.0.0.1/32 192.168.112.4/32 192.168.111.11/32 postmap: cfg_get_str: /run/secrets/postfix_db_virt_domains_maps: user = vimbadmin_user postmap: cfg_get_str: /run/secrets/postfix_db_virt_domains_maps: password = password postmap: cfg_get_str: /run/secrets/postfix_db_virt_domains_maps: dbname = vimbadmin postmap: cfg_get_str: /run/secrets/postfix_db_virt_domains_maps: result_format = %d postmap: cfg_get_int: /run/secrets/postfix_db_virt_domains_maps: expansion_limit = 0 postmap: cfg_get_str: /run/secrets/postfix_db_virt_domains_maps: query = SELECT domain FROM domain WHERE domain = '%d' AND backupmx = false AND active = true; postmap: cfg_get_str: /run/secrets/postfix_db_virt_domains_maps: domain = postmap: cfg_get_str: /run/secrets/postfix_db_virt_domains_maps: hosts = vimbadmin-db-pgsql:5432 postmap: dict_open: pgsql:/run/secrets/postfix_db_virt_domains_maps postmap: dict_pgsql_get_active: attempting to connect to host vimbadmin-db-pgsql:5432 postmap: dict_pgsql: successful connection to host vimbadmin-db-pgsql:5432 postmap: dict_pgsql: successful query from host vimbadmin-db-pgsql:5432 postmap: dict_pgsql_lookup: retrieved 1 rows root@32cdc5546306:/# echo $? 1 = In main.cf: virtual_mailbox_domains = pgsql:/run/secrets/postfix_db_virt_domains_maps The /run/secrets/postfix_db_virt_domains_maps file: = user = vimbadmin_user hosts = vimbadmin-db-pgsql:5432 dbname = vimbadmin query = SELECT domain FROM domain WHERE domain = '%d' AND backupmx = false AND active = true; password = password result_format = %d If I run the query against the database directly, it returns the 'domain' column with a value of 'raygun.zat'. SELECT domain FROM domain WHERE domain = 'raygun.zat' AND backupmx = false AND active = true To further complicate matters, the virtual_alias_maps command works just fine. root@32cdc5546306:/# postmap -vq 'k...@raygun.zat' pgsql:/run/secrets/postfix_db_virt_alias_maps 2>&1 postmap: name_mask: all postmap: name_mask: host postmap: inet_addr_local: configured 3 IPv4 addresses postmap: inet_addr_local: configured 0 IPv6 addresses postmap: been_here: 127.0.0.1/32: 0 postmap: been_here: 192.168.112.4/32: 0 postmap: been_here: 192.168.111.11/32: 0 postmap: mynetworks_core: 127.0.0.1/32 192.168.112.4/32 192.168.111.11/32 postmap: cfg_get_str: /run/secrets/postfix_db_virt_alias_maps: user = vimbadmin_user postmap: cfg_get_str: /run/secrets/postfix_db_virt_alias_maps: password = password postmap: cfg_get_str: /run/secrets/postfix_db_virt_alias_maps: dbname = vimbadmin postmap: cfg_get_str: /run/secrets/postfix_db_virt_alias_maps: result_format = %s postmap: cfg_get_int: /run/secrets/postfix_db_virt_alias_maps: expansion_limit = 0 postmap: cfg_get_str: /run/secrets/postfix_db_virt_alias_maps: query = SELECT goto FROM alias WHERE address = '%s' AND active = true postmap: cfg_get_str: /run/secrets/postfix_db_virt_alias_maps: domain = postmap: cfg_get_str: /run/secrets/postfix_db_virt_alias_maps: hosts = vimbadmin-db-pgsql:5432 postmap: dict_open: pgsql:/run/secrets/postfix_db_virt_alias_maps postmap: dict_pgsql_get_active: attempting to connect to host vimbadmin-db-pgsql:5432 postmap: dict_pgsql: successful connection to host vimbadmin-db-pgsql:5432 postmap: dict_pgsql: successful query from host vimbadmin-db-pgsql:5432 postmap: dict_pgsql_lookup: retrieved 1 rows k...@raygun.zat root@32cdc5546306:/# echo $? 0 Here is that file /run/secrets/postfix_db_virt_alias_maps; === user = vimbadmin_user hosts = vimbadmin-db-pgsql:5432 dbname = vimbadmin query = SELECT goto FROM alias WHERE address = '%s' AND active = true password = password System info: Ubuntu 20.04 and postfix from their repos. I am running postfix and dovecot together in a Docker container. Postgres is in another container. Since the virtual_alias_maps work, I'm 99% certain it isn't something odd with Docker networking. Oh, and I also am running bind in another container so I can test dns changes more easily. I can lookup the mx record for raygun.zat from inside the p
Re: content_filter with external script and virtual_alias_maps
On Wed, Jul 8, 2020 at 4:18 PM Viktor Dukhovni wrote: > > On Wed, Jul 08, 2020 at 04:12:24PM -0700, Stats Student wrote: > > > Let me know if what I am asking isn't clear and I'll be happy to > > provide further details. I did post all of my configuration last week > > but can include it in the email, if that's the preferred method. > > This list is no substitute for a basic working knowledge of system > administration, and a working knowledge of the Postfix architecture as > described in the No Starch or O'Reilly books. > > You can get answers to specific focused questions here, but likely not > extensive hand-holding to produce a working configuration if you're > unfamiliar with the basics. > > -- > Viktor. So you know, I bought the O'Reilly book 18 years ago, used it for 10 years, then donated it to a library. I don't think what I am asking is "basic", but then again I don't configure Postfix every day. Regards.
Re: content_filter with external script and virtual_alias_maps
On Wed, Jul 08, 2020 at 04:12:24PM -0700, Stats Student wrote: > Let me know if what I am asking isn't clear and I'll be happy to > provide further details. I did post all of my configuration last week > but can include it in the email, if that's the preferred method. This list is no substitute for a basic working knowledge of system administration, and a working knowledge of the Postfix architecture as described in the No Starch or O'Reilly books. You can get answers to specific focused questions here, but likely not extensive hand-holding to produce a working configuration if you're unfamiliar with the basics. -- Viktor.
Re: content_filter with external script and virtual_alias_maps
> > > > I don't use transport_maps currently so it's unclear to me how this > > would work with the existing setup which I assume already uses the > > virtual delivery agent with virtual_transport. Can you please show an > > example of the transport_maps with two routes? > > In that case you already have maildir delivery, no transport map > needed as long as foo.maildir has an entry in virtual_*_maps, and > virtual_mailbox_maps for foo.maildir returns a pathname ending in > '/'. I don't have Maildir delivery, the virtual_transport points to a custom defined delivery agent with pipe which executes a script (which you suggested at the beginning of this exchange) and that works fine. What I need is an additional "route" that would send the message to Maildir *in addition* to the pipe/script. I am guessing this is done through transport_maps but as I said before, I don't know how. Let me know if what I am asking isn't clear and I'll be happy to provide further details. I did post all of my configuration last week but can include it in the email, if that's the preferred method.
Re: content_filter with external script and virtual_alias_maps
Stats Student: > On Wed, Jul 8, 2020 at 1:10 PM Wietse Venema wrote: > > > > Stats Student: > > > > Again, an email address IS NOT an account. > > > > > > > > > > Ok, understood. > > > > > > > If it helps to rephrase the example: > > > > > > > > Prerequisites: > > > > foo@example delivers to script > > > > foo.maildir@example delivers to maildir > > > > > > I don't know how to satisfy the last prerequisite. Can you help? > > > > There are so many ways. One is to use transport_maps to route > > foo.maildir@example to the virtual delivery agent, and then configure > > virtual_uid_maps, virtual_gid_maps, and virtual_mailbox_maps. > > I don't use transport_maps currently so it's unclear to me how this > would work with the existing setup which I assume already uses the > virtual delivery agent with virtual_transport. Can you please show an > example of the transport_maps with two routes? In that case you already have maildir delivery, no transport map needed as long as foo.maildir has an entry in virtual_*_maps, and virtual_mailbox_maps for foo.maildir returns a pathname ending in '/'. Wietse
Re: content_filter with external script and virtual_alias_maps
On Wed, Jul 8, 2020 at 1:10 PM Wietse Venema wrote: > > Stats Student: > > > Again, an email address IS NOT an account. > > > > > > > Ok, understood. > > > > > If it helps to rephrase the example: > > > > > > Prerequisites: > > > foo@example delivers to script > > > foo.maildir@example delivers to maildir > > > > I don't know how to satisfy the last prerequisite. Can you help? > > There are so many ways. One is to use transport_maps to route > foo.maildir@example to the virtual delivery agent, and then configure > virtual_uid_maps, virtual_gid_maps, and virtual_mailbox_maps. I don't use transport_maps currently so it's unclear to me how this would work with the existing setup which I assume already uses the virtual delivery agent with virtual_transport. Can you please show an example of the transport_maps with two routes?
Re: content_filter with external script and virtual_alias_maps
Stats Student: > > Again, an email address IS NOT an account. > > > > Ok, understood. > > > If it helps to rephrase the example: > > > > Prerequisites: > > foo@example delivers to script > > foo.maildir@example delivers to maildir > > I don't know how to satisfy the last prerequisite. Can you help? There are so many ways. One is to use transport_maps to route foo.maildir@example to the virtual delivery agent, and then configure virtual_uid_maps, virtual_gid_maps, and virtual_mailbox_maps. > Currently have the following configuration - > > virtual_mailbox_maps = pgsql:/etc/postfix/pgsql_virtual_mailbox_maps.cf The result must be a pathname that ends in '/'. That is what enables maildir delivery. You can test that with the postmap command. Wietse
Re: content_filter with external script and virtual_alias_maps
> Again, an email address IS NOT an account. > Ok, understood. > If it helps to rephrase the example: > > Prerequisites: > foo@example delivers to script > foo.maildir@example delivers to maildir I don't know how to satisfy the last prerequisite. Can you help? Currently have the following configuration - virtual_mailbox_maps = pgsql:/etc/postfix/pgsql_virtual_mailbox_maps.cf /etc/postfix/pgsql_virtual_mailbox_maps.cf - query = SELECT login FROM usr WHERE login = '%u I also tried changing the output of the query which didn't make a difference (I think I read somewhere that Postfix treats the return as a boolean) query = SELECT login || '\t' || login||'/' FROM usr WHERE login = '%u I tried setting these options, as well, but that didn't work either - virtual_mailbox_base = /var/mail home_mailbox = Maildir/ > > Use virtual_alias_maps with: > foo@example foo@example, foo.maildir@example > If I understand correctly, I need to effectively "make up" two emails for each account and somehow configure separate deliveries for each email. I would think the delivery configuration would be based on the domain, but I guess you are suggesting it be done using the login part - foo vs foo.maildir (using "login" loosely here). > Now, mail for foo@example goes to script and maildir. > > Wietse
Re: content_filter with external script and virtual_alias_maps
Stats Student: > On Tue, Jul 7, 2020 at 4:19 PM Wietse Venema wrote: > > > > Stats Student: > > > On Tue, Jul 7, 2020 at 2:15 PM Wietse Venema wrote: > > > > > > > > Stats Student: > > > > > Thank you, but I still do not understand why I need to provide > > > > > additional user aliases. If my system receives a message for > > > > > > > > To deliver a message to two destinations > > > > > > > > 1) a script > > > > 2) a maildir file > > > > > > > > That message needs to have (surprise!) two destinations. > > > > > > > > 1) a destination that delivers to the script > > > > 2) a destination that delivers to the maildir file > > > > > > > > You can add that second destination with virtual_alias_maps, > > > > sender_bcc_maps, recipient_bcc_maps, .forward files, and so on. > > > > > > > > Wietse > > > > > > > Could you please show an example of what would go into one of those > > > maps to indicate a maildir destination? > > > > Prerequisites: > > foo@example delivers to script > > bar@example delivers to maildir > > > > Use virtual_alias_maps with: > > foo@example foo@example, bar@example > > > > Now, mail for foo@example goes to script and maildir. > > > > How to deliver to script or maildir? Use transport_maps to select > > a delivery agent that delivers to script (local or pipe delivery > > agent) or maildir (virtual or local delivery agent). > > > > foo@example > > Sorry if I am not explaining the requirement correctly. > > I need the same message addressed to f...@example.com to be delivered > to *two* places - the script AND the mailstore, *not* two different > accounts. I did NOT tell you to use two accounts. I told you to use two email addresses. An email address IS NOT an account. > I do *not* want messages addressed to f...@example.com to also go to > b...@example.com which is what the virtual_alias_maps you showed would > do. Again, an email address IS NOT an account. If it helps to rephrase the example: Prerequisites: foo@example delivers to script foo.maildir@example delivers to maildir Use virtual_alias_maps with: foo@example foo@example, foo.maildir@example Now, mail for foo@example goes to script and maildir. Wietse
Re: content_filter with external script and virtual_alias_maps
On Tue, Jul 7, 2020 at 4:19 PM Wietse Venema wrote: > > Stats Student: > > On Tue, Jul 7, 2020 at 2:15 PM Wietse Venema wrote: > > > > > > Stats Student: > > > > Thank you, but I still do not understand why I need to provide > > > > additional user aliases. If my system receives a message for > > > > > > To deliver a message to two destinations > > > > > > 1) a script > > > 2) a maildir file > > > > > > That message needs to have (surprise!) two destinations. > > > > > > 1) a destination that delivers to the script > > > 2) a destination that delivers to the maildir file > > > > > > You can add that second destination with virtual_alias_maps, > > > sender_bcc_maps, recipient_bcc_maps, .forward files, and so on. > > > > > > Wietse > > > > > Could you please show an example of what would go into one of those > > maps to indicate a maildir destination? > > Prerequisites: > foo@example delivers to script > bar@example delivers to maildir > > Use virtual_alias_maps with: > foo@example foo@example, bar@example > > Now, mail for foo@example goes to script and maildir. > > How to deliver to script or maildir? Use transport_maps to select > a delivery agent that delivers to script (local or pipe delivery > agent) or maildir (virtual or local delivery agent). > > foo@example Sorry if I am not explaining the requirement correctly. I need the same message addressed to f...@example.com to be delivered to *two* places - the script AND the mailstore, *not* two different accounts. I do *not* want messages addressed to f...@example.com to also go to b...@example.com which is what the virtual_alias_maps you showed would do. Re: transport maps -- my understanding is that those work on a per domain basis. Don't think I want to have a separate transport for each user.
Re: content_filter with external script and virtual_alias_maps
Stats Student: > On Tue, Jul 7, 2020 at 2:15 PM Wietse Venema wrote: > > > > Stats Student: > > > Thank you, but I still do not understand why I need to provide > > > additional user aliases. If my system receives a message for > > > > To deliver a message to two destinations > > > > 1) a script > > 2) a maildir file > > > > That message needs to have (surprise!) two destinations. > > > > 1) a destination that delivers to the script > > 2) a destination that delivers to the maildir file > > > > You can add that second destination with virtual_alias_maps, > > sender_bcc_maps, recipient_bcc_maps, .forward files, and so on. > > > > Wietse > > > Could you please show an example of what would go into one of those > maps to indicate a maildir destination? Prerequisites: foo@example delivers to script bar@example delivers to maildir Use virtual_alias_maps with: foo@example foo@example, bar@example Now, mail for foo@example goes to script and maildir. How to deliver to script or maildir? Use transport_maps to select a delivery agent that delivers to script (local or pipe delivery agent) or maildir (virtual or local delivery agent). foo@example
Re: content_filter with external script and virtual_alias_maps
On Tue, Jul 7, 2020 at 2:15 PM Wietse Venema wrote: > > Stats Student: > > Thank you, but I still do not understand why I need to provide > > additional user aliases. If my system receives a message for > > To deliver a message to two destinations > > 1) a script > 2) a maildir file > > That message needs to have (surprise!) two destinations. > > 1) a destination that delivers to the script > 2) a destination that delivers to the maildir file > > You can add that second destination with virtual_alias_maps, > sender_bcc_maps, recipient_bcc_maps, .forward files, and so on. > > Wietse > Could you please show an example of what would go into one of those maps to indicate a maildir destination? us...@example.com
Re: content_filter with external script and virtual_alias_maps
Stats Student: > Thank you, but I still do not understand why I need to provide > additional user aliases. If my system receives a message for To deliver a message to two destinations 1) a script 2) a maildir file That message needs to have (surprise!) two destinations. 1) a destination that delivers to the script 2) a destination that delivers to the maildir file You can add that second destination with virtual_alias_maps, sender_bcc_maps, recipient_bcc_maps, .forward files, and so on. Wietse
Re: content_filter with external script and virtual_alias_maps
On Fri, Jul 3, 2020 at 3:44 AM Matus UHLAR - fantomas wrote: > > >> Stats Student: > >> > 1) in addition to sending the messages to a script, is there a way to > >> > store the messages in a real mailstore ( Maildir ) ? > > >On Wed, Jul 1, 2020 at 8:31 AM Wietse Venema wrote: > >> Add a recipient with virtual_alias_maps, sender_bcc_maps, > >> recipient_bcc_maps, etc., and use the existing local(8) or virtual(8) > >> delivery agent to deliver to a maildir. > > On 01.07.20 13:34, Stats Student wrote: > >As for your other suggestion, I am sorry I didn't follow what you > >recommended specifically. > > you can alias the recipient to two destinations, where one sends mail to > script, other delivers it to mail store. > > you can do this in virtual alias table, alias table, in .forward file etc. > > Note that with alias table or .forward, failure to deliver to the script can > result in multiple delivery. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Enter any 12-digit prime number to continue. Thank you, but I still do not understand why I need to provide additional user aliases. If my system receives a message for us...@example.com, that message needs to go to two places - 1) the script and 2) Maildir mailstore. I don't want that message to now get addressed to user2@, user3@, etc, the same way that one can have messages addressed to root be aliased to real users - root: user1, user2, etc. Maybe I am not understanding aliases correctly. If anything, I would think the solution would be to add another virtual_transport, or maybe even a transport_map (which I did look into but couldn't see how to make it work for my problem). Maybe my use case is very unusual and I should just enhance my script to save messages in separate files (they'll be used to enhance the parser, not be read by users), but I am hoping I can avoid that.
Re: content_filter with external script and virtual_alias_maps
Stats Student: > 1) in addition to sending the messages to a script, is there a way to > store the messages in a real mailstore ( Maildir ) ? On Wed, Jul 1, 2020 at 8:31 AM Wietse Venema wrote: Add a recipient with virtual_alias_maps, sender_bcc_maps, recipient_bcc_maps, etc., and use the existing local(8) or virtual(8) delivery agent to deliver to a maildir. On 01.07.20 13:34, Stats Student wrote: As for your other suggestion, I am sorry I didn't follow what you recommended specifically. you can alias the recipient to two destinations, where one sends mail to script, other delivers it to mail store. you can do this in virtual alias table, alias table, in .forward file etc. Note that with alias table or .forward, failure to deliver to the script can result in multiple delivery. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Enter any 12-digit prime number to continue.
Re: content_filter with external script and virtual_alias_maps
Thank you. Re: bouncing emails - makes sense, won't do.
As for your other suggestion, I am sorry I didn't follow what you
recommended specifically.
I posted my configuration, if you could take a look.
https://dpaste.org/WdPx
On Wed, Jul 1, 2020 at 8:31 AM Wietse Venema wrote:
>
> Stats Student:
> > Hi, as a follow up to this question -
> >
> > 1) in addition to sending the messages to a script, is there a way to
> > store the messages in a real mailstore ( Maildir ) ?
>
> Add a recipient with virtual_alias_maps, sender_bcc_maps,
> recipient_bcc_maps, etc., and use the existing local(8) or virtual(8)
> delivery agent to deliver to a maildir.
>
> > 2) can I return something from the script that would cause the message
> > to get rejected, maybe even send a message back with an error code
> >
> > virtual_transport = mailstore
> >
> > mailstore unix - n n - - pipe
> > flags=DRXhu user=vmail argv=/path/to/script ${recipient}
>
> Don't do that. What you are proposing will produce backscatter,
> i.e. Postfix accepts SPAM with a false sender address, and then
> it sends a bounce message to some innocent person who did not send
> you mail.
>
> Wietse
Re: content_filter with external script and virtual_alias_maps
Stats Student:
> Hi, as a follow up to this question -
>
> 1) in addition to sending the messages to a script, is there a way to
> store the messages in a real mailstore ( Maildir ) ?
Add a recipient with virtual_alias_maps, sender_bcc_maps,
recipient_bcc_maps, etc., and use the existing local(8) or virtual(8)
delivery agent to deliver to a maildir.
> 2) can I return something from the script that would cause the message
> to get rejected, maybe even send a message back with an error code
>
> virtual_transport = mailstore
>
> mailstore unix - n n - - pipe
> flags=DRXhu user=vmail argv=/path/to/script ${recipient}
Don't do that. What you are proposing will produce backscatter,
i.e. Postfix accepts SPAM with a false sender address, and then
it sends a bounce message to some innocent person who did not send
you mail.
Wietse
Re: content_filter with external script and virtual_alias_maps
Hi, as a follow up to this question -
1) in addition to sending the messages to a script, is there a way to
store the messages in a real mailstore ( Maildir ) ?
2) can I return something from the script that would cause the message
to get rejected, maybe even send a message back with an error code
virtual_transport = mailstore
mailstore unix - n n - - pipe
flags=DRXhu user=vmail argv=/path/to/script ${recipient}
On Sat, Jan 4, 2020 at 3:26 PM Stats Student
wrote:
>
> Thanks very much, appreciate the detailed explanation. Everything
> seems to working as advertised.
>
> On Mon, Dec 30, 2019 at 7:32 AM Wietse Venema wrote:
> >
> > Wietse Venema:
> > > Stats Student:
> > > > Hi, I would like to configure Postfix to do the following:
> > > >
> > > > 1) receive messages for users in a Postgres database and hand those
> > > > messages to an external script for processing (no traditional
> > > > mailstore). The server handles mail for only one domain.
> >
> > With a few minor refinements:
> >
> > Postfix chooses the delivery method based on the recipient domain
> > (the part on the right-hand side of the '@').
> >
> > Here, we direct mail for example.com to your message store, and we
> > make sure that all cronjob mail comes from r...@example.com,
> > w...@example.com etc.
> >
> > This uses the name 'mailstore' for all things related to your
> > database. Of course you can use a different name.
> >
> > /etc/postfix/main.cf
> > virtual_transport = mailstore
> > mailstore_destination_recipient_limit=1
> > virtual_mailbox_domains = example.com
> > virtual_mailbox_maps = hash:/etc/postfix/mailstore-users
> > myorigin = example.com
> > mydestination =
> >
> > /etc/postfix/master.cf:
> > # Requires mailstore_destination_recipient_limit=1 in main.cf.
> > mailstore unix - n n - - pipe
> > flags=DRXhu user=vmail argv=/path/to/script ${recipient}${recipient}
> >
> > /etc/postfix/mailstore-users:
> > f...@example.com whatever
> > b...@example.com whatever
> >
> > This requires that you have have a UNIX system account 'vmail'
> > (command: useradd vmail). Of course you can use a different name.
> >
> > Once you have this working, replace hash:/etc/postfix/mailstore-users
> > with a pgsql table that returns a non-emnpty string for existing
> > users, and 'not found' otherwise. See "man pgsql_table", especially
> > the section "LIST MEMBERSHIP".
> >
> > > 2) for a handful of accounts (postmaster, help, root), the messages
> > > should be forwarded to another address (different domain). Would be
> > > great for this forwarding to take place without going through the
> > > processing script in (1).
> >
> > Use virtual_alias_maps:
> >
> > /etc/postfix/main.cf:
> > virtual_alias_maps = hash:/etc/postfix/virtual
> >
> > /etc/postfix/virtual:
> > postmaster user1@example
> > rootuser2@example
> > helpuser3@example
> >
> > No need to muck with content filters.
> >
> > Wietse
Re: Disable virtual_alias_maps after amavis
On Wed, 10 Jun 2020, Matus UHLAR - fantomas wrote: > On 10.06.20 12:48, Jozsef Kadlecsik wrote: > > handled@by.exchange handled@by.dovecot,handled@by.exchange > > > > The problem is that the address handled@by.dovecot receives every email > > sent to handled@by.exchange twice: handled@by.exchange is expanded before > > amavisd is called, and also after receiving the messages from there. > > This is what "no_address_mappings" in "receive_override_options" is for: > http://www.postfix.org/postconf.5.html#no_address_mappings That's it, thank you! Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.hu PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics H-1525 Budapest 114, POB. 49, Hungary
Re: Disable virtual_alias_maps after amavis
On 10.06.20 12:48, Jozsef Kadlecsik wrote: handled@by.exchange handled@by.dovecot,handled@by.exchange The problem is that the address handled@by.dovecot receives every email sent to handled@by.exchange twice: handled@by.exchange is expanded before amavisd is called, and also after receiving the messages from there. On 10.06.20 12:51, Matus UHLAR - fantomas wrote: This is what "no_address_mappings" in "receive_override_options" is for: http://www.postfix.org/postconf.5.html#no_address_mappings See: http://www.postfix.org/FILTER_README.html FYI, the amavis docs contain the info too: https://www.ijs.si/software/amavisd/README.postfix.html#basics_smtpd-daemon 127.0.0.1:10025 inet n- n - - smtpd ... -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters ... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody
Re: Disable virtual_alias_maps after amavis
On 10.06.20 12:48, Jozsef Kadlecsik wrote: handled@by.exchange handled@by.dovecot,handled@by.exchange The problem is that the address handled@by.dovecot receives every email sent to handled@by.exchange twice: handled@by.exchange is expanded before amavisd is called, and also after receiving the messages from there. This is what "no_address_mappings" in "receive_override_options" is for: http://www.postfix.org/postconf.5.html#no_address_mappings See: http://www.postfix.org/FILTER_README.html -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. (R)etry, (A)bort, (C)ancer
Disable virtual_alias_maps after amavis
Hello, We have a virtual_alias_maps entry like this handled@by.exchange handled@by.dovecot,handled@by.exchange The problem is that the address handled@by.dovecot receives every email sent to handled@by.exchange twice: handled@by.exchange is expanded before amavisd is called, and also after receiving the messages from there. I modified master.cf and disabled virtual_alias_maps at receiving back the email from amavis: localhost:10025 inetn - n - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes -o header_checks= -o mime_header_checks= -o nested_header_checks= -o body_checks= -o virtual_alias_maps= but it did not help. We cannot change the address handled@by.exchange to something else. The address handled@by.dovecot cannot be added to the alias in exchange. Instead of "-o virtual_alias_maps=", should we use something like "-o cleanup_service_name=amavis_cleanup"? Then we'd need the master.cf entry amavis_cleanupunix n - y - 0 cleanup -o virtual_alias_maps= But the manpage of smtpd does not state that cleanup_service_name is available as an option. How could one disable virtual_alias_maps in smtpd at receiving the mail from amavis? Multi-instance could be a solution, but I'd better avoid it in this case. Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.hu PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics H-1525 Budapest 114, POB. 49, Hungary
Re: content_filter with external script and virtual_alias_maps
Thanks very much, appreciate the detailed explanation. Everything
seems to working as advertised.
On Mon, Dec 30, 2019 at 7:32 AM Wietse Venema wrote:
>
> Wietse Venema:
> > Stats Student:
> > > Hi, I would like to configure Postfix to do the following:
> > >
> > > 1) receive messages for users in a Postgres database and hand those
> > > messages to an external script for processing (no traditional
> > > mailstore). The server handles mail for only one domain.
>
> With a few minor refinements:
>
> Postfix chooses the delivery method based on the recipient domain
> (the part on the right-hand side of the '@').
>
> Here, we direct mail for example.com to your message store, and we
> make sure that all cronjob mail comes from r...@example.com,
> w...@example.com etc.
>
> This uses the name 'mailstore' for all things related to your
> database. Of course you can use a different name.
>
> /etc/postfix/main.cf
> virtual_transport = mailstore
> mailstore_destination_recipient_limit=1
> virtual_mailbox_domains = example.com
> virtual_mailbox_maps = hash:/etc/postfix/mailstore-users
> myorigin = example.com
> mydestination =
>
> /etc/postfix/master.cf:
> # Requires mailstore_destination_recipient_limit=1 in main.cf.
> mailstore unix - n n - - pipe
> flags=DRXhu user=vmail argv=/path/to/script ${recipient}
>
> /etc/postfix/mailstore-users:
> f...@example.com whatever
> b...@example.com whatever
>
> This requires that you have have a UNIX system account 'vmail'
> (command: useradd vmail). Of course you can use a different name.
>
> Once you have this working, replace hash:/etc/postfix/mailstore-users
> with a pgsql table that returns a non-emnpty string for existing
> users, and 'not found' otherwise. See "man pgsql_table", especially
> the section "LIST MEMBERSHIP".
>
> > 2) for a handful of accounts (postmaster, help, root), the messages
> > should be forwarded to another address (different domain). Would be
> > great for this forwarding to take place without going through the
> > processing script in (1).
>
> Use virtual_alias_maps:
>
> /etc/postfix/main.cf:
> virtual_alias_maps = hash:/etc/postfix/virtual
>
> /etc/postfix/virtual:
> postmaster user1@example
> rootuser2@example
> helpuser3@example
>
> No need to muck with content filters.
>
> Wietse
Re: content_filter with external script and virtual_alias_maps
On Mon, Dec 30, 2019 at 12:46:50AM -0800, Stats Student wrote: > 1) receive messages for users in a Postgres database and hand those > messages to an external script for processing (no traditional > mailstore). The server handles mail for only one domain. > > 2) for a handful of accounts (postmaster, help, root), the messages > should be forwarded to another address (different domain). This is easily handled via virtual_alias_maps, rewriting the recipients in question. > Would be great for this forwarding to take place without going through the > processing script in (1). Virtual alias rewriting happens before message delivery. Note that the domain need not be configured as a virtual alias domain, virtual alias rewriting happens for all recipients, regardless of address class. > A very long time ago, I had it working with content_filter (as > described in http://www.postfix.org/FILTER_README.html#advanced_filter) > and virtual_alias_maps. That's unnecessary, a pipe(8) transport is just fine, unless the mail is going back into Postfix after processing by the script. > But for some reason (receive_override_options = no_address_mappings) > causes the server to ignore users in virtual_alias_maps and bounce. Well, that's simply not how Postfix works, when you have a content_filter. The bounce only happens with no_address_mappings in combination with NO content_filter. But, you don't need either a filter or no_address_mappings. > What's the best way to get this configured? Would appreciate specific > setup recommendations (relay vs virtual aliases, content_filter, etc). > Happy to provide additional details. Rewrite the exempt users to a different domain, resolve the original domain to a pipe(8) transport that runs the script. Provided the script does not re-inject modified email back into Postfix with the same recipient domain. -- Viktor.
Re: content_filter with external script and virtual_alias_maps
Wietse Venema:
> Stats Student:
> > Hi, I would like to configure Postfix to do the following:
> >
> > 1) receive messages for users in a Postgres database and hand those
> > messages to an external script for processing (no traditional
> > mailstore). The server handles mail for only one domain.
With a few minor refinements:
Postfix chooses the delivery method based on the recipient domain
(the part on the right-hand side of the '@').
Here, we direct mail for example.com to your message store, and we
make sure that all cronjob mail comes from r...@example.com,
w...@example.com etc.
This uses the name 'mailstore' for all things related to your
database. Of course you can use a different name.
/etc/postfix/main.cf
virtual_transport = mailstore
mailstore_destination_recipient_limit=1
virtual_mailbox_domains = example.com
virtual_mailbox_maps = hash:/etc/postfix/mailstore-users
myorigin = example.com
mydestination =
/etc/postfix/master.cf:
# Requires mailstore_destination_recipient_limit=1 in main.cf.
mailstore unix - n n - - pipe
flags=DRXhu user=vmail argv=/path/to/script ${recipient}
/etc/postfix/mailstore-users:
f...@example.comwhatever
b...@example.comwhatever
This requires that you have have a UNIX system account 'vmail'
(command: useradd vmail). Of course you can use a different name.
Once you have this working, replace hash:/etc/postfix/mailstore-users
with a pgsql table that returns a non-emnpty string for existing
users, and 'not found' otherwise. See "man pgsql_table", especially
the section "LIST MEMBERSHIP".
> 2) for a handful of accounts (postmaster, help, root), the messages
> should be forwarded to another address (different domain). Would be
> great for this forwarding to take place without going through the
> processing script in (1).
Use virtual_alias_maps:
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
postmaster user1@example
rootuser2@example
helpuser3@example
No need to muck with content filters.
Wietse
Re: content_filter with external script and virtual_alias_maps
Stats Student:
> Hi, I would like to configure Postfix to do the following:
>
> 1) receive messages for users in a Postgres database and hand those
> messages to an external script for processing (no traditional
> mailstore). The server handles mail for only one domain.
Postfix chooses the delivery method based on the recipient domain
(the part on the right-hand side of the '@').
Here, we direct mail for example.com to your message store, and we
make sure that all cronjob mail comes from r...@example.com,
w...@example.com etc.
/etc/postfix/main.cf
virtual_transport = mailstore
mailstore_destination_recipient_limit=1
virtual_mailbox_domains = example.com
virtual_mailbox_maps = hash:/etc/postfix/mailstore-users
myorigin = example.com
mydestination =
/etc/postfix/master.cf:
# Requires mailstore_destination_recipient_limit=1 in main.cf.
mailstore unix - n n - - pipe
flags=DRhu user=vmail argv=/path/to/script ${recipient}
/etc/postfix/mailstore-users:
f...@example.comwhatever
b...@example.comwhatever
Once you have this working, replace hash:/etc/postfix/mailstore-users
with a pgsql table that returns a non-emnpty string for existing
users, and 'not found' otherwise. See "man pgsql_table", especially
the section "LIST MEMBERSHIP".
> 2) for a handful of accounts (postmaster, help, root), the messages
> should be forwarded to another address (different domain). Would be
> great for this forwarding to take place without going through the
> processing script in (1).
Use virtual_alias_maps:
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
postmaster user1@example
rootuser2@example
helpuser3@example
No need to muck with content filters.
Wand ietse
content_filter with external script and virtual_alias_maps
Hi, I would like to configure Postfix to do the following: 1) receive messages for users in a Postgres database and hand those messages to an external script for processing (no traditional mailstore). The server handles mail for only one domain. 2) for a handful of accounts (postmaster, help, root), the messages should be forwarded to another address (different domain). Would be great for this forwarding to take place without going through the processing script in (1). A very long time ago, I had it working with content_filter (as described in http://www.postfix.org/FILTER_README.html#advanced_filter) and virtual_alias_maps. But for some reason (receive_override_options = no_address_mappings) causes the server to ignore users in virtual_alias_maps and bounce. Hence the question. I used to use qpsmtpd on port 10025 with a custom plugin (in Perl) which did the processing - but maybe there is a better way to do the same. What's the best way to get this configured? Would appreciate specific setup recommendations (relay vs virtual aliases, content_filter, etc). Happy to provide additional details. Thanks.
Re: domain-specific virtual_alias_maps file
Mattia Rizzolo: > Is it possible to have anything like that? Also assuming in the future > this host will have to handle a separate domain, I'd prefer to have > different files for each set of aliases, and keep it tidy. Postfix supports multiple aliases files; that is usually how mailman is hooked up with Postfix, if you use the Postfix local delivery agent. alias_maps = hash:/etc/aliases, hash:/path/to/mailman/aliases, ... There currently is no simple way to have different alias_maps settings for different domains; that is because the Postfix local delivery agent implements a domain-less flat namespace. It is possible to configure different Postfix local delivery agents for different domains, each agent having its own "-o alias_maps" setting in master.cf, but I would not consider that simple. Of course that is not a problem with virtual_alias maps; there, each alias contains the domain name that it belongs in. Wietse
domain-specific virtual_alias_maps file
Hi,
I'm setting up a new site that is going to handle all a mailing list
(with mailman, on its own domain lists.example.org) and a few aliases
@example.org. The host is named mail1.example.org.
I successfully did it using:
- main.cf:
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail1.example.org, localhost
relay_domains = lists.example.org
virtual_alias_maps = hash:/etc/postfix/virtual_domains
mailman_destination_recipient_limit = 1
transport_maps = hash:/etc/postfix/transport
-
- master.cf
mailman unix - n n - - pipe
flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
${nexthop} ${user}
-
- transport
lists.example.org mailman:
-
virtual_domains
mat...@example.org mat...@mapreri.org
f...@example.org blablabla@gmail
f...@example.org asdasdasd@gmail
-
Now, this all works, but there is one thing that has been nagging me.
Backstory: I also inherited a host running exim4 that handles a few
aliases, and there I have a file /etc/exim4/aliases/example.org, and in
exim4.conf there this snippet:
- exim4.conf
domain_aliases:
driver = redirect
allow_fail
allow_defer
domains = dsearch;/etc/exim4/aliases
data = ${lookup{$local_part}wildlsearch{/etc/exim4/aliases/$domain}}
-
Then the alias file is just
- /etc/exim4/aliases/example.org
root: mat...@mapreri.org
info: root
blabla: a@b.c, d@e.f
-
...and the like, without having @example.org at each alias line. It's
really the same syntax of the system's /etc/aliases, but it applies only
the single virtual domain (or "virtual alias" in postfix terms, I guess).
Is it possible to have anything like that? Also assuming in the future
this host will have to handle a separate domain, I'd prefer to have
different files for each set of aliases, and keep it tidy.
Thank you in advance for any suggestion you can give me!
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: difference between setting up an alias in virtual_alias_maps and virtual_mailbox_maps?
Thanks Yassine thats very helpful. Im going to modify the config to do it all with virtual_alias_maps On 27/03/2019 10:56, Yassine Chaouche wrote: On 3/27/19 11:19 AM, Andrew Wood wrote: What is the difference between setting up an alias in virtual_alias_maps and virtual_mailbox_maps? I can make alias@domain point to a mailbox by pairing it with the path to the maildir in virtual_mailbox_maps but it seems if I do that the alias can only point to one mailbox not multiple. e.g user@domain /path/to/user@domain/ alias@domain /path/to/user@domain/ this works OK but if I was to do user1@domain /path/to/user1@domain/ user2@domain /path/to/user2@domain/ alias@domain /path/to/user1@domain/ alias@domain /path/to/user2@domain/ this doesnt work. Hello Andrew, I use commas to separate multiple recipients of one alias, like this : alias@domain \t user1@domain, user2@domain, user3@domain I think virutal_mailbox_maps and virtual_alias_maps shouldn't be compared, they're different configurations. virtual_mailbox_maps will tell postfix if a mailbox is valid or not, this can be a query in your database with the e-mail of the user. If the query returns a result then the user exists and postfix is happy, otherwise postfix will bounce the e-mail to the sender saying the user doesn't exist. virtual_alias_maps will tell postfix what aliases are defined (what you want), so that for example abuse@domain is redirected to both john and mary. Yassine.
Re: difference between setting up an alias in virtual_alias_maps and virtual_mailbox_maps?
On 3/27/19 11:19 AM, Andrew Wood wrote: What is the difference between setting up an alias in virtual_alias_maps and virtual_mailbox_maps? I can make alias@domain point to a mailbox by pairing it with the path to the maildir in virtual_mailbox_maps but it seems if I do that the alias can only point to one mailbox not multiple. e.g user@domain /path/to/user@domain/ alias@domain /path/to/user@domain/ this works OK but if I was to do user1@domain /path/to/user1@domain/ user2@domain /path/to/user2@domain/ alias@domain /path/to/user1@domain/ alias@domain /path/to/user2@domain/ this doesnt work. Hello Andrew, I use commas to separate multiple recipients of one alias, like this : alias@domain \t user1@domain, user2@domain, user3@domain I think virutal_mailbox_maps and virtual_alias_maps shouldn't be compared, they're different configurations. virtual_mailbox_maps will tell postfix if a mailbox is valid or not, this can be a query in your database with the e-mail of the user. If the query returns a result then the user exists and postfix is happy, otherwise postfix will bounce the e-mail to the sender saying the user doesn't exist. virtual_alias_maps will tell postfix what aliases are defined (what you want), so that for example abuse@domain is redirected to both john and mary. Yassine.
difference between setting up an alias in virtual_alias_maps and virtual_mailbox_maps?
What is the difference between setting up an alias in virtual_alias_maps and virtual_mailbox_maps? I can make alias@domain point to a mailbox by pairing it with the path to the maildir in virtual_mailbox_maps but it seems if I do that the alias can only point to one mailbox not multiple. e.g user@domain /path/to/user@domain/ alias@domain /path/to/user@domain/ this works OK but if I was to do user1@domain /path/to/user1@domain/ user2@domain /path/to/user2@domain/ alias@domain /path/to/user1@domain/ alias@domain /path/to/user2@domain/ this doesnt work. Posfix logs that it has deleivered a message to alias@domain successfully but the message never arrives in either box nor does it bounce back. I can also add an entry in virtual_alias_maps, does this have the ability to point to multiple mailboxes and should I be using this for all rather than doing it in virtual_mailbox_maps? Regards Andrew
Re: question regarding virtual_alias_maps and virtual_mailboxes_map
Andras Kemeny: [ Charset ISO-8859-2 converted... ] > hi, > > i have a working setup, but since i want to expand the capabilities of > our system, i tampered with it and ran into an error at which i'm quite > baffled. > > excerpt from the settings: > > # Valid virtual domains > virtual_mailbox_domains = proxy:hash:/etc/postfix/virtual_domains > virtual_alias_domains = proxy:hash:/etc/postfix/virtual_domains > > /(btw postfix keeps complaining like this:// > //Aug? 8 11:54:15 rhyno postfix/trivial-rewrite[24427]: warning: do not > list domain rhyno.tech in BOTH virtual_alias_domains and > virtual_mailbox_domains// > //...but then how do i tell postfix that i need it to check for aliased > addresses before attempting virtual delivery?)/ As documented, virtual_alias_maps is ALWAYS searched. Wietse
question regarding virtual_alias_maps and virtual_mailboxes_map
hi, i have a working setup, but since i want to expand the capabilities of our system, i tampered with it and ran into an error at which i'm quite baffled. excerpt from the settings: # Valid virtual domains virtual_mailbox_domains = proxy:hash:/etc/postfix/virtual_domains virtual_alias_domains = proxy:hash:/etc/postfix/virtual_domains /(btw postfix keeps complaining like this:// //Aug 8 11:54:15 rhyno postfix/trivial-rewrite[24427]: warning: do not list domain rhyno.tech in BOTH virtual_alias_domains and virtual_mailbox_domains// //...but then how do i tell postfix that i need it to check for aliased addresses before attempting virtual delivery?)/ # Virtual aliases virtual_alias_maps = proxy:hash:/etc/postfix/virtual_aliases # Valid virtual recipients #virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap/virtual_boxes.cf /(yes, there is no virtual_mailbox_maps as i didn't want a separate round of address checking (as you can see, that data is available from LDAP only) when dovecot will check it no matter what. so there should be no address checking. why does then postfix keep complaining like:// //Aug 8 11:54:15 rhyno postfix/error[24439]: 7C64B5C009F: to=, orig_to=, relay=none, delay=3.1, delays=3.1/0.01/0/0.03, dsn=5.1.1, status=bounced (User unknown in virtual alias table)// //...when in fact a...@rhyno.tech exists and works?)// / # Deliver mail for virtual recipients to Dovecot virtual_transport = lmtp:unix:private/dovecot-lmtp so all delivery (and any address checking) happens via dovecot-lmtp. i don't get why postfix wants to know the final recipients if rhyno.tech is in the virtual_domains hashmap. virtual_domains file: rhyno.tech OK rhynotechnologies.com OK virtual_aliases file: hostmas...@rhyno.tech a...@rhyno.tech postmas...@rhyno.tech a...@rhyno.tech ab...@rhyno.tech a...@rhyno.tech git...@rhyno.tech a...@rhyno.tech,n...@rhyno.tech what am i doing wrong? should i try to set up aliasing in dovecot? is it possible at all? thanks, andras
Re: Problem with virtual_alias_maps and backscatter
Hi,
Am 20.05.2018 um 16:40 schrieb Wietse Venema:
[...]
> Indeed. With Postfix 2.4 and later, both the virtual(5) and
> canonical(5) manpages document that wildcard address mappings will
> break adress validation.
>
Yes i read that but as said was surprised that this included lookups to
the very same table as well. Especially since lookups to
virtual_alias_map are docuemented to be recursive. Of course after
reading the source code and seeing where all this is done it got very
clear to me why postfix is doing it the way it does.
However i still think the documentation should be more specific about this.
[...]
>
> - Keep the @example.com - @example.org mapping, and add a
> reject_unverified_recipient check for recipients in example.com.
>
> unverified_recipient_reject_code = 550
> smtpd_recipient_restrictions =
> ...
> reject_unauth_destination
> check_recipient_access inline:{example.com=reject_unverified_recipient}
That did the trick! Thanks for the fast response!
regards
christian
signature.asc
Description: OpenPGP digital signature
Re: Problem with virtual_alias_maps and backscatter
equinox:
> Re-reading the documentation over and over again i yesterday realized
> that a simple non-regexp table containing
>
>
> @example.com@example.org
> ...
>
>
> does suffice to do the same thing. However the problem i'm having stays
> the same.
Indeed. With Postfix 2.4 and later, both the virtual(5) and
canonical(5) manpages document that wildcard address mappings will
break adress validation.
Address validation in the SMTP daemon was not part of the initial
Postfix design, and therefore the validation will be an over-approximation
when a map replaces an address. To be more precise, the lookup
result would have to go through all the steps that are implemented
in the cleanup daemon.
Currently, you can make the address validation more precise with:
- Replace the @example.com - @example.org mapping with a 1:1 alias
for each valid address in example.com.
- Keep the @example.com - @example.org mapping, and add a
reject_unverified_recipient check for recipients in example.com.
unverified_recipient_reject_code = 550
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access inline:{example.com=reject_unverified_recipient}
The inline: table is available in Postfix 3.0 and later. Use a
hash: map with earlier Postfix versions.
The reject_unverified_recipient feature requests that the verify(8)
daemon sends a probe email message to find out of the recipient
address would bounce (after RCPT TO, Postfix sends RSET and QUIT).
The probe message result is cached for several days, so the number
of probes per recipient will be small.
If the alias (or canonical mapping) resolves to a remote address,
Postfix will contact a remote server. If this happens a lot then
the remote site might object.
Wietse
Problem with virtual_alias_maps and backscatter
Hi,
I got 2 domains, let's call them example.org and example.com and i want
them to share the same mail addresses. So f...@example.org and
f...@example.com should always reach the same destination.
The mail system consists of 2 MX hosts and a single backend MTA that
forwards all mails to my imap server. The MX hosts use virtual_domains
and virtual_alias_maps to check whether a specific recipient exists and
then forward the mail to the internal host or in some cases to external
mail servers.
For years now the virtual_alias_map for example.org and example.com
looked like this:
/^(.*)@example\.com$/${1}@example.org
/^foo@example\.org$/ f...@some-other-domain.org
/^bar@example\.org$/ bar@external-domain.something
This worked just fine but, for some reason only now, i realized this
makes @example.com a backscatter spam source.
Re-reading the documentation over and over again i yesterday realized
that a simple non-regexp table containing
@example.com@example.org
...
does suffice to do the same thing. However the problem i'm having stays
the same.
Looking into the source code the reason for this behaviour is that,
while the virtual_alias_maps lookup as done by the cleanup daemon is
recursive the same lookup by smtpd is not. It will simple except
anything that is a match in any of the various lookup tables (just
search for 'virt_alias_maps' in smtpd/smtpd-check.c to find the code i'm
referring to).
For now the problem is not too severe since example.com is not used
often and the whole mail system has very low traffic. So any massive
misuse of the system would have triggered my monitoring.
Still this is not a situation that i want to keep any longer and even
worse i recently had to do a similiar setup for somebody else. The
premise is basically the same only that for this system addresses for
mails to example.org are resolved using an LDAP lookup and the mail
system uses virtual_mailbox_maps to filter non existing users. This
domain will be used much more frequently and will soon attract spammers.
So my first question is whether the above analysis is correct?
If yes i think the documention doesn't state well enough that this is
the case. For me it is obvious that in case the virtual alias is
pointing to an external address it will not be checked but i was
surprised to have the same behaviour for addresses that are handled by
the same MTA. Especially since the documentation explicitly says that
the lookups in virtual_alias_maps are recursive.
And of course my next question: How can i change my setup to make it
work without turning my MX hosts to backscatter spam sources?
For the originial system i of course can use a regexp lookup that looks
something like this:
/^foo@example\.(org|com)$/ f...@some-other-domain.org
/^bar@example\.(org|com)$/ bar@external-domain.something
This is what i will be doing as soon as i finished writing this mail. Of
course for the other system this is not as easy. The only thing i can
think of right now is to have a cron script that generates a
virtual_alias_map for example.com based on the LDAP entries for
example.org. Is this really the only way or is there another solution to
this?
regards
christian
signature.asc
Description: OpenPGP digital signature
Re: Substitute original address in virtual_alias_maps
MegaBrutal: > Hello, > > If I have a virtual alias map like this: > > @domain.tldsomeaddr...@otherdomain.tld superaddr...@somedomain.tld > > Then all e-mails to domain.tld will be forwarded to the two given > addresses, right? > > Fine. But then, I want those e-mails to be delivered to the original > recipient too. For example, if s...@domain.tld receives an e-mail, I > want it to be delivered to 3 addresses: someaddr...@otherdomain.tld, > superaddr...@somedomain.tld, and s...@domain.tld itself. If I could > add the address to the list, it would be fine, but... it's a variable. > How can I substitute a variable there? Something like: > > @domain.tldsomeaddr...@otherdomain.tld > superaddr...@somedomain.tld $originaladdress > > But I don't know what can I supply to substitute the original address with. Use a PCRE table, capture the original address with (), and place it in the expansion as $1: /etc/postfix/virtual.pcre: /(.+@example\.com$) $1, addr, addr /etc/postfix/main.cf: virtual_alias_maps = pcre:/etc/postfix/virtual.pcre, othermaps... In the left-hand pattern, the '\' and '$' are required to avoid false matches. Wietse
Substitute original address in virtual_alias_maps
Hello, If I have a virtual alias map like this: @domain.tldsomeaddr...@otherdomain.tld superaddr...@somedomain.tld Then all e-mails to domain.tld will be forwarded to the two given addresses, right? Fine. But then, I want those e-mails to be delivered to the original recipient too. For example, if s...@domain.tld receives an e-mail, I want it to be delivered to 3 addresses: someaddr...@otherdomain.tld, superaddr...@somedomain.tld, and s...@domain.tld itself. If I could add the address to the list, it would be fine, but... it's a variable. How can I substitute a variable there? Something like: @domain.tldsomeaddr...@otherdomain.tld superaddr...@somedomain.tld $originaladdress But I don't know what can I supply to substitute the original address with. I hope you understand my goal, as I didn't have much time to compose clearly. Best regards, MegaBrutal
Re: virtual_alias_maps combined with sender domain
thx noel! you are absolutely right - the proper way is to create a 2 restriction classes. thx again! On 12/09/2016 05:22 PM, Noel Jones wrote: > On 12/9/2016 9:11 AM, Harald Glanzer wrote: >> hi all! >> >> i am using virtual_alias_maps for a simple 'mainlinglist' configuration, i.e. >> lookup a list adress and get the expanded (local) recipients. >> >> the lookup is based on mysql: >> SELECT recipients FROM forwardings WHERE listadress='%s' >> >> is there any way to restrict this expansion s.t. it only occurs for a >> speficic >> sender domain. for example, i would love to do something like that >> SELECT recipients FROM forwardings WHERE listadress='%s' AND sender = >> '%INTERNAL_VARIABLE' >> >> where INTERNAL_VARIABLE contains the domain of the sender. i want to >> restrict this s.t. >> a virtual_alias_maps expansion occurs _only_ if the sender belongs to a >> certain domain (and has >> used SMTP auth)... >> > > > It is possible to restrict internal lists to a specific sender using > restriction classes. Here's an example: > http://www.postfix.org/RESTRICTION_CLASS_README.html#internal > > > > > -- Noel Jones > -- DI Harald Glanzer Research Industrial Systems Engineering (RISE) Forschungs-, Entwicklungs- und Großprojektberatung GmbH Concorde Business Park F 2320 Schwechat Austria Email: harald.glan...@rise-world.com Web: www.rise-world.com Firmenbuch: FN 280353i Handelsgericht Korneuburg UID: ATU62886416
