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 comp
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 follo
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 compl
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 postfix-users-
Wietse Venema via Postfix-users:
> Damian via Postfix-users:
> > > The recommended
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 https:/
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 you
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 confi
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. Th
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 ma
> 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
T
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 $POSTFIXSOURCE/conf
"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 yest
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 cle
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 it
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 rema
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 i
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 a
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
> "smtpd_discard_
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 Marc
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
W
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 read
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
> > conta
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 Cisco
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 receive
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 mo
[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 b
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 rel
[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 b
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 th
[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 bac
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 h
[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 bac
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 years
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 t
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
> smtpd_discard_ehlo_key
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 as
[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 t
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
___
Postf
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 relea
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 sho
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 a
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. Does
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 sy
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 proxy_protocol;
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 addres
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 S
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 "smtpd_forbid_unau
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 a
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-us
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
> >&
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 19:
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 ag
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 pr
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 Received
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 duplicat
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 re
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 cleanup_header_done_cal
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
is talking 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 o
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 22:37:1
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 position
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 Received
Carlos Velasco via Postfix-users:
>
> Wietse Venema via Postfix-users escribi? el 10/12/2023 a las 21:53:
> > Carlos Velasco via Postfix-users:
> >> Wietse Venema via Postfix-users escribi? el 10/12/2023 a las 19:44:
> >>> Carlos Velasco via Postfix-users:
>
Carlos Velasco via Postfix-users:
> Wietse Venema via Postfix-users escribi? el 10/12/2023 a las 19:44:
> > Carlos Velasco via Postfix-users:
> >> *** And there is the milter, is custom made ***
> > You need to reduce complexity.
> >
> > - If you remove the Mi
Carlos Velasco via Postfix-users:
> *** And there is the milter, is custom made ***
You need to reduce complexity.
- If you remove the Milter, is the header still duplicated?
- If you keep the milter and rmeove the polocy lookup, is eom other
header duplicated?
Wietse
__
Carlos Velasco via Postfix-users:
> > That means you are somehow calling the policy server twice.
> >
> > You didn't mention what version of the SPF policy server you are
> > using. Recent versions (under the project name SPF Engine, since
> > it's not just a policy server anymore) also provide a
Carlos Velasco via Postfix-users:
> 2. Duplicated SMTP Access Policy Delegation
> This issue is related to headers too.
> I'm using pypolicyd-spf as policy daemon to check SPF. It is working fine.
> The execution happens before milter. This is ok.
> Prepended "Received-SPF" header by pypolicyd-spf
Juerg Reimann via Postfix-users:
> I have to following configuration:
>
> -- --
>
> /etc/postfix/main.cf:
> smtpd_recipient_restrictions =
> ...
> check_recipient_access hash:/etc/postfix/protected_destinations,
What is in the ...?
Wietse
__
Doug Hardie via Postfix-users:
> I am using postfix with postsrsd. Is there a way for postfix to
> log the from address as originally received? The only addresses
> I find in postfix's log are the converted addresses from postsrsd.
> Both addresses are logged by postsrsd, but there is no way to t
duluxoz via Postfix-users:
> Hi All,
>
> When using `postscreen_upstream_proxy_protocol = haproxy` is there
> anything "special" that needs to be specified to ensure the use of v2 of
> the haproxy protocol, or does postfix automatically detect which version
> of the haproxy protocol is in use?
401 - 500 of 9285 matches
Mail list logo
