[pfx] HowTo Migrate from text based mapping/routing to Database based routing
Hello, currently we manually use text files for mapping/routing: # postconf -n |grep -e transport -e alias alias_database = hash:/etc/aliases hash:/etc/postfix/aliases alias_maps = hash:/etc/aliases hash:/etc/postfix/aliases allow_mail_to_commands = alias,forward,include local_transport = lmtp:unix:/run/cyrus/socket/lmtp mailbox_transport = lmtp:unix:/run/cyrus/socket/lmtp transport_maps = hash:/etc/postfix/mailertable (=> sub.example.com smtp:[somerelay.net] virtual_alias_domains = /etc/postfix/local-host-names (=> example.com) virtual_alias_maps = hash:/etc/postfix/virtusertable hash:/etc/postfix/aliases (=> f...@example.com pop-1234-0005) virtual_transport = lmtp:unix:/run/cyrus/socket/lmtp We would like to migrate to a Database in order to manage it with a GUI or something. Any hints on this? Are there existing scripts/projects? Thanks, Michael ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: HowTo Migrate from text based mapping/routing to Database based routing
Ml Ml via Postfix-users: > Hello, > > currently we manually use text files for mapping/routing: > > # postconf -n |grep -e transport -e alias > alias_database = hash:/etc/aliases hash:/etc/postfix/aliases > alias_maps = hash:/etc/aliases hash:/etc/postfix/aliases > allow_mail_to_commands = alias,forward,include > local_transport = lmtp:unix:/run/cyrus/socket/lmtp > mailbox_transport = lmtp:unix:/run/cyrus/socket/lmtp > transport_maps = hash:/etc/postfix/mailertable (=> sub.example.com > smtp:[somerelay.net] > virtual_alias_domains = /etc/postfix/local-host-names (=> example.com) > virtual_alias_maps = hash:/etc/postfix/virtusertable > hash:/etc/postfix/aliases (=> f...@example.com pop-1234-0005) > virtual_transport = lmtp:unix:/run/cyrus/socket/lmtp > > We would like to migrate to a Database in order to manage it with a > GUI or something. > Any hints on this? Are there existing scripts/projects? Some of the above settings have no support for table lookups, for example *_transport and allow_mail_to_commands. See https://www.postfix.org/postconf.5.html Any database scheme will do, as long as you can provide the queries that return the answers that Postfix expects to see. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: long header folding and DKIM fails
Postfix does not store line endings internally, because different environments have different line ending conventions (for example SMTP has while UNIX has ). Postfix strips line endings on input, and adds them on output. Postfix was modeled after routers with different kinds of network interfaces. The Postfix sendmail command allows both and , because too many app developers were messing up. As of January 2024, Postfix replaces any and that are not part of a line ending with space. This prevents outbound SMTP smuggling, and makes DKIM signatures more likely to verify. The default setting "cleanup_replace_stray_cr_lf = yes" was added in Postfix 3.9, 3.8.5, 3.7.10, 3.6.14, and 3.5.24 later. Returning to the problem at hand, the options that I see are: - Forward the message including all its MIME headers, and leave the decoding to the recipient's mail software. - Use a real MIME parser and decoder to extract the plain text that you want to forward. The trick to strip " =" works only for quoted-printable encoding, but does not handle messages encoded in base64. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: long header folding and DKIM fails
John Levine wrote in <20240430015342.8DF9C89B9BE7@ary.local>: |It appears that Steffen Nurpmeso via Postfix-users \ |said: |W> |I did not want to insult you! |>|In mind i had these canon..py snippets |>| |>| def strip_trailing_whitespace(content): |>|return re.sub(b"[\t ]+\r\n", b"\r\n", content) |>| |>| |>| def compress_whitespace(content): |>|return re.sub(b"[\t ]+", b" ", content) |>| |>| ... |>| |>|(x[0].lower().rstrip(), |>| compress_whitespace(unfold_header_value(x[1])).strip() + b"\r\n") |>| for x in headers] |>| |>|These strip()s remove any whitespace, as opposed to [\t ] only. | |If you are complaining that it removes bare \r and \n, those are invalid, |we've repeatedly told you why they're invalid and you're not doing yourself |any favors by continued digging. No, as i said on the IETF list and now here is that isspace(3) includes several US-ASCII aka lowermost 7-bit of ISO 10646 whitespace characters aside from SPace and HTabulator. You may find it nitpicking, and as i also said dkimpy is the best with that strip() above compared to plain usage of [ascii_]isspace() (rspamd, opendkim) or \s regex (perl thing used by amavisd: last step only on minimal subrange, too). But it is not the "hardcore literal RFC 6376" that the dkim library exim uses implements, or what my thing does. Much worse than the above whitespace thingy is anyway the RFC 5322 parser support of python as such, etc etc. |>In general "all the interoperability problems" are only (as far as |>*i* flew above it) about such whitespace issues. Most dramatical, |>still, by opendkim and rspamd (git repository source). --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: long header folding and DKIM fails
Wietse Venema via Postfix-users wrote in <4vtlbf3vz0zj...@spike.porcupine.org>: |Postfix does not store line endings internally, because different |environments have different line ending conventions (for example |SMTP has while UNIX has ). Postfix strips line endings |on input, and adds them on output. Postfix was modeled after routers |with different kinds of network interfaces. 'has nothing to do with the line endings. On some lonely IETF place i posted code snippets of opendkim's header parsing, he knows that very well. |The Postfix sendmail command allows both and , because |too many app developers were messing up. | |As of January 2024, Postfix replaces any and that are not |part of a line ending with space. This prevents outbound SMTP |smuggling, and makes DKIM signatures more likely to verify. The |default setting "cleanup_replace_stray_cr_lf = yes" was added in |Postfix 3.9, 3.8.5, 3.7.10, 3.6.14, and 3.5.24 later. | |Returning to the problem at hand, the options that I see are: | |- Forward the message including all its MIME headers, and leave | the decoding to the recipient's mail software. | |- Use a real MIME parser and decoder to extract the plain text | that you want to forward. | |The trick to strip " =" works only for quoted-printable encoding, |but does not handle messages encoded in base64. But one thing is plain, if lines get folded "artificially" to satisfy line length limits, then this is a whitespace that DKIM will see, and if it was not in the original message, the signature will break. The only possibility to get over this hurdle is to apply RFC 2047 (or RFC 2231, in a parameter) MIME encoding, and then (for RFC 2047) the software needs to be able to understand the character set of the data in order not to break up multibyte characters (not possible with ISO C, iconv can this, a bit), because 2047 generates "atomic units" instead of a stream that is united like 2231. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: long header folding and DKIM fails
Steffen Nurpmeso via Postfix-users: > But one thing is plain, if lines get folded "artificially" to > satisfy line length limits, then this is a whitespace that DKIM > will see, and if it was not in the original message, the signature > will break. After the DKIM signature is generated, the artificial line break already invalidates the signature. The purpose of the artificial space after this line break is to preserve the MIME structure, so that humans aren't exposed to raw html, q-p, or base64 etc. > The only possibility to get over this hurdle is to apply RFC 2047 > (or RFC 2231, in a parameter) MIME encoding, and then [...] Any such actions need to be taken sender-side, before the DKIM signature is generated. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: long header folding and DKIM fails
Wietse Venema via Postfix-users wrote in <4vtb9v00wbzj...@spike.porcupine.org>: |Steffen Nurpmeso via Postfix-users: |> But one thing is plain, if lines get folded "artificially" to |> satisfy line length limits, then this is a whitespace that DKIM |> will see, and if it was not in the original message, the signature |> will break. | |After the DKIM signature is generated, the artificial line break |already invalidates the signature. The purpose of the artificial |space after this line break is to preserve the MIME structure, so |that humans aren't exposed to raw html, q-p, or base64 etc. Maybe we are running off-bounds. |> The only possibility to get over this hurdle is to apply RFC 2047 |> (or RFC 2231, in a parameter) MIME encoding, and then [...] | |Any such actions need to be taken sender-side, before the DKIM |signature is generated. I agree. That much is plain. --End of <4vtb9v00wbzj...@spike.porcupine.org> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
