dovecot - Jan 2022 - patch: make received-header on submission optional or optionally drop the from-part in it

Am 03.01.22 um 15:47 schrieb Michael Peddemors:
> Using your email system IS the reason, simply make sure that you inform
no, it's not.

and:
> (SLA, Terms and Conditions etc) and it has a valid use, eg for security
> purposes.
for security_reasons it's completly ok, to store this information
*locally* on the server for some time, but not to push this information
together with date+time towards the world.

sorry, if you don't have an idea of privacy-needs, you should not post
about this topic and then say something about "no flames please"...
> Oh, but no flames please, this is almost getting off topic as it is.
well, then let's come back to the origin topic.

There's an need for it (as I noticed meanwhile at least back to 2019:
 https://dovecot.org/pipermail/dovecot/2019-August/116865.html ) and
until it breaks no existing thing (which is expected due to *optional*
settings ), there's no reason to discuss about that need itself.

( You won't be forced to enable it for Your mail-server )

@others: due to the importance of it for us, I'm currently trying to
implement it, but because that's my first deeper view in dovecots code,
maybe I'll need some help.

d.

> @others: due to the importance of it for us, I'm currently trying to
> implement it, but because that's my first deeper view in dovecots code,
> maybe I'll need some help.
okay, perhaps I've a solution for this.

because we're using standard-distribution-pkgs, we're checked it with
that version (devuan chimaera/debian bullseye) and it works as expected.

The port to the currently available version 2.3.17.1 was simple, because
only the Macro "DEF(SET_BOOL, ..." has changed to "DEF(BOOL,
..."
between that versions, but we only have tested the compilation of this
version.

because until now I've never really worked with git, I've no possibility
to follow that way for integration. Independently from this maybe you
won't like the changes and won't integrate them at all.

=====================================================================1. added an
corresponding option to "lmtp_add_received_header" named
"submission_add_received_header"

2. added options "lmtp_add_rcvd_from" and
"submission_add_rcvd_from"

3. added another arg to smtp_server_transaction_write_trace_record() to
handle the "*rcvd_from"-flags

4. beautified the header-construction within
smtp_server_transaction_write_trace_record() a little bit

5. added the options to default-config. (unset default is always keeping
old behaviour)
=====================================================================
the patch for 2.3.17.1 is attached.

please let me know, if you're integrating it, because then I'll send the
patch for the old version to the devuan/debian-maintainers for
integration, so that we can update normally again.

regards

d.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dovecot-2.3.17.1-rcvd_from-patch.xz
Type: application/x-xz
Size: 2360 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20220103/3aca3a27/attachment.xz>

> On 03/01/2022 17:15 dc-ml at dvl.werbittewas.de wrote:
> 
>  
> Am 03.01.22 um 15:47 schrieb Michael Peddemors:
> 
> > Using your email system IS the reason, simply make sure that you
inform
> 
> no, it's not.
> 
> and:
> 
> > (SLA, Terms and Conditions etc) and it has a valid use, eg for
security
> > purposes.
> 
> for security_reasons it's completly ok, to store this information
> *locally* on the server for some time, but not to push this information
> together with date+time towards the world.
> 
> sorry, if you don't have an idea of privacy-needs, you should not post
> about this topic and then say something about "no flames
please"...
> 
> > Oh, but no flames please, this is almost getting off topic as it is.
> 
> well, then let's come back to the origin topic.
> 
> There's an need for it (as I noticed meanwhile at least back to 2019:
>  https://dovecot.org/pipermail/dovecot/2019-August/116865.html ) and
> until it breaks no existing thing (which is expected due to *optional*
> settings ), there's no reason to discuss about that need itself.
> 
> ( You won't be forced to enable it for Your mail-server )
> 
> @others: due to the importance of it for us, I'm currently trying to
> implement it, but because that's my first deeper view in dovecots code,
> maybe I'll need some help.
> 
> d.
Hi!

We'll take a look at your patch. Can you please point out to some legal
information about the Received header's GDPR incompliance, I would be
interested to see it.

Aki