[pfx] Re: relay specific domain
On Tue, 23 Jan 2024, Wietse Venema via Postfix-users wrote: Barbara M. via Postfix-users: Jan 23 00:11:34 auth postfix/smtpd[188544]: NOQUEUE: reject: RCPT from wp-host1.xyz.com[4.3.2.1]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= It this is this an INTERNAL DESTINATION, add it to main.cf:relay_domains. relay_domains = dom-redir.it, ... If this is an EXTERNAL DESTINATION, authorize the client with mynetworks or with SASL authentication. smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, ... Sorry for my poor english. Hope I can be understood. As I told in my post, I want that if anyone send mail to *@dom-redir.it, his SMTP server, find this server as MX for the dom-redir.it domain (DNS already configured obviously), this server receive the mail and relay it to the real destination server (that can be considered EXTERNAL). In this situation I can't use client authorization (that is already configured and working, with the usuals mynetworks and SASL authentication). Just for test I have tried to add the domain in main.cf as: relay_domains = dom-redir.it, ... but as I wrote, I already have tried before with the usual: relay_domains = hash:/etc/postfix/relay_domains where in /etc/postfix/relay_domains I have: dom-redir.itOK . . . That is the same. But still have the "Relay access denied" answer. Tried to compare with other similar servers (not same OS or Postfix version), but I can't find what I am doing wrong. I suppose it is a parameter somewhere. Thanks, B ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
Dnia 24.01.2024 o godz. 08:20:33 Matthias Schneider via Postfix-users pisze: > > Upon reviewing the code, it appears there are only one limit on > vstring_sprintf, three limits on msg_info in the code, whereas the rest of > the %.200s limits are present on msg_warn lines. My request stems from > the need to log more comprehensive information, such as > Authentication-Results headers or DKIM Signatures, which often exceed the > current 200-character limit. ( they header key 'Authentication-Results: ' > is using 24 chars already) If you found the limits in the code, just change them to a value that suits you and rebuild Postfix for yourself. It's one of the advantages of being open source, anyway. -- 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: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
Hi Jaroslaw, Thank you for your suggestion. I've indeed explored the option of adjusting the limits in the code, and I've been maintaining a patched version for my specific needs for quite some time now. However, I've also encountered others who faced similar challenges and found the patched version useful. While this approach works, having this feature as a configurable option in the upstream codebase would significantly simplify the process for users with similar requirements. It would make Postfix more adaptable to various use cases without the need for manual adjustments and custom builds. I appreciate your input and encourage discussions that contribute to the improvement of open-source projects like Postfix. Best regards, Matthias Schneider - Ursprüngliche Mail - Von: "Jaroslaw Rafa via Postfix-users" An: "postfix-users" Gesendet: Mittwoch, 24. Januar 2024 12:18:54 Betreff: [pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check Dnia 24.01.2024 o godz. 08:20:33 Matthias Schneider via Postfix-users pisze: > > Upon reviewing the code, it appears there are only one limit on > vstring_sprintf, three limits on msg_info in the code, whereas the rest of > the %.200s limits are present on msg_warn lines. My request stems from > the need to log more comprehensive information, such as > Authentication-Results headers or DKIM Signatures, which often exceed the > current 200-character limit. ( they header key 'Authentication-Results: ' > is using 24 chars already) If you found the limits in the code, just change them to a value that suits you and rebuild Postfix for yourself. It's one of the advantages of being open source, anyway. -- 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 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
1) You can log full headers with a Milter. You will run into the length limit of the syslog() client (historically, 2 kBytes) before the Milter protocol limit (64 kBytes) which is less than the Postfix header_size_limit (default: 102400). 2) You can uniqely identify all Postfix transactions with a long Postfix queue ID. There is no need to log the same large header upon entry and exit. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: relay specific domain
Barbara M.: > On Tue, 23 Jan 2024, Wietse Venema via Postfix-users wrote: > > > Barbara M. via Postfix-users: > >> Jan 23 00:11:34 auth postfix/smtpd[188544]: NOQUEUE: reject: RCPT from > >> wp-host1.xyz.com[4.3.2.1]: 554 5.7.1 : Relay > >> access denied; from= to= > >> proto=ESMTP helo= > > > > It this is this an INTERNAL DESTINATION, add it to main.cf:relay_domains. > > > >relay_domains = dom-redir.it, ... Or if your server is MX for that domain. See https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
Initially, I experimented with a Milter for logging the required headers, but I found that employing a larger %s printf value proved to be a more efficient solution. However, I'd like to point out that the default configuration for MaxMessageSize in rsyslog is often set to 8k, with the potential to increase it to 64k when using TCP. Therefore, the syslog aspect can handle larger messages effectively. The issue I've been grappling with is more centered around the 200-character limit in the %.200s format, rather than any limitations imposed by syslog. I already use long queue IDs for unique identification of Mail transactions, and that's totally fine, its just about to have the ability to log custom headers without a small size limit. The current limit is also missing in the header_checks documentation (i totally agree that there _must be_ a limit) I hope this provides a clearer perspective. Best regards, Matthias Schneider - Ursprüngliche Mail - Von: "Wietse Venema via Postfix-users" An: "Postfix users" Gesendet: Mittwoch, 24. Januar 2024 14:37:34 Betreff: [pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check 1) You can log full headers with a Milter. You will run into the length limit of the syslog() client (historically, 2 kBytes) before the Milter protocol limit (64 kBytes) which is less than the Postfix header_size_limit (default: 102400). 2) You can uniqely identify all Postfix transactions with a long Postfix queue ID. There is no need to log the same large header upon entry and exit. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
On Wed, Jan 24, 2024 at 03:10:03PM +0100, Matthias Schneider via Postfix-users wrote: > Initially, I experimented with a Milter for logging the required > headers, but I found that employing a larger %s printf value proved to > be a more efficient solution. However, I'd like to point out that the > default configuration for MaxMessageSize in rsyslog is often set to > 8k, with the potential to increase it to 64k when using TCP. > Therefore, the syslog aspect can handle larger messages effectively. Why is syslog the right medium for accurate message header recording? What sort of key/value pairs are you looking to extract from headers? When ~2 decades ago I implemented header logging (actually MIME-skeleton logging, that recorded also the header of all nested MIME parts), I recorded the MIME skeletons of each message (separated by blank lines) to a daily disk file. Syslog was not a good vehicle for faithful recording of message metadata. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Documentation on upgrade 2.10 to 3.5
Oops! I just realized that I sent this instead of saving it. Dang! So continuing my thoughts with item 4 ... 4) Probably not a PostFix question, but it is related. One big reason for doing an in-place upgrade is because I do not know how to move my mailbox from the old server to something new. Is that just a matter of copying a $HOME directory? I hate to mess with a working system. The current setup is not broken. The server has almost 300 days of uptime on it and has been running for most of ten years. Looking forward, though, I see in a year or two CentOS7 might become less and less usable, in much the same way that Windows XP is pretty much unusable now. I want to get ahead of that curve. It is probably worth noting that I have now converted all of my CentOS systems except the email server to AlmaLinux 9 using ELevate. There were a few glitches along the way, but it did work. The converted systems were a mix of CentSO7, 8 Stream and 9 Stream. Only one of them has any significant workload (VirtualBox host). The others are all test beds. Thanks! === Bill Gee On 1/21/24 15:44, Bill Gee wrote: Hello everyone - The time is finally coming when I have to do something with my Postfix server. I have several questions for the group. Background - Currently I have Postfix 2.10.1 running on CentOS7. It is rock-solid. If not for the coming EOL on CentOS7 I would leave it alone. The upgrade target I have chosen is AlmaLinux 9 which packages PostFix 3.5.9. This will be an in-place upgrade using ELevate and leapp. I ran "leapp preupgrade" on the system. It issued a raft of advice regarding the Postfix main.cf and master.cf files. The only other inhibitor is NFS. This system hosts quite a few other services including DHCP, DNS, DoveCot (from third party repository), Samba and NFS shares. My questions for this group: 1) Is there any documentation about moving from Postfix 2 to 3? I looked on the web site but saw nothing obvious. 2) The leapp output mentions a compatibility option. I think I need to use that. Is there documentation on it? 3) Would it be useful to set up a test machine (of which I have several) and try the configuration files on it? I think there is no good way to actually run messages through it, but I can at least see if the Postfix service starts. 4) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
On Wed, Jan 24, 2024, Wietse Venema via Postfix-users wrote: > 1) You can log full headers with a Milter. You will run into the > length limit of the syslog() client (historically, 2 kBytes) before > the Milter protocol limit (64 kBytes) which is less than the Postfix Just FYI: That limit can be increased to 256K or even 1M if _FFR_MDS_NEGOTIATE is used for libmilter (and the MTA). ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Documentation on upgrade 2.10 to 3.5
On Wed, Jan 24, 2024 at 09:38:06AM -0600, Bill Gee via Postfix-users wrote: > > 1) Is there any documentation about moving from Postfix 2 to 3? I > > looked on the web site but saw nothing obvious. The RELEASE NOTES: https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-2.11 https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.0 https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.1 https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.2 https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.3 https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.4 https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.5 > > 2) The leapp output mentions a compatibility option. I think I need to > > use that. Is there documentation on it? https://www.postfix.org/postconf.5.html#compatibility_level https://www.postfix.org/COMPATIBILITY_README.html > > 3) Would it be useful to set up a test machine (of which I have several) > > and try the configuration files on it? I think there is no good way to > > actually run messages through it, but I can at least see if the Postfix > > service starts. Your choice. > 4) Probably not a PostFix question, but it is related. One big reason for > doing an in-place upgrade is because I do not know how to move my mailbox > from the old server to something new. Is that just a matter of copying a > $HOME directory? What you copy rather depends on where mail is stored. If you turn off incoming mail and no user is able to modify their mailbox (delete messages, ...) then copying the files to corresponding locations on a new system will work. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
Claus Assmann via Postfix-users: > On Wed, Jan 24, 2024, Wietse Venema via Postfix-users wrote: > > 1) You can log full headers with a Milter. You will run into the > > length limit of the syslog() client (historically, 2 kBytes) before > > the Milter protocol limit (64 kBytes) which is less than the Postfix > > Just FYI: That limit can be increased to 256K or even 1M if > _FFR_MDS_NEGOTIATE is used for libmilter (and the MTA). I should check my claims before posting. - The 64kB limit is for Postfix when sending a body chunk to a Milter. It does not apply to headers. - When Postfix sends a header label and value to a Milter, the combined length has to fit into an unsigned 32-bit integer (length includes null terminators). That limit is inherent to the types used. - Postfix puts a limit of INT_MAX/2 on the payload size of a response from a Milter. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Documentation on upgrade 2.10 to 3.5
On Wed, Jan 24, 2024 at 11:17:16AM -0500, Viktor Dukhovni via Postfix-users
wrote:
> > > 2) The leapp output mentions a compatibility option. I think I need to
> > > use that. Is there documentation on it?
>
> https://www.postfix.org/postconf.5.html#compatibility_level
> https://www.postfix.org/COMPATIBILITY_README.html
The native compatibility level for Postfix 3.0 through 3.5 is "2". But
the parameter defaults to "0". You need to explicitly set it to "2",
once you've either accepted the new defaults, or chosen explicit
overrides.
main.cf:
compatibility_level = 2
# Set non-default values for any of the below, only as-needed.
# append_dot_mydomain = ???
# mynetworks_style = ???
# smtpd_relay_restrictions = ???
# relay_domains = ???
# ?smtputf8_enable = ???
In Postfix 3.6 the syntax changed and it became "3.6", which is still
the level in the latest 3.9 snapshots. There are very few parameters
whose defaults changed incompatibly. The current list is:
append_dot_mydomain = ${{$compatibility_level}
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
Hi Victor, Thank you for diving into this topic. Using a Milter is an option, but it often involves correlating information from both the milter process and the log for a comprehensive view. For example, capturing TLS details from both the smtp client process and smtpd pid, along with recipient information and specific Headers is crucial. The proposed configurable header key/value limit would simplyfy this process. As far as I know, there are currently no other supported protocols for event streaming. Therefore, relying on syslog (nearly real-time) or reading logs from a file (with some delay) remains the most effective solution for obtaining delivery information. Best regards, Matthias Schneider - Ursprüngliche Mail - Von: Viktor Dukhovni via Postfix-users An: postfix-users@postfix.org Gesendet: Wed, 24 Jan 2024 16:38:05 +0100 (CET) Betreff: [pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check On Wed, Jan 24, 2024 at 03:10:03PM +0100, Matthias Schneider via Postfix-users wrote: > Initially, I experimented with a Milter for logging the required > headers, but I found that employing a larger %s printf value proved to > be a more efficient solution. However, I'd like to point out that the > default configuration for MaxMessageSize in rsyslog is often set to > 8k, with the potential to increase it to 64k when using TCP. > Therefore, the syslog aspect can handle larger messages effectively. Why is syslog the right medium for accurate message header recording? What sort of key/value pairs are you looking to extract from headers? When ~2 decades ago I implemented header logging (actually MIME-skeleton logging, that recorded also the header of all nested MIME parts), I recorded the MIME skeletons of each message (separated by blank lines) to a daily disk file. Syslog was not a good vehicle for faithful recording of message metadata. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
On Wed, Jan 24, 2024 at 08:27:53PM +0100, Matthias Schneider via Postfix-users wrote: > Using a Milter is an option, but it often involves correlating > information from both the milter process and the log for a > comprehensive view. Everything of interest can be added as a message header. > For example, capturing TLS details from both the smtp client process > and smtpd pid, along with recipient information and specific Headers > is crucial. You can PREPEND the TLS details for inspection by a milter. Why is this "crucial"? Postfix SMTP server TLS logging is fairly terse. Other than that TLS was used, what is so crucial to correlate with message headers? > As far as I know, there are currently no other supported protocols for > event streaming. Therefore, relying on syslog (nearly real-time) or > reading logs from a file (with some delay) remains the most effective > solution for obtaining delivery information. A milter can stream its findings to some central collection point using any protocol of its choice, including syslog. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
> Viktor Dukhovni via Postfix-users : > > On Wed, Jan 24, 2024 at 08:27:53PM +0100, Matthias Schneider via > Postfix-users wrote: > >> Using a Milter is an option, but it often involves correlating >> information from both the milter process and the log for a >> comprehensive view. > > Everything of interest can be added as a message header. Just to add another view, I guess the op wants to solve a problem like this: Consider a mailflow utility that correlates postfix logs according to queue ids and stores them to a database. A webinterface allows users to retrieve delivery information for their email addresses themselves. Postfix logging is sufficient to see if a delivery succeeded (250 OK - often including some form of queue-id) or bounced and sometimes this functionality is very convenient for users, that normally do not have access to maillogs. As the amount of email increases it can be difficult to distinguish mails to or from a correspondent. In this case it would help a lot to display the subject as well but that's not part of envelope data. Therefore it's convenient to log it using a header_check like /^Subject: / -> INFO, which is subject to the 200 bytes limit. As headers consist of 7-bit ASCII only, UTF8-Characters like Umlauts or Emojis must be encoded (qp/base64), so 200 bytes sometimes is not equal to 200 chars and might result in truncated subject lines. Programming a milter just to display a complete subject line would be quite time-consuming. Therefore I think the op considers a higher or configurable limit helpful. Best regards, Gerald ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check
Hi Gerald, Thank you for providing an insightful perspective on the matter, and you've hit the nail on the head. Indeed, the 200-byte limit not only impacts the display of subjects but also affects headers with security content, such as Authentication-Results. A Milter cannot get any information about the smtp delivery attempts, only the TLS infomation from the recieving smtpd process. To obtain a full picture, we end up having to join the in-session information from the Milter to the log, which is asynchronous and can delay final delivery status for several days. In light of this, a higher or configurable limit in the log would simplify the process, eliminating the need for complex join operations between two separate logs. Considering the various use cases and scenarios, maintaining the 200-char limit as the default while allowing users to configure it based on their specific needs sounds like a pragmatic solution. This approach would provide flexibility for users who wish to log extensive information, such as antispam symbols in headers. Best regards, Matthias Schneider - Ursprüngliche Mail - Von: "Gerald Galster via Postfix-users" An: "postfix-users" Gesendet: Mittwoch, 24. Januar 2024 23:21:10 Betreff: [pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check > Viktor Dukhovni via Postfix-users : > > On Wed, Jan 24, 2024 at 08:27:53PM +0100, Matthias Schneider via > Postfix-users wrote: > >> Using a Milter is an option, but it often involves correlating >> information from both the milter process and the log for a >> comprehensive view. > > Everything of interest can be added as a message header. Just to add another view, I guess the op wants to solve a problem like this: Consider a mailflow utility that correlates postfix logs according to queue ids and stores them to a database. A webinterface allows users to retrieve delivery information for their email addresses themselves. Postfix logging is sufficient to see if a delivery succeeded (250 OK - often including some form of queue-id) or bounced and sometimes this functionality is very convenient for users, that normally do not have access to maillogs. As the amount of email increases it can be difficult to distinguish mails to or from a correspondent. In this case it would help a lot to display the subject as well but that's not part of envelope data. Therefore it's convenient to log it using a header_check like /^Subject: / -> INFO, which is subject to the 200 bytes limit. As headers consist of 7-bit ASCII only, UTF8-Characters like Umlauts or Emojis must be encoded (qp/base64), so 200 bytes sometimes is not equal to 200 chars and might result in truncated subject lines. Programming a milter just to display a complete subject line would be quite time-consuming. Therefore I think the op considers a higher or configurable limit helpful. Best regards, Gerald ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
