Gerd Hoerst via Postfix-users:
> Hi !
>
> in my main.cf
>
> non_smtpd_milters = $smtpd_milters
>
> is already configured...
>
> Whereelse can i check ?
non_smtpd_milters emulates an SMTP client. It pretends that mail
arrives from localhost/127.0.0.1 via ESMTP.
Your Milter needs to be willing
Phil Biggs via Postfix-users:
> postfix/dnsblog 17448 - - warning: dnsblog_query: lookup error for DNS query
> 137.52.152.104.list.dnswl.org: Host or domain name not found. Name service
> error for name=137.52.152.104.list.dnswl.org type=A: Host not found, try
> again
>
> As later lookups
Phil Biggs via Postfix-users:
>
> Back in June of 2023 I added list.dnswl.org to postscreen.
>
> Over time I've noticed that I get the occasional lookup error like this:
>
> postfix/dnsblog 17448 - - warning: dnsblog_query: lookup error for DNS query
> 137.52.152.104.list.dnswl.org: Host or
Viktor Dukhovni via Postfix-users:
> On Thu, Jan 11, 2024 at 03:53:35PM +0100, natan via Postfix-users wrote:
> > Hi Wietse Have you thought about postfix repo for Debian, just like dovecot
> > has for his relase ?
> >
>
> What is a "Postfix repo for Debian"? Do you mean binary release
>
natan via Postfix-users:
> Hi Wietse Have you thought about postfix repo for Debian, just like
> dovecot has for his relase ?
>
> I'm asking by the way
Yes. It will happen some time.
Wietse
___
Postfix-users mailing list --
Ralf Hildebrandt via Postfix-users:
> > Would it be possible to log at least the queue-id as well? Also sender
> > and/or recipient would be nice ;-) Or is it for security that no more
> > information is logged?
>
> 20240104
>
> Cleanup: when the Postfix SMTP server rejects bare ,
> log the
Ralf Hildebrandt via Postfix-users:
> http://ftp.porcupine.org/mirrors/postfix-release/index.html
Forgot to push these. It's uploadin now, but I am on public WIFI.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To
Viktor Dukhovni via Postfix-users:
> On Wed, Jan 10, 2024 at 05:38:37PM +0200, Nikolaos Milas via Postfix-users
> wrote:
>
> > On 10/1/2024 5:24 ?.?., Matus UHLAR - fantomas via Postfix-users wrote:
> >
> > > If you use postscreen, remove reject_rbl_client from *_restrictions.
> > >
> > >
Also on-line at https://www.postfix.org/false-smuggling-claims.html
and linked from https://www.postfix.org/smtp-smuggling.html
I expect to do a stable release update in a week or so, that will
include non-emergency fixes that I wanted to release in December,
and that silences false vulnerability
Michael Grimm via Postfix-users:
> > Postfix has a "rule based language" for receiving mail, but there
> > is no such thing for outbound deliveries.
>
> I am only curious of how much functionality would be needed for
> that?
There is zero code, so that would be a lot of work. To give an
example,
Michael Grimm via Postfix-users:
> [FreeBSD 14-STABLE, postfix 3.8.4, dovecot 2.3.21, rspamd 3.7.5]
>
> Hi
>
> Sometimes outgoing mail is deferred due to "reputational issues"
> at the receiving side. These "reputational issues" mostly concerned
> my IP6 addresses, thus I removed IP6 mailing
Damian via Postfix-users:
> If I remember correctly, on the wire there was \r\n\r\n.\r\r\n
That is not a viable spoofing attack pattern.
To understand why, recall that an authenticated attacker sends an
email message to email service A, that contains a non-standard
End-of-DATA in the middle
People are welcome to test tools against postfix-3.9-20240106.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
Damian:
> If I remember correctly, on the wire there was \r\n\r\n.\r\r\n
Viktor Dukhovni:
> Does that also need to be more strict? :-(
Indeed, and as usual the fix is trivial. This process is backwards,
it is what we get with publication before the analysis, tooling,
and software fixes are
BTW All smuggling tests are invalid when the client is allowlisted
with smtpd_forbid_bare_newline_exclusions (default: $mynetworks).
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to
Wietse Venema via Postfix-users:
> Damian via Postfix-users:
> > > The recommen
Damian via Postfix-users:
> > The recommended settings are:
> >
> >
> >
Gerben Wierda via Postfix-users:
> Is
>
> smtpd_data_restrictions =
> reject_unauth_pipelining,
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_multi_recipient_bounce
>
> enough to stop this small(?) risk (before I manage to upgrade)?
Please see
Peter Wienemann via Postfix-users:
> Dear Wietse,
>
> thanks for your careful review.
>
> On 2024-01-05 16:11:56 +0100, Wietse Venema via Postfix-users wrote:
> > Peter Wienemann via Postf
Peter Wienemann via Postfix-users:
> Hi Viktor,
>
> On 2024-01-02 18:13:22 +0100, Viktor Dukhovni via Postfix-users wrote:
> > That said, indeed the documentation is not explicit on this point, one
> > has to read "between the lines". If your technical writing skills are
> > adequate, perhaps
Geert Hendrickx via Postfix-users:
> On Thu, Jan 04, 2024 at 10:36:23 -0500, Wietse Venema via Postfix-users wrote:
> > Wietse Venema via Postfix-users:
> > > Geert Hendrickx via Postfix-users:
> > > > I just found an unexpected side effect of this particular co
Wietse Venema via Postfix-users:
> Geert Hendrickx via Postfix-users:
> > On Thu, Dec 21, 2023 at 07:51:31 -0500, Wietse Venema via Postfix-users
> > wrote:
> > > * With all Postfix versions, "smtpd_data_restrictions =
> > > reject_unauth_pipel
Geert Hendrickx via Postfix-users:
> On Thu, Dec 21, 2023 at 07:51:31 -0500, Wietse Venema via Postfix-users wrote:
> > * With all Postfix versions, "smtpd_data_restrictions =
> > reject_unauth_pipelining" will stop the published exploit.
>
>
> Hi
&g
Wietse Venema via Postfix-users:
> Emmett Culley via Postfix-users:
> > I have a long time running Postfix server (version 2.10) where I need to
> > send from specific IP addresses for some virtual domains.
> >
> > I have it working, sort of. If I send email
Emmett Culley via Postfix-users:
> I have a long time running Postfix server (version 2.10) where I need to send
> from specific IP addresses for some virtual domains.
>
> I have it working, sort of. If I send email from this server to another
> server running postfix, it all seems to work.
toganm--- via Postfix-users:
> WVvP> To integrate Dovecot, see Dovecot documentation for examples.
>
> That does not help because dovecot is not running on the same machine.
It DOES NOT matter where Dovecot runs.
Wietse
___
Postfix-users
> mailbox_transport = lmtp:172.16.0.216:24
> virtual_transport = lmtp:172.16.0.216:24
No more random experiments.
To integrate Dovecot, see Dovecot documentation for examples.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
pgnd via Postfix-users:
> What config &/or build/install options are necessary to complete
> a non-interactive Postfix build, with no prior Postfix instance
> or configs needed?
It is probably a missing "postconf -c /config/dir/name" option.
For example, to use the files in the
"Hakon Alstadheim wrote:
>Just FYI, I got postfix 3.7.9-0+deb12u1 from bookworm-updates (i.e.
>Debian) today.
Scott Kitterman:
> For those still using Debian Bullseye (oldstable), postfix
> 3.5.23-0+deb11u1 is also available from bullseye-updates. Both
> of these stable updates were released
John R. Levine via Postfix-users:
> On Fri, 29 Dec 2023, Wietse Venema wrote:
> > The real reason is that it's easier to convince a few delinquent
> > MTA implementors, than an IETF working group.
>
> The WG isn't opposed but we have a very long list of nits to clean up
John R. Levine via Postfix-users:
> On Fri, 29 Dec 2023, Theodore Ts'o wrote:
> > Of course, implementing a HELP command is also not much work, so why
> > not?
>
> That's the conclusion we came to in emailcore. It's so easy to implement
> that even though it's been a long time (if ever) since
Peter Wienemann via Postfix-users:
> Dear Wietse,
>
> On 2023-12-15 22:17:08 +0100, Wietse Venema via Postfix-users wrote:
> > Peter Wienemann via Postfix-users:
> >> Thanks Wietse! Your pseudo-code clarifies the approach chosen by
> >> Postfix. What still r
Wietse Venema via Postfix-users:
> John Levine via Postfix-users:
> > Over in the IETF we're slowly working on updating RFC 5321.
> >
> > Today's topic is the HELP command. The current spec says that it is
> > mandatory to implment it. Most MTAs implement it by r
John Levine via Postfix-users:
> Over in the IETF we're slowly working on updating RFC 5321.
>
> Today's topic is the HELP command. The current spec says that it is
> mandatory to implment it. Most MTAs implement it by returning a fixed
> string, or something close to fixed, e.g., gmail's answer
Damian via Postfix-users:
> > It really does not matter much, but leaving BDAT enabled can help in
> > some cases. It is not necessary to go this deep down the rabbit hole.
>
> So what could be smuggled into a Postfix that defines
> "reject_unauth_pipelining" but does not define
>
Pedro David Marco:
> To my understanding, the Smuggled email contains SMTP data plus
> headers, plus body... , so what is the problem if filters check
> them as well?
Wietse:
> The problem is that Postfix receives TWO messages.
> https://www.postfix.org/smtp-smuggling.html#impact
Pedro David
Pedro David Marco via Postfix-users:
> To my understanding, the Smuggled email contains SMTP data plus
> headers, plus body... , so what is the problem if filters check
> them as well?
The problem is that Postfix receives TWO messages.
https://www.postfix.org/smtp-smuggling.html#impact
Dmitry Katsubo via Postfix-users:
> Dear Postfix team,
>
> In some rare cases when OS is CPU-loaded, the log is overflowed with the
> following messages from Postfix, which fills up log space very quickly:
>
> 2023-12-24 18:04:41.016972 postfix/tlsmgr[105819]: warning: end-of-input
> while
Geert Hendrickx via Postfix-users:
> On Sat, Dec 23, 2023 at 18:09:10 -0500, Wietse Venema via Postfix-users wrote:
> > Note that only the encapsulating message can contain a DKIM signature
> > by the authenticated sender's domain. The smuggled message caannot
> > con
John D'Orazio via Postfix-users:
> I believe some users are in fact confusing DMARC and DKIM. DMARC is a
> policy that lets receiving servers know how to deal with mail that seems to
> be coming from your server but has *not* passed SPF and DKIM checks. From
> the Google support forum:
>
> DMARC
Bill Sommerfeld via Postfix-users:
> On 12/22/23 17:30, Vijay S Sarvepalli via Postfix-users wrote:
> > Arguably the second server is at fault
> > here for "SPF" signing two emails, nevertheless the vulnerability is due
> > to the combinatorial or Composition Attack as Wietse has identified.
>
Tim Weber via Postfix-users:
> I think this is a very good way to look at it, and a helpful lesson
> from this situation. Especially since, reading the article as it
> was published, it is obvious that SEC must have known the impact
> to Postfix and Sendmail. I understand their urge to notify
Peter Uetrecht via Postfix-users:
> Hello everyone,
>
> I need an easy way to add a custom header that depends on the domain part
> of the envelope rcpt to. If the receiving domain matches the custom header
> should be added. I know about header_checks, but that can?t be used because
> the
Wietse Venema via Postfix-users:
> Wietse Venema via Postfix-users:
> > Tim Weber via Postfix-users:
> > > Hi Wietse,
> > >
> > > thanks for getting back to me so quickly. Please rest assured that
> > > I'm not looking for someone to blame. My motivat
[An on-line version of this announcement will be available at
https://www.postfix.org/announcements/postfix-3.5.23.html]
Fixed with Postfix 3.5.23:
* Security: this release adds support to defend
against an email spoofing attack (SMTP smuggling) on
recipients at a Postfix server. For
Wietse Venema via Postfix-users:
> Tim Weber via Postfix-users:
> > Hi Wietse,
> >
> > thanks for getting back to me so quickly. Please rest assured that
> > I'm not looking for someone to blame. My motivation is to try to
> > find out whether SEC's release proce
[An on-line version of this announcement will be available at
https://www.postfix.org/announcements/postfix-3.6.13.html]
Fixed with Postfix 3.6.13:
* Security: this release adds support to defend
against an email spoofing attack (SMTP smuggling) on
recipients at a Postfix server. For
Tim Weber via Postfix-users:
> Hi Wietse,
>
> thanks for getting back to me so quickly. Please rest assured that
> I'm not looking for someone to blame. My motivation is to try to
> find out whether SEC's release process really has been as responsible
> as they claim:
Sorry, you are talking to
[An on-line version of this announcement will be available at
https://www.postfix.org/announcements/postfix-3.7.9.html]
Fixed with Postfix 3.7.9:
* Security: this release adds support to defend
against an email spoofing attack (SMTP smuggling) on
recipients at a Postfix server. For
We had no indication thet there was a succesful spoofing attack
that required the composition of TWO servers with specific differences
in their handling of non-standard line endings in SMTP.
Otherwise, we would certainly have convinced SEC Consult to change
their time schedule until after people
[Reposted, as I din't see the response show up]
CERT/CC reached out to Postfix developers. At no point were we made
aware that there was a successful SPF spoofing attack that required
the combination of TWO email services with SPECIFIC DIFFERENCES in
the way they handle line endings other than .
[An on-line version of this announcement will be available at
https://www.postfix.org/announcements/postfix-3.8.4.html]
Fixed with Postfix 3.8.4:
* Security: this release adds support to defend
against an email spoofing attack (SMTP smuggling) on
recipients at a Postfix server. For
The www.postfix.org home page links to my personal home page.
My personal home page contains my email address and PGP key.
There are no process requirements, just talk to me.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To
Viktor Dukhovni via Postfix-users:
> On Thu, Dec 21, 2023 at 04:29:20PM -0500, Wietse Venema via Postfix-users
> wrote:
>
> > > > https://gitlab.com/ohisee/block-shodan-stretchoid-census
> > >
> > > I feel no particular urge to block them.
> >
>
Viktor Dukhovni via Postfix-users:
> On Thu, Dec 21, 2023 at 03:08:57PM -0500, pgnd via Postfix-users wrote:
>
> > > This even includes "shodan" looking
> >
> > ugh. shodan.
> >
> > this can help a bit
> >
> > https://gitlab.com/ohisee/block-shodan-stretchoid-census
>
> I feel no particular
Kim Sindalsen via Postfix-users:
> I'm reading that either " smtpd_data_restrictions =
> reject_unauth_pipelining" or "smtpd_forbid_unauth_pipelining = yes" should
> *work* for shor-term workaround, right?
They look for the same thing but at different times.
> I've had data-restrictions for
natan:
> https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
Wietse:
> See:https://www.postfix.org/smtp-smuggling.html
natan:
> reject_unauth_pipelining in: smtpd_data_restrictions
> or maybe only in smtpd_end_of_data_restrictions ?
Then, Postfix will have to receive
natan via Postfix-users:
> Hi
> I found today
>
> https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
See: https://www.postfix.org/smtp-smuggling.html
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe
Till W. via Postfix-users:
[ Charset ISO-8859-1 converted... ]
> Dear team,
> we enabled smtpd_forbid_unauth_pipelining in our Postfix, but unfortunately
> it still accepts \n.\n (.) as EOD. This is our configuration in
> main.cf:
>
> smtpd_forbid_unauth_pipelining = yes
>
Till W. via Postfix-users:
> Dear team,
> we enabled smtpd_forbid_unauth_pipelining in our Postfix, but unfortunately
> it still accepts \n.\n (.) as EOD. This is our configuration in
> main.cf:
>
Of course it does. It is supposed to reject message content that is
received IN THE SAME PACKET
[A longer and updated version of this text may be found at
https://www.postfix.org/smtp-smuggling.html]
SUMMARY
As part of a non-responsible disclosure process, SEC Consult has
published an email spoofing attack that involves a composition of
email services with specific differences in the way
Phil Biggs via Postfix-users:
> Thursday, December 21, 2023, 10:05:41 AM, Wietse Venema via Postfix-users
> wrote:
>
> > Viktor Dukhovni via Postfix-users:
> >> smtpd_data_restrictions=reject_unauth_pipelining.
>
> > That will, as Viktor observes, on port
Viktor Dukhovni via Postfix-users:
> smtpd_data_restrictions=reject_unauth_pipelining.
That will, as Viktor observes, on port 25 mitigate the published attack.
I'll update the text at https://www.postfix.org/smtp-smuggling.html
Wietse
___
Wietse Venema via Postfix-users:
> As part of a non-responsible disclosure process, SEC Consult has
> published an email spoofing attack that involves a composition of
> different mail service behaviors with respect to broken line endings.
Also on-line at httpps://www.postfix
Wietse:
>A Postfix implementation will have to work for other use cases,
>too. It would be good to know how nginx in forward proxy mode
>handles or ignores client address and port info, now and in the
>forseeable future.
Joachim Lindenberg via Postfix-users:
> I double checked documentation at
>
Linkcheck via Postfix-users:
> On 20/12/2023 3:51 pm, Wietse Venema via Postfix-users wrote:
> > "smtpd_forbid_unauth_pipelining = yes
>
> I tried that (3.7.6) and got...
> warning: unknown smtpd restriction: "smtpd_forbid_unauth_pipelining"
>
> Where sh
As part of a non-responsible disclosure process, SEC Consult has
published an email spoofing attack that involves a composition of
different mail service behaviors with respect to broken line endings.
A short-term fix may deployed now, before the upcoming long holiday:
- Postfix 3.9 (stable
Wietse Venema via Postfix-users:
> Viktor Dukhovni via Postfix-users:
> [. in BDAT payload]
> > > If my suspicion is correct, a dwnstream server may receive the
> > > normal and suggled content as two separate messages.
> >
> > I don't see why. It shouldn'
Viktor Dukhovni via Postfix-users:
[. in BDAT payload]
> > If my suspicion is correct, a dwnstream server may receive the
> > normal and suggled content as two separate messages.
>
> I don't see why. It shouldn't matter how Microsoft's MTA ends up
> with a message containing "." or (.), so long
Wietse
> This means that nginx ignores the source port in the proxy protocol.
> Is that documented somewhere?
Joachim Lindenberg:
> It does not ignore it, the variable exists. My configuration doesn't
> use it for outbound, as plenty of ports are in used, and dynamic
> is ok for the use case.
Joachim Lindenberg via Postfix-users:
> >Is there a technical spec of that protocol? Does it look in any
> way like HaProxy protocol version 1 or 2? What are the source IP
> address and port?
> https://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#:~:text=Enables%20the%20PROXY%20protocol
>
John Levine via Postfix-users:
> This paper describes a clever hack that uses defective line endings to embed
> a second SMTP session inside a first one, which has the practical effect
> of letting you send fake authenticated mail from anyone else who uses the
> same mail system you do. If that
Joachim Lindenberg via Postfix-users:
> >How is this used to connect to an arbitrary destination on the Internet?
>
> This is probably nginx implementation specific, but one can configure a
> stream proxy as follows:
>
> stream {
> server {
> listen 10.200.200.1:12345
Wietse Venema via Postfix-users:
> Rejecting stray and while receiving mail will prevent
> Postfix from receiving "smuggled" SMTP commands after a malformed
> end-of-data sequence, and thus, it will prevent Postfix from
> forwarding them.
>
> So would rejectin
Joachim Lindenberg via Postfix-users:
> I'd like to challenge that. (HA) Proxy protocol essentially implies
> to connect to another configured address and then prepend a string
> with connection info to the TCP stream.
Indeed. The (HA) proxy accepts a connection from an arbitrary client
IP
Wietse;
> inside Postfix -reverse haproxy-> remote MTAs in the Internet
> That is currently not implemented, and no design exists.
Joachim Lindenberg via Postfix-users:
> Hello Wietse,
> Yes, exactly, no second instance. Ok, implies I haven't overlooked
> something. Is this an option you are
Wietse:
> - Don't accept mail with a broken end-of-data sequence (Postfix
> currently allows zero or more followed by ). Or more
> generally, don't accept or that aren't part of a
> sequence. Postfix does not support BDAT with BINARYMIME, so there
> is no valid use of stray or bytes.
Vijay
Viktor Dukhovni via Postfix-users:
> - Postfix 3.9 (pending official release soon), rejects unuthorised
> pipelining by default: "smtpd_forbid_unauth_pipelining = yes".
>
> - Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same supporting
> code as 3.9 snapshots, but the
Bill Cole via Postfix-users:
> On 2023-12-18 at 11:31:47 UTC-0500 (Mon, 18 Dec 2023 16:31:47 +)
> Vijay S Sarvepalli via Postfix-users
> is rumored to have said:
>
> > Hello Viktor, Wietse,
> > (I am copying the Postfix community as the report is out in the public
> > now)
> >
> > First of
Kristoff via Postfix-users:
> Dec 17 04:32:05 smtp postfix/smtp[725772]: 4F58E6A10A0:
> to=u...@example.com,
> orig_to=SRS0=zxmM=H4=example.com=u...@ourhobbyclubdomain.com,
> relay=mail.example.com[A.B.C.D]:25, delay=0.16, delays=0.05/0/0.08/0.02,
> dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
Did you mean instead of
inside Postix -> outside Postfix -> remote MTAs in the Internet
Use
inside Postfix -reverse haproxy-> remote MTAs in the Internet
Theat is currently not implemented, and no design exists.
Wietse
___
POstfix does not use he sender email addres for relay permission
checks, unless *you* configired Postfix to do so.
For further support we need output from:
postconf -n
postconf -P
and logging NON-DEBUG from postfix smtpd (the server).
Wietse
saunders.nicholas--- via Postfix-users:
> /etc/postfix/sasl/sasl_passwd is where I have it. The example is:
That file is mainained by Cyrus SASL. Questions about implementation
details are bettere asked there.
Wietse
___
Postfix-users mailing
Peter Wienemann via Postfix-users:
> On 2023-12-12 15:51:58 +0100, Wietse Venema via Postfix-users wrote:
> > Peter Wienemann via Postfix-users:
> >> Dear Postfix experts,
> >>
> >> checking the documentation for the relayhost parameter [0] I find no
> &g
Steffen Nurpmeso via Postfix-users:
> Wietse Venema via Postfix-users wrote in
> <4sr8hc44p7zj...@spike.porcupine.org>:
> |Currently, Postfix does not send the Postfix-generated Received:
> |header to Milters, because that is how Sendmail works, that is what
> ...
>
Jiri Bourek via Postfix-users:
> My response was quoting the message that mentions the patch changing
> behaviour of PREPEND - message from 10 Dec 2023 19:04:55 -0500 (EST). I
> now spotted the "With this, no change is needed to the Postfix SMTP
> daemon" sentence in message from 12 Dec 2023
Currently, Postfix does not send the Postfix-generated Received:
header to Milters, because that is how Sendmail works, that is what
Milters expect, and changing the behavior unilaterally would break
compatibility with a large installed base.
This information would improve the Milter's analysis.
Jiri Bourek via Postfix-users:
> Example for current behaviour:
>
> Received-SPF: Pass *<-- only we could've add this*
> Received: from some.server by this.server
>
> With the new one:
>
> Received: from some.server by this.server
> Received-SPF: Pass *<-- did scammer add it or did we?*
Once
lists--- via Postfix-users:
> I have a user with an 'old' printer/scanner who wants to scan/email scans
> from the home located device
>
> printer offers:
> machine email address:
> SMTP server:
> SMTP server port:
>
> send authentication: PoPb4SMTP/SMTP AUTH: Plain/Login/CRAM-MD5/Auto
If the
Carlos Velasco via Postfix-users:
> > Thus, the Postfix code that handles header update/delete requests
> > was still naively skipping the first header, making calls to delete
> > the prepended Received-SPF: header ineffective, and mis-directing
> > calls to delete the first Milter-visible
Carlos Velasco via Postfix-users:
>
> Wietse Venema via Postfix-users escribi? el 11/12/2023 a las 22:30:
> > Wietse Venema:
> >> Patch below.
> > Carlos Velasco:
> >> Tested patch against 3.8.3, now it works as expected. Thank you.
> >> No dupl
Peter Wienemann via Postfix-users:
> Dear Postfix experts,
>
> checking the documentation for the relayhost parameter [0] I find no
> indication how Postfix behaves in case of multiple relay hosts with
> multiple DNS entries. Let us assume the following setting:
for each destination d in
Carlos Velasco via Postfix-users:
> I think you are absolutely correct in your analysis.
> I've been looking over the code and, although there is a lot I
> still don't understand, your yesterday patch seems more a (good)
> workaround to the real problem.
> I also located the
Wietse Venema:
> Patch below.
Carlos Velasco:
> Tested patch against 3.8.3, now it works as expected. Thank you.
> No duplicated "Received-SPF" and *removing "Received" in position
> 1 is now not the own generated, is really the first one Received
> seen in the
lking here about breaking any compatibility, re-read the
> >> > messages.
>
> >Bill Cole via Postfix-users:
> >> What did I miss? Are you not asking for Postfix to support providing
> >> milters with a header that none of them expect and which no ot
Bill Cole via Postfix-users:
> On 2023-12-11 at 09:37:39 UTC-0500 (Mon, 11 Dec 2023 15:37:39 +0100)
> Carlos Velasco via Postfix-users
> is rumored to have said:
>
> > Bill Cole via Postfix-users escribi? el 11/12/2023 a las 15:31:
> >> On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023
Carlos Velasco via Postfix-users:
>
> Wietse Venema via Postfix-users escribi? el 11/12/2023 a las 1:11:
> > Patch below.
> Tested patch against 3.8.3, now it works as expected. Thank you.
> No duplicated "Received-SPF" and removing "Received" in posi
Patch below.
Wietse
--- /var/tmp/postfix-3.9-20231210/src/smtpd/smtpd.c 2023-10-12
11:34:40.0 -0400
+++ src/smtpd/smtpd.c 2023-12-10 18:52:56.0 -0500
@@ -3404,13 +3404,6 @@
}
/*
- * PREPEND message headers above our own Received: header.
- */
-
Wietse Venema via Postfix-users:
> Wietse:
> > I asked for a copy of the (headers of the) resulting message that
> > Postfix delivers.
> > - Does it have a Received-SPF header?
> > - Does it have two?
>
> Carlos Velasco:
> > 1. Deleting the header in th
Wietse:
> I asked for a copy of the (headers of the) resulting message that
> Postfix delivers.
> - Does it have a Received-SPF header?
> - Does it have two?
Carlos Velasco:
> 1. Deleting the header in the milter or doing nothing in the milter
> has the same result: final email has only 1
201 - 300 of 13108 matches
Mail list logo
