Maildirs in AWS EFS?

[Rodolfo González González]

Hello,

AWS released one month ago a EFS system with administered life cycle, 
which means that files not accessed in the last 30 days are moved to a 
lower cost storage tier. Currently I hold my e-mail, delivered to 
Maildir++ folders by postfix and retrieved with Dovecot, in standard EBS 
volumes. This has the disadvantage that I need to allocate more than 
enough space to ensure that the volume won't get filled too soon. And 
this costs. Changing to standard EFS wasn't an option, since it's way 
more expensive than EBS. But with the new system the cost is lower.


I just have a doubt in the technical side: is it safe to have the email 
in EFS? I've read experiences about storing in S3 and using a driver to 
mount the bucket, and it seems that it's not a very good option. But EFS 
works like NFS4. Does anyone have experience mounting an EFS to store 
maildirs?


Thanks in advanced,
Rodolfo.

Re: Permanent store of incoming mail.

[@lbutlr]

On 20 Mar 2019, at 15:40, Patrick Ben Koetter  wrote:
> Or, if you use dovecot as storage, create a second dovecot instance and dsync
> messages from first to second instance.

This is a much better solution in terms of features and making that alternate 
mailspool available. Mine is better in terms of being dead simple to implement, 
though it is probably more fiddly to maintain.

If all you need to do is store the mail for some bureaucratic reason, that's 
the one I'd use. If you need to be able to let users, for example, recover lost 
mails from the backup spool or search it or anything much beyond letting it sit 
their until it expires, then yeah, I'd do what you suggest instead.



-- 
They say only the good die young. If it works the other way too I'm
immortal

Re: Permanent store of incoming mail.

[Patrick Ben Koetter]

* @lbutlr :
> On 20 Mar 2019, at 15:06, Homer Wilson Smith  
> wrote:
> >Pointers to RTFM
> > 
> >Running Centos 7.x, latest postfix.
> > 
> >What is the best way to keep a permanent store for
> > incgoing e-mail.  Doesn't have to be forever.  1 year perhaps.
> 
> I use recipient_bcc_maps 

Or, if you use dovecot as storage, create a second dovecot instance and dsync
messages from first to second instance.

On the second instance you can benefit from server-side search and all the
tooling that comes with doveadm, e.g. iterating over all messages in all
mailboxes and age those older than one year.

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 

Re: Understanding the importance of submission

[Bill Cole]

On 20 Mar 2019, at 11:01, Yassine Chaouche wrote:


Dear postfix,

I don't seem to get the idea of submission, I know I must be wrong, 
b/c so many articles out there preach to use a different port for 
submission, but I hope to find some argument in your replies that will 
make me change my mind.
If I understand correctly, submission is a means for mail server 
admins to enforce some policies on port 587 w/o interfering with mail 
relay which occurs on port 25. These policies are mainly :


1/ Force TLS on all incoming connexions
2/ Force users to authenticate

While 1/ can't be enforced on port 25, 2/ can be enforced for relay, 
e.g. with :


smtpd_sasl_auth_enable = yes
smtpd_relay_restrictions =  permit_mynetworks, 
permit_sasl_authenticated, reject_unauth_destination


So the only thing that I need submission port for seems to be to force 
TLS connexions, right ?


Anything else I am missing there ?


1. Eliminates the usual rationale for broad authentication by IP (i.e. 
permit_mynetworks) which opens most Postfix systems to abuse by networks 
that the admin very much WANTS to be trustworthy but which often are 
not. One can do this without segregating submission but doing so spurs 
the question: "Why permit_mynetworks?" The usual answer in the modern 
world is that there's no good reason for permit_mynetworks, or at least 
there's no reason to include submitters' networks in mynetworks.


2. Allows enforcement of SPF and SPF-like policy for local domain 
senders on port 25.


3. Simplifies the common need to distinguish between "inbound" and 
"outbound" mail in filtering, policy, and signing tools.


4. Eliminates the need to allow authentication on port 25, reducing the 
attack surface for credential-stuffing and brute-force tactics.



Another claim for submission is that it reduces spam, but to my 
understanding that's only for *sending* spam (relaying), and that's 
because the admin enforces user authentication for relay, which can 
safely be done on port 25 anyways (otherwise we'd be an open relay).


Spammer tactics that take advantage of 'permit_mynetworks' (and similar 
policies for other MTAs) are common.


As for *reciving* spam (we're the final destination), it can still be 
delivered unauthed from port 25, so that won't stop *receiving* spam, 
will it ?


No, but if you don't need to allow your own users to relay through port 
25, you can use tools that are designed to reject mail coming directly 
from end-user devices (e.g. Spamhaus PBL, banning suspect reverse 
hostname patterns, etc.) which are made cumbersome or weakened by having 
end-user submissions and inbound mail flowing through a common 
transport.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: Permanent store of incoming mail.

[@lbutlr]

On 20 Mar 2019, at 15:06, Homer Wilson Smith  wrote:
>Pointers to RTFM
> 
>Running Centos 7.x, latest postfix.
> 
>What is the best way to keep a permanent store for
> incgoing e-mail.  Doesn't have to be forever.  1 year perhaps.

I use recipient_bcc_maps 



-- 
'The trouble with my friend here is that he doesn't know the difference
between a postulate and a metaphor of human existence. Or a hole in the
ground.' --Pyramids

Permanent store of incoming mail.

[Homer Wilson Smith]

Pointers to RTFM

Running Centos 7.x, latest postfix.

What is the best way to keep a permanent store for
incgoing e-mail.  Doesn't have to be forever.  1 year perhaps.

Presently rsyncing main server:/home to backup server:/home without
--delete, so copied mail just accrues in cur and new.  rsync runs
every two hours.

Cons, its slow, cpu intensive and does not get all mail if it is
deleted or .forwarded before rsync runs every 2  hours.

A double delivery system would be fine, mail comes in and is auto 
forwarded to an identical server. How does postfix do an auto 
deliver and then also forward?


Thanks

Homer W Smith
CEO Lightlink Internet


Homer Wilson Smith   Clean Air, Clear Water,Art Matrix - Lightlink
(607) 277-0959   A Green Earth, and Peace,  Internet, Ithaca NY
ho...@lightlink.com  Is that too much to ask?   http://www.lightlink.com

Re: Understanding the importance of submission

[Ralph Seichter]

* Viktor Dukhovni:

> That's one of the common misperceptions of of the IETF standards
> process. Proposed standards are IETF standards.

I intrepret https://tools.ietf.org/html/rfc7127#section-3 differently:

  Proposed Standards are of such quality that implementations can be
  deployed in the Internet. [...] Proposed Standards may be revised if
  problems are found or better solutions are identified, when experiences
  with deploying implementations of such technologies at scale is gathered.

That, to me, means at this stage the RFC is not "binding". Given your
personal experience, I am sure you know what you are talking about, but
I am surprised.

> But there's not IETF police to enforce the standards, and not all the
> standards succeed in the marketplace.

Indeed.

-Ralph

Re: Understanding the importance of submission

[Matus UHLAR - fantomas]

On 3/20/19 4:18 PM, Patrick Ben Koetter wrote:

Access providers may block outbound TCP/25 connections, because infected
enduser devices try to transport messages on that port to remote MTAs. They
won't block TCP/597 because submission requires SMTP AUTH, which requires the
sender to possess login/pass – something most spammers don't have.


On 20.03.19 16:26, Yassine Chaouche wrote:

Requiring authentication to relay on 25 will also get rid of spam.


it will also get rid of incoming mail from other mail servers...

--
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.
WinError #9: Out of error messages.

Re: Understanding the importance of submission

[Viktor Dukhovni]

> On Mar 20, 2019, at 11:51 AM, Ralph Seichter  wrote:
> 
> As far as I can see, RFC 8314 is only in the proposed standards stage,
> so no, the use of port 587 is not deprecated.

That's one of the common misperceptions of of the IETF standards
process.  Proposed standards are IETF standards.  Full standards
are those standards that have matured to the point where they
are known to be widely used, broadly interoperable and stable.

But there's not IETF police to enforce the standards, and not
all the standards succeed in the marketplace.

-- 
Viktor.

Re: Understanding the importance of submission

[Viktor Dukhovni]

On Wed, Mar 20, 2019 at 04:01:24PM +0100, Yassine Chaouche wrote:

> I don't seem to get the idea of submission, I know I must be wrong, b/c 
> so many articles out there preach to use a different port for 
> submission, but I hope to find some argument in your replies that will 
> make me change my mind.

The real difference is that on the submission port you can pass the
ORIGINATING macro to DKIM milters to sign *outbound* mail, while
on the inbound relay port you'll DKIM verification of remotely
originated email.

You would also front-end smtpd(8) with postscreen on port 25, and
apply RBLs that reject clients listed in RBLs, ... but not do either
on 587.

Your configuration is also simplified by separating the rules for
authorizing outbound email from your users, from the logic that
fights spam from untrusted remote users.

I find divide and conquer to be the best way to fight complexity,
to the point of often running a separate Postfix instance for
outbound email, not just a separate service on a separate port.

-- 
Viktor.

Re: Understanding the importance of submission

[Viktor Dukhovni]

On Wed, Mar 20, 2019 at 08:26:47AM -0700, Alice Wonder wrote:

> Note that submission on Port 587 is deprecated, it is now "official" to 
> use Port 465 with implicit TLS.

That's mostly wishful (and perhaps even slightly misguided) thinking
on the part of the authors of one particular IETF RFC.  In practice,
port 587 is alive and well, and there's nothing wrong with it that
switching to 465 fixes.

-- 
Viktor.

Re: Howto reject only one recipient and not drop entire email?

[Noel Jones]

On 3/20/2019 6:53 AM, Otto Kekäläinen wrote:

1. Try adding "unknown_address_reject_code = 553" in main.cf. This is a
wise choice in any case.
2. Use a better mail client which handles multiple recipient mail more
robustly.


Thanks for the pointers!

I added the 553 reject code, but unfortunately it does not seem to help.

My client is msmtp and the SMTP session looks like this:

cat mail.txt | msmtp -a default -X mail.log --debug -t

<-- 220 REDACTED ESMTP Postfix (Ubuntu)
--> EHLO localhost
<-- 250-REDACTED
<-- 250-PIPELINING
<-- 250-SIZE 1024
<-- 250-VRFY
<-- 250-ETRN
<-- 250-STARTTLS
<-- 250-ENHANCEDSTATUSCODES
<-- 250-8BITMIME
<-- 250 DSN
--> MAIL FROM:
--> RCPT TO:
--> RCPT TO:
--> DATA
<-- 250 2.1.0 Ok
<-- 250 2.1.5 Ok
<-- 553 5.1.2 : Recipient address rejected: Domain not found
msmtp: recipient address REDACTED not accepted by the server
msmtp: server message: 553 5.1.2 : Recipient address
rejected: Domain not found
msmtp: could not send mail (account default from /etc/msmtprc)

So if the blame is on the client, what replacements for msmtp do you recommend?




The few smtp command line clients I know of all fail on a rejected 
recipient. This is probably appropriate for an interactive command, 
to give immediate feedback. Same thing with desktop clients such as 
Thunderbird.  But none of them seem to have an option to ignore 
errors, which is a shortcoming.


"Real" SMTP MTAs will continue with the next recipient.

Probably your best bet is to find a [perl, java, php, etc.] smtp 
script and hack it to continue with the next recipient when one is 
rejected, which shouldn't be too hard.




  -- Noel Jones

Re: Understanding the importance of submission

[A. Schulze]

Am 20.03.19 um 16:18 schrieb Patrick Ben Koetter:
> Use submission on TCP/587 for MUA to MTA traffic.

Btw:

RFC 8314 describe Implicit TLS for POP3, IMAP and Submission
on ports 995, 993 and 465. Works fine the usual modern MUAs
and eliminate the opportunity for downgrades while talking plaintext+STARTTLS

Andreas

Re: Understanding the importance of submission

[Mike]

On 3/20/2019 11:39 AM, Ralph Seichter wrote:
> * Yassine Chaouche:
> 
>> So the only thing that I need submission port for seems to be to force 
>> TLS connexions, right ?
> 
> You already mentioned having different policies, so the possibilities
> are numerous. Having the dedicated submission port allows me to easily
> force encryption, force authentication (password, client certificates),
> limit users to certain sender domains, add DKIM signatures, to name just
> some examples. I can also flat out reject envelope senders foo@mydomain
> on port 25, add DNS BL/WL checks, various milters, etc.
> 
> In my experience it is easier to configure (and understand) how your
> Postfix instances are operating when inbound and outbound emails are
> entering via separate ports.

The similarity between the two ports is that they both allow a means of
entry for an email into the server.

Beside that, they can (and usually do) have differing policies regarding
that entry.

Keeping the two entry streams separate makes it easier to put the
differing policies into place and to enforce those policies.

If someone, for whatever reason, has very similar policies for the two
ports, then for that person, the distinction of having two separate
ports becomes less apparent.

Re: Understanding the importance of submission

[Ralph Seichter]

* Alice Wonder:

> Note that submission on Port 587 is deprecated, it is now "official" to 
> use Port 465 with implicit TLS.

As far as I can see, RFC 8314 is only in the proposed standards stage,
so no, the use of port 587 is not deprecated.

-Ralph

Re: Understanding the importance of submission

[Ralph Seichter]

* Yassine Chaouche:

> So the only thing that I need submission port for seems to be to force 
> TLS connexions, right ?

You already mentioned having different policies, so the possibilities
are numerous. Having the dedicated submission port allows me to easily
force encryption, force authentication (password, client certificates),
limit users to certain sender domains, add DKIM signatures, to name just
some examples. I can also flat out reject envelope senders foo@mydomain
on port 25, add DNS BL/WL checks, various milters, etc.

In my experience it is easier to configure (and understand) how your
Postfix instances are operating when inbound and outbound emails are
entering via separate ports.

-Ralph

Re: Understanding the importance of submission

[Yassine Chaouche]

On 3/20/19 4:26 PM, Alice Wonder wrote:
[...]Note that submission on Port 587 is deprecated, it is now 
"official" to use Port 465 with implicit TLS. [...]


Oh, I thought it was the other way arround and most people now are 
dropping 465 in favor of 587 with STARTTLS to support old/odd clients 
who don't support TLS. Could you point me to the/a reference ?


Yassine.

Re: Understanding the importance of submission

[Alice Wonder]

On 3/20/19 8:18 AM, Patrick Ben Koetter wrote:

* Yassine Chaouche :

Dear postfix,

I don't seem to get the idea of submission, I know I must be wrong, b/c so
many articles out there preach to use a different port for submission, but I


Use submission on TCP/587 for MUA to MTA traffic.
Use smtp on TCP/25 for MTA to MTA traffic.

Run authenticated MUA friendly policies on Submission. Run MTA policies on
smtp port.

Access providers may block outbound TCP/25 connections, because infected
enduser devices try to transport messages on that port to remote MTAs. They
won't block TCP/597 because submission requires SMTP AUTH, which requires the
sender to possess login/pass – something most spammers don't have.

p@rick




Note that submission on Port 587 is deprecated, it is now "official" to 
use Port 465 with implicit TLS.


Using Port 587 isn't going to stop working, of course, but...

But anyway yes, port 25 is frequently blocked by consumer ISPs. It's 
blocked by mine, for example.

Re: Understanding the importance of submission

[Yassine Chaouche]

On 3/20/19 4:18 PM, Patrick Ben Koetter wrote:

[...] Use submission on TCP/587 for MUA to MTA traffic.

Why ?

[...]

Run authenticated MUA friendly policies on Submission. Run MTA policies on
smtp port.

What kind ?

Access providers may block outbound TCP/25 connections, because infected
enduser devices try to transport messages on that port to remote MTAs. They
won't block TCP/597 because submission requires SMTP AUTH, which requires the
sender to possess login/pass – something most spammers don't have.

Requiring authentication to relay on 25 will also get rid of spam.

Yassine.

Re: Understanding the importance of submission

[Patrick Ben Koetter]

* Yassine Chaouche :
> Dear postfix,
> 
> I don't seem to get the idea of submission, I know I must be wrong, b/c so
> many articles out there preach to use a different port for submission, but I

Use submission on TCP/587 for MUA to MTA traffic.
Use smtp on TCP/25 for MTA to MTA traffic.

Run authenticated MUA friendly policies on Submission. Run MTA policies on
smtp port.

Access providers may block outbound TCP/25 connections, because infected
enduser devices try to transport messages on that port to remote MTAs. They
won't block TCP/597 because submission requires SMTP AUTH, which requires the
sender to possess login/pass – something most spammers don't have.

p@rick






> hope to find some argument in your replies that will make me change my mind.
> If I understand correctly, submission is a means for mail server admins to
> enforce some policies on port 587 w/o interfering with mail relay which
> occurs on port 25. These policies are mainly :
> 
> 1/ Force TLS on all incoming connexions
> 2/ Force users to authenticate
> 
> While 1/ can't be enforced on port 25, 2/ can be enforced for relay, e.g.
> with :
> 
> smtpd_sasl_auth_enable = yes
> smtpd_relay_restrictions =  permit_mynetworks, permit_sasl_authenticated,
> reject_unauth_destination
> 
> So the only thing that I need submission port for seems to be to force TLS
> connexions, right ?
> 
> Anything else I am missing there ?
> 
> Another claim for submission is that it reduces spam, but to my
> understanding that's only for *sending* spam (relaying), and that's because
> the admin enforces user authentication for relay, which can safely be done
> on port 25 anyways (otherwise we'd be an open relay). As for *reciving* spam
> (we're the final destination), it can still be delivered unauthed from port
> 25, so that won't stop *receiving* spam, will it ?
> 
> I'm all confused.
> 
> Yassine.
> 

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 

Understanding the importance of submission

[Yassine Chaouche]

Dear postfix,

I don't seem to get the idea of submission, I know I must be wrong, b/c 
so many articles out there preach to use a different port for 
submission, but I hope to find some argument in your replies that will 
make me change my mind.
If I understand correctly, submission is a means for mail server admins 
to enforce some policies on port 587 w/o interfering with mail relay 
which occurs on port 25. These policies are mainly :


1/ Force TLS on all incoming connexions
2/ Force users to authenticate

While 1/ can't be enforced on port 25, 2/ can be enforced for relay, 
e.g. with :


smtpd_sasl_auth_enable = yes
smtpd_relay_restrictions =  permit_mynetworks, 
permit_sasl_authenticated, reject_unauth_destination


So the only thing that I need submission port for seems to be to force 
TLS connexions, right ?


Anything else I am missing there ?

Another claim for submission is that it reduces spam, but to my 
understanding that's only for *sending* spam (relaying), and that's 
because the admin enforces user authentication for relay, which can 
safely be done on port 25 anyways (otherwise we'd be an open relay). As 
for *reciving* spam (we're the final destination), it can still be 
delivered unauthed from port 25, so that won't stop *receiving* spam, 
will it ?


I'm all confused.

Yassine.

Re: "Chunk exceeds message size limit"

[@lbutlr]

On 19 Mar 2019, at 13:00, Viktor Dukhovni  wrote:
> Note that, perhaps unintentionally, the treatment of "message_size_limit
> = 0" is not documented to mean "no limit".  Perhaps we should also
> address that.

By forbidding a setting of 0?



-- 
'They're the cream!' Rincewind sighed. 'Cohen, they're the cheese.'

Re: Howto reject only one recipient and not drop entire email?

[Matus UHLAR - fantomas]

On 20.03.19 13:53, Otto Kekäläinen wrote:

I added the 553 reject code, but unfortunately it does not seem to help.

My client is msmtp and the SMTP session looks like this:

cat mail.txt | msmtp -a default -X mail.log --debug -t



--> RCPT TO:
--> RCPT TO:
--> DATA
<-- 250 2.1.0 Ok
<-- 250 2.1.5 Ok
<-- 553 5.1.2 : Recipient address rejected: Domain not found
msmtp: recipient address REDACTED not accepted by the server
msmtp: server message: 553 5.1.2 : Recipient address
rejected: Domain not found
msmtp: could not send mail (account default from /etc/msmtprc)

So if the blame is on the client, what replacements for msmtp do you recommend?


this is clearly the msmtp issue. I would think that the msmtp author expects
you to clear the list of recipients to only contain valid addresses.
I don't know about any other SW with msmtp's functionality.

--
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.
(R)etry, (A)bort, (C)ancer

Re: Howto reject only one recipient and not drop entire email?

[Bill Cole]

On 20 Mar 2019, at 7:53, Otto Kekäläinen wrote:

So if the blame is on the client, what replacements for msmtp do you 
recommend?


Both the real sendmail and the Postfix sendmail do the right thing.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: Howto reject only one recipient and not drop entire email?

[Otto Kekäläinen]

> 1. Try adding "unknown_address_reject_code = 553" in main.cf. This is a
> wise choice in any case.
> 2. Use a better mail client which handles multiple recipient mail more
> robustly.

Thanks for the pointers!

I added the 553 reject code, but unfortunately it does not seem to help.

My client is msmtp and the SMTP session looks like this:

cat mail.txt | msmtp -a default -X mail.log --debug -t

<-- 220 REDACTED ESMTP Postfix (Ubuntu)
--> EHLO localhost
<-- 250-REDACTED
<-- 250-PIPELINING
<-- 250-SIZE 1024
<-- 250-VRFY
<-- 250-ETRN
<-- 250-STARTTLS
<-- 250-ENHANCEDSTATUSCODES
<-- 250-8BITMIME
<-- 250 DSN
--> MAIL FROM:
--> RCPT TO:
--> RCPT TO:
--> DATA
<-- 250 2.1.0 Ok
<-- 250 2.1.5 Ok
<-- 553 5.1.2 : Recipient address rejected: Domain not found
msmtp: recipient address REDACTED not accepted by the server
msmtp: server message: 553 5.1.2 : Recipient address
rejected: Domain not found
msmtp: could not send mail (account default from /etc/msmtprc)

So if the blame is on the client, what replacements for msmtp do you recommend?

Re: Docker Postfix logging

[Walter Doekes]

Hi Matthias,

> since i don't want to mount /dev/log into a postfix container, i created
> a small tool in golang to create a syslog unix socket and print all logs
> to stdout,
> the command `postfix start-fg` is wrapped.
>
> https://github.com/mschneider82/postfixstdoutlogger/

Alternately, here's a more generic version that _also_ reaps children, in
case postfix were to spawn any:

https://github.com/ossobv/gospawn/

Cheers!

Walter Doekes

Re: Docker Postfix logging

[Tamás Gérczei]

Hi,

Nice one, albeit you can use this
 since 3.4 - I have
it set to the value '/dev/stdout'.

Yours,
Tamás

On 3/20/19 11:10 AM, Matthias Schneider wrote:
> Hi,
>
> since i don't want to mount /dev/log into a postfix container, i
> created a small tool in golang to create a syslog unix socket and
> print all logs to stdout,
> the command `postfix start-fg` is wrapped.
>
> Just want to share this with the community:
>
> https://github.com/mschneider82/postfixstdoutlogger/
>
>
> Best Regards
>
> Matthias Schneider
>

Docker Postfix logging

[Matthias Schneider]

Hi,

since i don't want to mount /dev/log into a postfix container, i created 
a small tool in golang to create a syslog unix socket and print all logs 
to stdout,

the command `postfix start-fg` is wrapped.

Just want to share this with the community:

https://github.com/mschneider82/postfixstdoutlogger/


Best Regards

Matthias Schneider

Re: "Chunk exceeds message size limit"

[Markus Schönhaber]

Viktor Dukhovni, 19.3.2019 20:00 +0100:

> Note that, perhaps unintentionally, the treatment of "message_size_limit
> = 0" is not documented to mean "no limit".  Perhaps we should also
> address that.

I asked about that some years ago and Wietse told me that it is
intentionally not documented:
> http://postfix.1071664.n5.nabble.com/value-of-zero-not-documented-for-message-size-limit-td66874.html

-- 
Regards
  mks