[pfx] Re: postfix does not add Return-Path if mail is missing it
On 2023-04-23 at 14:29:31 UTC-0400 (Sun, 23 Apr 2023 20:29:31 +0200) Benny Pedersen via Postfix-users is rumored to have said: Matus UHLAR - fantomas via Postfix-users skrev den 2023-04-23 16:43: On 23.04.23 11:19, Benny Pedersen via Postfix-users wrote: Subject: [pfx] postfix does not add Return-Path if mail is missing it imho a bug it's added in local if delivering to mbox or maildir: http://www.postfix.org/local.8.html its not in my case a local problem, its seen from remote mta (exim), i reported here in belive that this is a bug, i know envelope-from can be in received header aswell Return-Path should only be added by the final delivery agent. If the mail is being sent out to another MTA, it should NOT have a Return-Path on it. what will postfix do if both missing ?, I'm sure Viktor and/or Wietse with correct me if I'm wrong, but I'm fairly sure Postfix never cares about the presence of a Return-Path header *UNLESS* it is configured to strip an existing one out. It does not interpret existing Received headers. what will spf test do in spamassassin ? SA has multiple ways of figuring out the RFC5321MailFrom (a.k.a. envelope sender or return-path) value, which the MTA should provide to whatever glue you use to integrate SA. Some glue layers (e.g. MIMEDefang, MailMunge, and I expect any other milter) construct synthetic final delivery headers (Received, Delivered-To, Return-Path, etc.) to pass to SA. See the SA docs (and your glue docs, I guess...) for details. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postfix does not add Return-Path if mail is missing it
Matus UHLAR - fantomas via Postfix-users skrev den 2023-04-23 16:43: On 23.04.23 11:19, Benny Pedersen via Postfix-users wrote: Subject: [pfx] postfix does not add Return-Path if mail is missing it imho a bug it's added in local if delivering to mbox or maildir: http://www.postfix.org/local.8.html its not in my case a local problem, its seen from remote mta (exim), i reported here in belive that this is a bug, i know envelope-from can be in received header aswell what will postfix do if both missing ?, what will spf test do in spamassassin ? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
Matus UHLAR - fantomas via Postfix-users writes: > (...) > for envelope from, simple access map should be enough: > http://www.postfix.org/access.5.html > > and use DISCARD Ok. Thanks for the heads-up, Matus! Sincerely, Byung-Hee -- ^고맙습니다 _地平天成_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
Thanks Viktor: > welcome to the internet Yeah :) I've been here for 30 years. > unlikely to be productive I simply want to help others avoid my points of confusion, in the belief I am not a uniquirely incapable or unintelligent reader. I will say this: Irrespective of how well you understand postfix (as an expert) the docs have clearly resulted in a lot of confusion not only in me, but in others, as evidenced by erroneous alternative content that comes up when searching this topic and/or similar questions asked by others in other forums. Unfortunately, precisely because the "welcome to the internet," it's often a good idea to disambiguate demonstrated points of confusion and/or counteract easily found internet misinformation about the project, directly in the project docs. > @ In your original response you were probably narrowly thinking about a specific transport(5) map when you responded @ was not included in search, but here unless I misunderstand you, you verify that there are some tables where @domain.com is searched. In other words, you seem to agree the components that have statements such as "The tables are searched by the envelope sender address and @domain" do the table search differently than described in transport(5). Unfortunately, the doc for those components point readers to the transport(5) doc but only mention the @domain item in passing, leaving readers wondering about the semantics of that statement, given the examples in transport(5) go counter to the statement. "@domain" could have been written that way to highlight that "domain" refers to the part after the @ sign. I suggest transport(5) include a small note in the table of search examples/precedence to show examples relevant to the search order and for those components that include the @ sign, or that their docs point to a similar table specific to how search is performed for those components. > [ DUNNO is access(5) not transport(5) ] [] indicate paraphrasing The docs for sender_dependent_default_transport_maps seem to contradict you. They state "lookup result of DUNNO terminates the search without overriding the global default_transport parameter setting." so either you are mistaken or I am again misunderstanding either you or the docs. > [no scans] That makes sense for table formats that have indeterminate keys such as pcre, but the objection IMHO makes less sense relative to *results* in those tables. If an access(5) verb appears in a transport(5) result that seems detectable. That being said, it turned out "discard", though not a verb, *is* a valid transport that seems to be defined in default distributions of postfix, and operates like my proposed "blackhole" transport ... so that muddies the waters. Perhaps postfix should disallow transport names that match verbs for that reason. I think transport names are completely arbitrary, so doing that could avoid confusion. Finally, to prevent long or expensive startup any proposed "config sanity scans" could be limited by a timer or by a "total items scanned" counter. and be either selected or squelched by command line arg. Then, if the scan terminates early, it could generate a separate warning about "config sanity scan terminated early due to table size." Thanks again for your prior responses. I think I now understand things well enough to make progress. No need to respond unless you'd like to chat about this further. On Sat, Apr 22, 2023 at 8:58 PM Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> wrote: > On Sat, Apr 22, 2023 at 07:58:25PM -0700, Andrew Athan wrote: > > > If I understand it well enough I'll write and submit a doc PR. > > This is unlikely to be productive. > > > If I put all this together what I think I'm hearing is that transport_map > > overrides everything > > The transport(5) table has the highest priority for the components of > the (transport, nexthop) pair that it specifies. All the other sources > are fallback sources when either or both of the transport or nexthop are > not specified in transport(5). > > > So does sender_dependent_relayhost_maps contain mappings from keys to > > transport:nexthop values or to nexthop values? > > A "relayhost" is a host (i.e. a nexthop) so clearly not a transport > ("smtp", "lmtp", "local", ...). > > > I think what's generally missing in the transport(5) man page and any > docs > > I've read so far, is a description of the concept that what postfix is > > trying to do is to get to a fully resolved transport:nexthop PAIR. > > https://www.postfix.org/transport.5.html > > RESULT FORMAT >The lookup result is of the form transport:nexthop. The > transport >field specifies a mail delivery transport such as smtp or local. > The >nexthop field specifies where and how to deliver mail. > >The transport field specifies the name of a mail delivery > transport >(the first name of a mail delivery service entry in the Postfix > mas- >
[pfx] Re: postfix does not add Return-Path if mail is missing it
On 23.04.23 11:19, Benny Pedersen via Postfix-users wrote: Subject: [pfx] postfix does not add Return-Path if mail is missing it imho a bug it's added in local if delivering to mbox or maildir: http://www.postfix.org/local.8.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. I drive way too fast to worry about cholesterol. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
On 23.04.23 13:43, Byung-Hee HWANG via Postfix-users wrote: Andrew Athan via Postfix-users writes: (...) My goal is to silently discard all inbound mail from a certain domain. Or actually, I may wish to redirect all of that mail either to a flat file (similar to the proposed blackhole transport) or (...) Go with easy way. See header_checks. `man 5 header_checks` ;;; This [1] is real server conf files from my mail server. [1] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-0919 for envelope from, simple access map should be enough: http://www.postfix.org/access.5.html and use DISCARD -- 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. The early bird may get the worm, but the second mouse gets the cheese. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postfix does not add Return-Path if mail is missing it
Benny Pedersen via Postfix-users: > > imho a bug Insifficient ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] postfix does not add Return-Path if mail is missing it
imho a bug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org