[pfx] Re: distinguishing submission from smtp log lines

2025-01-09 Thread Greg Klanderman via Postfix-users
> On January 7, 2025 Viktor Dukhovni via Postfix-users > wrote: >> I found smtpd_service_name, and guessing I could use that to >> replace the part after '/'? Would changing that have any >> functional impact, or only the logs? > Yes, it would break tools like "collate" that you might

[pfx] distinguishing submission from smtp log lines

2025-01-07 Thread Greg Klanderman via Postfix-users
Hi, I just tried adding '-o syslog_name=postfix/submission' to master.cf for my submission port, as I would like to be able to distinguish log lines for the two smtpd ports. I had expected it to completely replace 'postfix/smtpd' at the beginning of the log line, but now see it only replaces 'p

[pfx] Re: documentation for tags that appear after 'disconnect from' log lines?

2025-01-02 Thread Greg Klanderman via Postfix-users
>>>>> On January 2, 2025 Bill Cole via Postfix-users >>>>> wrote: > On 2025-01-02 at 16:47:00 UTC-0500 (Thu, 02 Jan 2025 16:47:00 -0500) > Greg Klanderman via Postfix-users is rumored to > have said: >>>>>>> On January 2, 202

[pfx] Re: documentation for tags that appear after 'disconnect from' log lines?

2025-01-02 Thread Greg Klanderman via Postfix-users
>>>>> On January 2, 2025 Bill Cole via Postfix-users >>>>> wrote: > On 2025-01-01 at 20:13:35 UTC-0500 (Wed, 01 Jan 2025 20:13:35 -0500) > Greg Klanderman via Postfix-users is rumored to > have said: >> I just noticed a single unknown host is c

[pfx] Re: documentation for tags that appear after 'disconnect from' log lines?

2025-01-01 Thread Greg Klanderman via Postfix-users
>>>>> On January 1, 2025 Viktor Dukhovni via Postfix-users >>>>> wrote: > On Wed, Jan 01, 2025 at 08:13:35PM -0500, Greg Klanderman via > Postfix-users wrote: >> I'm fine with allowing a little probing, especially if the host >> doing so has

[pfx] Re: documentation for tags that appear after 'disconnect from' log lines?

2025-01-01 Thread Greg Klanderman via Postfix-users
>>>>> On January 1, 2025 Wietse Venema via Postfix-users >>>>> wrote: > Greg Klanderman via Postfix-users: >> >> Hello all and Happy New Year! >> >> Is there some documentation for the list of tags, their meanings, >> and the format

[pfx] Re: documentation for tags that appear after 'disconnect from' log lines?

2025-01-01 Thread Greg Klanderman via Postfix-users
> On January 1, 2025 Viktor Dukhovni via Postfix-users > wrote: > As the operator of a "responsible" SMTP survey engine: > https://stats.dnssec-tools.org/about.html > https://stats.dnssec-tools.org/ > that connects just a few times a day (once per IP address of an MX > host, wi

[pfx] documentation for tags that appear after 'disconnect from' log lines?

2025-01-01 Thread Greg Klanderman via Postfix-users
Hello all and Happy New Year! Is there some documentation for the list of tags, their meanings, and the format for the value after '=' for the 'disconnect from' log lines? For example: | disconnect from X[IP] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4 I believe auth=0/1 indicates that aut

Re: Postfix stable release 3.7.1 and legacy releases 3.6.6, 3.5.16, 3.4.26

2022-04-26 Thread Greg Klanderman
xp > package installed?" instead of "unsupported map type for this > operation". This happened with all non-dynamic map types (static, > cidr, etc.) that have no 'bulk create' support. Problem reported > by Greg Klanderman. Thank you Wietse! Greg

Re: match empty sender in hash: sender access map?

2022-04-13 Thread Greg Klanderman
>>>>> On April 10, 2022 Viktor Dukhovni wrote: > On Sun, Apr 10, 2022 at 02:27:33PM -0400, Greg Klanderman wrote: >> Quick question, what is the correct syntax to match an empty sender in >> a hash: sender access map (i.e. check_sender_access)? > This is natur

Re: match empty sender in hash: sender access map?

2022-04-13 Thread Greg Klanderman
>>>>> On April 13, 2022 Matus UHLAR <- fantomas > wrote: >>>>>>> On April 10, 2022 Bill Cole >>>>>>> wrote: >>> Right, because you do not need to run 'postmap' on regex or pcre maps. The >>> text &g

Re: match empty sender in hash: sender access map?

2022-04-12 Thread Greg Klanderman
> On April 10, 2022 Bill Cole > wrote: > Right, because you do not need to run 'postmap' on regex or pcre maps. The > text > format ios what Postfix uses for those types. Thank you Bill! Knowing that now, I see where postmap(1) states: | The postmap(1) command can query any support

match empty sender in hash: sender access map?

2022-04-10 Thread Greg Klanderman
Hi all, Quick question, what is the correct syntax to match an empty sender in a hash: sender access map (i.e. check_sender_access)? Somewhat related, if I have a regexp: map (header checks), like so: /^Subject:.*foo bar/ REJECT /^Subject:.*foo baz/ REJECT when it is postmap'd, it warns about

Re: relay restriction not working?

2020-08-21 Thread Greg Klanderman
> On August 21, 2020 Viktor Dukhovni wrote: >> * if smtpd_relay_restrictions has been set (not defaulted) evaluate it >> first > I mentioned this to Wietse recently. My instinct is to go with the > last option. Viktor, great! Thank you for the update.. Greg

Re: relay restriction not working?

2020-08-21 Thread Greg Klanderman
> On August 14, 2020 Viktor Dukhovni wrote: > This is of those rare cases where the documentation is now in error. In > order to improve backwards compatibility with postfix prior to 2.10, the > order of evaluation was changed in postfix-3.3-20180106 to evaluate the > recipient restrictions

Re: relay restriction not working?

2020-08-14 Thread Greg Klanderman
>>>>> On August 14, 2020 Viktor Dukhovni wrote: > On Fri, Aug 14, 2020 at 05:41:38PM -0400, Greg Klanderman wrote: >> smtpd_relay_restrictions is documented as being checked before >> smtpd_recipient_restrictions, > This is of those rare cases where the d

relay restriction not working?

2020-08-14 Thread Greg Klanderman
Hi, First thank you for all the work you do/have done on Postfix! I have been using Postfix for 15+ years to handle mail for a handful of my domains. I upgraded my mail server from Debian 8 to 10 a couple months ago, and was running 3.4.10-0+deb10u1 as of the time I last saw the issue below.