Ralf Hildebrandt via Postfix-users:
> Hi!
>
> I wonder if this is possible:
>
> If a PCRE/regexp style map is triggering, it can be quite hard to
> find out WHICH pattern actually caused the action.
>
> So maybe postmap (when invoked with "-b", "-h" or "-q key") could emit
> which regular expres
* Allen Coates via Postfix-users :
> > Better yet, don't be lazy, include a fingerprint string in your RHS
> > reject rule values.
> Postscreen doesn't have the option of unique RHS fingerprints; nonetheless,
> it would useful to see which (of several)
> ACLs was rejecting an incoming connectio
On 20/03/2024 13:17, Viktor Dukhovni via Postfix-users wrote:
> On Wed, Mar 20, 2024 at 01:42:16PM +0100, Ralf Hildebrandt via Postfix-users
> wrote:
>> Hi!
>>
>> I wonder if this is possible:
>>
>> If a PCRE/regexp style map is triggering, it can be quite hard to
>> find out WHICH pattern actua
On Wed, Mar 20, 2024 at 09:17:58AM -0400, Viktor Dukhovni via Postfix-users
wrote:
> With bash <(command) inline file syntax, make the RHS unique on the fly:
>
> $ keystr=...
> $ remap=/etc/postfix/...
> $ postmap -q "$keystr" pcre:<(perl -pe 's/$/ LINE $./ unless
> m{^(if|endif|#)?
On Wed, Mar 20, 2024 at 01:42:16PM +0100, Ralf Hildebrandt via Postfix-users
wrote:
> Hi!
>
> I wonder if this is possible:
>
> If a PCRE/regexp style map is triggering, it can be quite hard to
> find out WHICH pattern actually caused the action.
>
> So maybe postmap (when invoked with "-b", "-
Hi!
I wonder if this is possible:
If a PCRE/regexp style map is triggering, it can be quite hard to
find out WHICH pattern actually caused the action.
So maybe postmap (when invoked with "-b", "-h" or "-q key") could emit
which regular expression (or which line it was in) actually matched.
Yes,
Matthias Schneider via Postfix-users:
> Hi Jaroslaw,
>
> In this context, it's not about the ability to recognize the
> message, as unique IDs and postfix long queue IDs can handle that
> effectively within the 200-character limit. The primary concern
> is having the capability to log full header
ar 2024 10:01:49
Betreff: [pfx] Re: Feature Request: Adjustable Header Log Size Limit in
INFO/WARN/REJECT Header_Check
Dnia 24.01.2024 o godz. 23:21:10 Gerald Galster via Postfix-users pisze:
>
> As the amount of email increases it can be difficult to distinguish mails
> to or from a corr
Dnia 24.01.2024 o godz. 23:21:10 Gerald Galster via Postfix-users pisze:
>
> 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'
;
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
&g
> 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.
>
> Everyt
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.
> Fo
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
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 t
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 i
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
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
IN
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
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 li
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
> t
- Ursprüngliche Mail -
Von: "Wietse Venema via Postfix-users"
An: "Postfix users"
Gesendet: Dienstag, 23. Januar 2024 15:40:45
Betreff: [pfx] Re: Feature Request: Adjustable Header Log Size Limit in
INFO/WARN/REJECT Header_Check
First, there are format string limits all ove
First, there are format string limits all over Postfix. As a matter
of principle I would not make a special case for headers.
Second, the existing 200 byte limit should be plenty sufficient to
uniqiely identify every past, present, and future email message in
this universe and in several other one
Venema via Postfix-users"
An: "Postfix users"
Gesendet: Montag, 22. Januar 2024 16:49:10
Betreff: [pfx] Re: Feature Request: Adjustable Header Log Size Limit in
INFO/WARN/REJECT Header_Check
Matthias Schneider via Postfix-users:
> Thanks for getting back to me quickly.
>
>
ds,
>
> Matthias Schneider
>
> - Urspr?ngliche Mail -
> Von: "Wietse Venema via Postfix-users"
> An: "Postfix users"
> Gesendet: Montag, 22. Januar 2024 16:14:03
> Betreff: [pfx] Re: Feature Request: Adjustable Header Log Size Limit in
> INFO/WA
ppreciated.
Best regards,
Matthias Schneider
- Ursprüngliche Mail -
Von: "Wietse Venema via Postfix-users"
An: "Postfix users"
Gesendet: Montag, 22. Januar 2024 16:14:03
Betreff: [pfx] Re: Feature Request: Adjustable Header Log Size Limit in
INFO/WARN/REJECT Header_Chec
Sorry, Postfix logging must not be used as if it is a reliable
channel for message processing. Postfx goes through great effort
to guarantee that message loss won't happen unless a file system
is damaged or unless a message is forcibly deleted from the queue.
There are no such guarantees for loggi
Dear Postfix Developers,
I hope this message finds you well. I'm reaching out to address a concern
related to the limit for the header key/value string in the "info", "warn" and
"reject" header_check log message during the cleanup process.
The current 200-character limit, introduced in 2002 (
Christian R??ner:
> Hello,
>
> whenever it comes to debug some e-mail issues, it always is a
> little bit hard to aggregate all the log lines together. Therefor
> I would wish some kind of identifier that starts at the connect,
> is carried over all Postfix services up to the disconnect state.
Us
Hello,
whenever it comes to debug some e-mail issues, it always is a little bit hard
to aggregate all the log lines together. Therefor I would wish some kind of
identifier that starts at the connect, is carried over all Postfix services up
to the disconnect state.
Current by using QID:
...
Se
Peter Ajamian:
> Can we get postscreen support in collate.pl? In other words have it
> group postscreen log entries with the rest of the log entries for a
> connection, or just show postscreen log entries when postscreen defers
> the connection?
Postscreen should not be configured to defer cli
Can we get postscreen support in collate.pl? In other words have it
group postscreen log entries with the rest of the log entries for a
connection, or just show postscreen log entries when postscreen defers
the connection?
Peter Ajamian
G'day,
I have a Postfix+Dovecot+LDAP set up with multi-level sub-domains. I had
no problem setting Dovecot up for this environment with the '%D' config
variable modifier.
*
https://doc.dovecot.org/configuration_manual/config_file/config_variables/#modifiers
*
https://github.com/dovecot/c
Jim wrote:
On Tue, Nov 16, 2021 at 11:41 (-0500), Kris Deugau wrote:
Jim wrote:
On Mon, Nov 15, 2021 at 12:25 (-0500), Wietse Venema wrote:
Instead, use Maildir format with one message per file,
I thought about that once, but I decided I have too many e-mail
messages for that. (I don't
On 16.11.21 13:16, Jim wrote:
At first glance I wouldn't see that related to mbox vs. maildir, but
I've been surprised before.
if you only need to read header of each file (maildir), it should be faster
than read whole file (mbox).
yes, IMAP sometimes needs to read while mail file for its stru
On Tue, Nov 16, 2021 at 11:41 (-0500), Kris Deugau wrote:
> Jim wrote:
>> On Mon, Nov 15, 2021 at 12:25 (-0500), Wietse Venema wrote:
>>> Instead, use Maildir format with one message per file,
>> I thought about that once, but I decided I have too many e-mail
>> messages for that. (I don't want
Jim wrote:
On Mon, Nov 15, 2021 at 12:25 (-0500), Wietse Venema wrote:
Finally, if you want to keep lots of mail around, don't keep
everything in one huge mailbox file.
I actually have a bunch of huge mailbox files ;-)
(Yeah, way too much email.)
Instead, use Maildir format with one message
> "Jim" == Jim writes:
>> Instead, use Maildir format with one message per file,
Jim> I thought about that once, but I decided I have too many e-mail
Jim> messages for that. (I don't want to run out of inodes, nor do I want to
Jim> make file accesses too slow because of the number of files
Wietse,
On Mon, Nov 15, 2021 at 12:25 (-0500), Wietse Venema wrote:
> Jim:
>> On Artix, the default is 5120. (Aside: in 1985, that would have
> Postfix has limits on everything, so that the mail system will not
> get stuck. It's really a bad idea to disable them.
I agree that changing it
Wietse Venema:
> Jim:
> > (This is really for postfix developers, but since I'm not allowed to
> > post this on the devel list, here it is here.)
> >
> > Background: I recently moved from Ubuntu to Artix. On Ubuntu, for
> > better or worse, mailbox_size_limit is 0, and I blissfully went around
>
Jim:
> (This is really for postfix developers, but since I'm not allowed to
> post this on the devel list, here it is here.)
>
> Background: I recently moved from Ubuntu to Artix. On Ubuntu, for
> better or worse, mailbox_size_limit is 0, and I blissfully went around
> using a large inbox.
>
> O
(This is really for postfix developers, but since I'm not allowed to
post this on the devel list, here it is here.)
Background: I recently moved from Ubuntu to Artix. On Ubuntu, for
better or worse, mailbox_size_limit is 0, and I blissfully went around
using a large inbox.
On Artix, the default
On 2021-07-22 23:47, Wietse Venema wrote:
Is there a problem with using DOVECOT sieve?
implement this in postfix prequeue smtp proxy mode ?, why did exim add
sieve to mta stage ?, hmm
i still search for why libmilter on gentoo is currently disabled, hope
its not a hidded secureity issue
Benny Pedersen:
> On 2021-07-22 20:29, Viktor Dukhovni wrote:
>
> > Perhaps you're looking for an SMTP proxy with Sieve support, so that
> > you
> > can express simple rules on the message envelope, header and body. I
> > haven't looked, but I expect that such a beast can be found on GitHub,
> >
On 2021-07-22 20:29, Viktor Dukhovni wrote:
Perhaps you're looking for an SMTP proxy with Sieve support, so that
you
can express simple rules on the message envelope, header and body. I
haven't looked, but I expect that such a beast can be found on GitHub,
or similar.
exim have sieve, so may
On 2021-07-22 at 14:46:07 UTC-0400 (Thu, 22 Jul 2021 14:46:07 -0400)
is rumored to have said:
>> The SMTP policy delegation service has access only to SMTP commands
>> and SMTP connection state, just like smtpd_mumble_restrictions, and
>> that will not change.
>
> Understood.
>
>
>> If you need
On 7/22/2021 1:46 PM, post...@ptld.com wrote:
If you need to see both SMTP commands/connections and message
content, use one of the approaches listed above. If there is no
ready-to-use implementation that meets your needs, Milters can be
implemented in python, perl, rust, java, php, C, and more
The SMTP policy delegation service has access only to SMTP commands
and SMTP connection state, just like smtpd_mumble_restrictions, and
that will not change.
Understood.
If you need to see both SMTP commands/connections and message
content, use one of the approaches listed above. If there is
On 07-22-2021 2:29 pm, Viktor Dukhovni wrote:
Perhaps you're lookin for an SMTP proxy with Sieve support, so that you
can express simple rules on the message envelope, header and body. I
haven't looked, but I expect that such a beast can be found on github,
or similar.
Thanks for the tidbit gi
Viktor Dukhovni:
> > On 22 Jul 2021, at 12:33 pm, post...@ptld.com wrote:
> >
> > Is there any chance of the policy server in the future adding a feature to
> > include the mail body in the attributes?
>
> No. If you want to inspect the body prior to accepting the message into
> the queue, use
On Thu, Jul 22, 2021 at 02:19:23PM -0400, post...@ptld.com wrote:
> And im not a fan of proxy filter, it feels like an expensive and
> cumbersome work around solution.
The SMTP engine is easy to implement, and only has to be written once.
You can probably find existing ones to which you can add
Is there any chance of the policy server in the future adding a
feature to include the mail body in the attributes?
No. If you want to inspect the body prior to accepting the message
into
the queue, use the existing smtpd_proxy_filter and/or milter features.
That is unfortunate. I was hopin
> On 22 Jul 2021, at 12:33 pm, post...@ptld.com wrote:
>
> Is there any chance of the policy server in the future adding a feature to
> include the mail body in the attributes?
No. If you want to inspect the body prior to accepting the message into
the queue, use the existing smtpd_proxy_filter
Is there any chance of the policy server in the future adding a feature
to include the mail body in the attributes?
A setting in main.cf:enable_policy_body=yes to include or not include
the body for those who don't need/want the extra data sent.
Maybe also separate out body vs attachment allowi
Thorsten Sch?ning:
> To make things better readable, I would like to have the following
> layout of the same entries instead:
>
> ```
> # Some comment...
> d...@example.org recipient
> c...@example.org recipient
> b@example.org recipient
> a.b@example.org recipient
>
Wietse Venema:
> Thorsten Sch?ning:
> > Guten Tag Wietse Venema,
> > am Freitag, 25. Juni 2021 um 16:21 schrieben Sie:
> >
> > > This also applies to main.cf, master.cf, and many other configuration
> > > files. Your feature request is therefore denied.
>
Thorsten Sch?ning:
> Guten Tag Wietse Venema,
> am Freitag, 25. Juni 2021 um 16:21 schrieben Sie:
>
> > This also applies to main.cf, master.cf, and many other configuration
> > files. Your feature request is therefore denied.
>
> Of course all of those files would ben
On 06-25-2021 9:41 am, Thorsten Schöning wrote:
To make things better readable, I would like to have the following
layout of the same entries instead:
```
# Some comment...
d...@example.org recipient
c...@example.org recipient
b@example.org recipient
a.b@example.org re
Guten Tag Wietse Venema,
am Freitag, 25. Juni 2021 um 16:21 schrieben Sie:
> This also applies to main.cf, master.cf, and many other configuration
> files. Your feature request is therefore denied.
Of course all of those files would benefit from such a feature in the
long term. Though, it
Thorsten Sch?ning:
> Hi all,
>
> The virtual alias table format of Postfix gives special meaning to
> leading whitespace under certain conditions:
This also applies to main.cf, master.cf, and many other configuration
files. Your feature request is therefore denied.
Wietse
Hi all,
The virtual alias table format of Postfix gives special meaning to
leading whitespace under certain conditions:
```
multi-line text
A logical line starts with non-whitespace text. A line that
starts with whitespace continues a logical line.
```
http://www.postfix.org/virtu
_maps, only smtp_tls_policy_maps that
instruct your outgoing smtp connections.
From: owner-postfix-us...@postfix.org On Behalf Of Max-Julian Pogner
Sent: Thursday, June 11, 2020 10:36 AM
To: postfix-users@postfix.org
Subject: Re: Checking my understanding of TLS-related settings, and a possible
fe
On Thu, Jul 02, 2020 at 09:21:27PM -0400, Viktor Dukhovni wrote:
> Tell your customer politely, but firmly, that you are not at liberty to
> enforce TLS 1.2 inbound, as that would downgrade the security of
> connections from clients that can only do TLS 1.0. However, since
> you do support TLS 1.
> On 3/07/2020, at 13:13, Jeremy Banks wrote:
>
> I am not confident all of our legacy apps can be configured for non-standard
> ports; I would be in no way surprised if one or more of them have the classic
> smtp ports hardcoded. Though, I will discuss that option with my co-workers.
>
> Is
On Thu, Jun 11, 2020 at 04:22:37PM +, Jeremy Banks wrote:
> At my job, we use Postfix as our email setup. Recently, as part of a
> security audit by one of our customers, we were told that our mail
> relays must accept only TLSv1.2 when doing TLS, and not any prior
> versions.
Tell your custo
TLS-related settings, and a possible
feature request
Hello,
well, as a quick-fix you could always start an additional smtpd service on a
non-standard port (by adding an appropriate line in master.cf) and configure
this additional smtpd in exception ways (by adding "-o smtpd_tls_FOO&quo
Hello,
well, as a quick-fix you could always start an additional smtpd service
on a non-standard port (by adding an appropriate line in master.cf) and
configure this additional smtpd in exception ways (by adding "-o
smtpd_tls_FOO" options to the additional smtpd service)
example master.cf line (n
Hello,
At my job, we use Postfix as our email setup. Recently, as part of a security
audit by one of our customers, we were told that our mail relays must accept
only TLSv1.2 when doing TLS, and not any prior versions. Well, that's simple
enough to address. The TLS readme[1] and the documentati
Greetings, Wietse Venema!
> Wietse Venema:
>> Andrey Repin:
>> > Greetings, All!
>> >
>> > > Greetings, Viktor Dukhovni!
>> >
>> > >>> Makes sense, thank you.
>> > >>>
>> > >>> So, next question is, do you want it to be mentioned in "Enabling
>> > >>> Postfix
>> > >>> SMTPUTF8 support" [2] or
Wietse Venema:
> Andrey Repin:
> > Greetings, All!
> >
> > > Greetings, Viktor Dukhovni!
> >
> > >>> Makes sense, thank you.
> > >>>
> > >>> So, next question is, do you want it to be mentioned in "Enabling
> > >>> Postfix
> > >>> SMTPUTF8 support" [2] or separately?
> > >>>
> > >>> [2] http:/
Andrey Repin:
> Greetings, All!
>
> > Greetings, Viktor Dukhovni!
>
> >>> Makes sense, thank you.
> >>>
> >>> So, next question is, do you want it to be mentioned in "Enabling Postfix
> >>> SMTPUTF8 support" [2] or separately?
> >>>
> >>> [2] http://www.postfix.org/SMTPUTF8_README.html#enabling
Greetings, All!
> Greetings, Viktor Dukhovni!
>>> Makes sense, thank you.
>>>
>>> So, next question is, do you want it to be mentioned in "Enabling Postfix
>>> SMTPUTF8 support" [2] or separately?
>>>
>>> [2] http://www.postfix.org/SMTPUTF8_README.html#enabling
>> My guess would be under:
>>
Greetings, Viktor Dukhovni!
>> Makes sense, thank you.
>>
>> So, next question is, do you want it to be mentioned in "Enabling Postfix
>> SMTPUTF8 support" [2] or separately?
>>
>> [2] http://www.postfix.org/SMTPUTF8_README.html#enabling
> My guess would be under:
>http://www.postfix.org/S
On Thu, Feb 14, 2019 at 03:48:45AM +0300, Andrey Repin wrote:
> Makes sense, thank you.
>
> So, next question is, do you want it to be mentioned in "Enabling Postfix
> SMTPUTF8 support" [2] or separately?
>
> [2] http://www.postfix.org/SMTPUTF8_README.html#enabling
My guess would be under:
Greetings, Wietse Venema!
> Viktor Dukhovni:
>> On Thu, Feb 14, 2019 at 12:45:37AM +0300, Andrey Repin wrote:
>>
>> > > Indeed I forgot that this does not enforce an ASCII character-set:
>> > >
>> > > http://www.postfix.org/postconf.5.html#strict_rfc821_envelopes
>> > >
>> > > However, right
Viktor Dukhovni:
> On Thu, Feb 14, 2019 at 12:45:37AM +0300, Andrey Repin wrote:
>
> > > Indeed I forgot that this does not enforce an ASCII character-set:
> > >
> > > http://www.postfix.org/postconf.5.html#strict_rfc821_envelopes
> > >
> > > However, right below that is:
> > >
> > > http:
On Thu, Feb 14, 2019 at 12:45:37AM +0300, Andrey Repin wrote:
> > Indeed I forgot that this does not enforce an ASCII character-set:
> >
> > http://www.postfix.org/postconf.5.html#strict_rfc821_envelopes
> >
> > However, right below that is:
> >
> > http://www.postfix.org/postconf.5.html#s
Greetings, Viktor Dukhovni!
> On Mon, Feb 11, 2019 at 01:56:56PM -0700, Zach Callear wrote:
>> Viktor Dukhovni:
>> > Have you tried:
>> > strict_rfc821_envelopes = yes
>>
>> I just tested it. With "strict_rfc821_envelopes = yes", and with a
>> blank "smtpd_helo_restrictions" setting, email
> On Feb 12, 2019, at 9:38 AM, Andrey Repin wrote:
>
> If you point in the direction of a repository and hint on what you want to see
> in it, I can try my hand.
The postfix source code is available from any of the various mirrors
listed at: http://www.postfix.org/download.html
I have a github
Greetings, Viktor Dukhovni!
>>
>>> However, right below that is:
>>> http://www.postfix.org/postconf.5.html#strict_smtputf8
>>>
>>> which will do the job.
>>
>> Thank you, Victor. That setting indeed allows me to reject Unicode
>> characters (and not just BOMs) in a MAIL FROM command, when
> On Feb 11, 2019, at 6:08 PM, Zach Callear wrote:
>
>> However, right below that is:
>> http://www.postfix.org/postconf.5.html#strict_smtputf8
>>
>> which will do the job.
>
> Thank you, Victor. That setting indeed allows me to reject Unicode
> characters (and not just BOMs) in a MAIL FR
Viktor Dukhovni:
However, right below that is:
http://www.postfix.org/postconf.5.html#strict_smtputf8
which will do the job.
Thank you, Victor. That setting indeed allows me to reject Unicode
characters (and not just BOMs) in a MAIL FROM command, when SMTPUTF8
isn't specified, as I ini
On Mon, Feb 11, 2019 at 01:56:56PM -0700, Zach Callear wrote:
> Viktor Dukhovni:
> > Have you tried:
> > strict_rfc821_envelopes = yes
>
> I just tested it. With "strict_rfc821_envelopes = yes", and with a
> blank "smtpd_helo_restrictions" setting, email sent with the example
> SMTP script
Viktor Dukhovni:
Have you tried:
strict_rfc821_envelopes = yes
? There's nothing special about a "UTF-8 BOM" (there's no such thing in
UTF-8 actually UTF-8 has no little-endian form). It is rather likely
that your sender was not using SMTPUTF8, and so the encoding of non-ASCII
envelope
> On Feb 11, 2019, at 2:16 PM, Zach Callear wrote:
>
> it still would be nice to have an easy configuration option to affect that
> behavior,
> as I find it highly unlikely that there's a legitimate use case for it.
Have you tried:
strict_rfc821_envelopes = yes
? There's nothing spec
Wietse Venema:
What is the difference with final delivery to Dovecot?
There is nothing special about the fact that I'm doing final delivery to
Dovecot, but it is what made me notice the problem. I just personally
consider it invalid for an envelope sender address to contain a UTF BOM,
and I
Zach Callear:
> My server has been receiving a lot of spam lately where the username
> portion of the email address in the MAIL FROM command contains a UTF
> byte-order mark (BOM).
>
> With my configuration until this point:
>
> 1. Postfix does recipient verification with Dovecot LMTP, which do
My server has been receiving a lot of spam lately where the username
portion of the email address in the MAIL FROM command contains a UTF
byte-order mark (BOM).
With my configuration until this point:
1. Postfix does recipient verification with Dovecot LMTP, which doesn't
care about the BOM a
Tom Sommer:
> On 2018-08-09 19:52, Wietse Venema wrote:
> > Tom Sommer:
> >> On 2018-08-09 19:31, Wietse Venema wrote:
> >> > I suggested using a lookup table (smtpd_reply_footer_maps) which
> >> > is queried with the original Postfix response, and which can
> >> > dynamically return a filled-in te
On 2018-08-09 19:52, Wietse Venema wrote:
Tom Sommer:
On 2018-08-09 19:31, Wietse Venema wrote:
> I suggested using a lookup table (smtpd_reply_footer_maps) which
> is queried with the original Postfix response, and which can
> dynamically return a filled-in template based on the content of the
Tom Sommer:
> On 2018-08-09 19:31, Wietse Venema wrote:
> > Viktor Dukhovni:
> >> On Thu, Aug 09, 2018 at 06:52:48PM +0200, Tom Sommer wrote:
> >>
> >> > So I can do a "Please look at
> >> > http://example.com/smtp.php?code=$smtp_code"; and do some magic on that
> >> > page with the error code and
On 2018-08-09 19:31, Wietse Venema wrote:
Viktor Dukhovni:
On Thu, Aug 09, 2018 at 06:52:48PM +0200, Tom Sommer wrote:
> So I can do a "Please look at
> http://example.com/smtp.php?code=$smtp_code"; and do some magic on that
> page with the error code and/or error description to help the custom
Viktor Dukhovni:
> On Thu, Aug 09, 2018 at 06:52:48PM +0200, Tom Sommer wrote:
>
> > So I can do a "Please look at
> > http://example.com/smtp.php?code=$smtp_code"; and do some magic on that
> > page with the error code and/or error description to help the customer.
>
> Seems like overkill. Wi
On 2018-08-09 19:07, Viktor Dukhovni wrote:
On Thu, Aug 09, 2018 at 06:52:48PM +0200, Tom Sommer wrote:
So I can do a "Please look at
http://example.com/smtp.php?code=$smtp_code"; and do some magic on that
page with the error code and/or error description to help the
customer.
Seems like ove
On Thu, Aug 09, 2018 at 06:52:48PM +0200, Tom Sommer wrote:
> So I can do a "Please look at
> http://example.com/smtp.php?code=$smtp_code"; and do some magic on that
> page with the error code and/or error description to help the customer.
Seems like overkill. Will you be documenting all the P
;> will keep digging.
>
> One more time:
> YOU don't insert status codes into the footer.
> POSTFIX inserts those for you.
Okay, so then we are back to my original feature request and me not
understanding how a smtpd_reject_footer_maps would enable me to do so
:)
Sorry for the
On 2018-08-09 18:24, Viktor Dukhovni wrote:
On Thu, Aug 09, 2018 at 11:07:33AM +0200, Tom Sommer wrote:
It would be nice if smtpd_reject_footer could include variables such
as
the 4.x.x/5.x.x response code or even the full postfix error message,
this way one could make more helpful errors mess
On Thu, Aug 09, 2018 at 11:07:33AM +0200, Tom Sommer wrote:
> It would be nice if smtpd_reject_footer could include variables such as
> the 4.x.x/5.x.x response code or even the full postfix error message,
> this way one could make more helpful errors messages with more helpful
> links.
Why wo
eep digging.
> >
> > One more time:
> > YOU don't insert status codes into the footer.
> > POSTFIX inserts those for you.
>
> Okay, so then we are back to my original feature request and me not
> understanding how a smtpd_reject_footer_maps would enable me to
r.
POSTFIX inserts those for you.
Okay, so then we are back to my original feature request and me not
understanding how a smtpd_reject_footer_maps would enable me to do so :)
Sorry for the noise, I guess.
--
Tom
Tom Sommer:
> On 2018-08-09 14:10, Wietse Venema wrote:
> > Tom Sommer:
> >> On 2018-08-09 14:01, Wietse Venema wrote:
> >> > Tom Sommer:
> >> >> It would be nice if smtpd_reject_footer could include variables such
> >> >> as
> >> >> the 4.x.x/5.x.x response code or even the full postfix error mess
1 - 100 of 305 matches
Mail list logo
