Re: [mlmmj] Roadmap for 1.5

Hi Baptiste,

The problem arises if you do want to modify the message - such as inserting [=
listID] to the subject or adding a Reply-To header.

If the sender has their SPF record to a hard reject (as is the case for a co=
uple of users on our mailing list) - then anyone else doesn=E2=80=99t receiv=
e their messages.

I like the idea where you only mangle the =46rom if the sender has a hard SP=
F reject, that way only those senders on our list are affected and everyone e=
lse it=E2=80=99s business as normal.


Kent

> On 5 May 2024, at 10:52=E2=80=AFAM, Baptiste Daroussin <[email protected]> wro=
te:
>=20
> =EF=BB=BFHi,
>=20
> if there is a strong request for this I would add it, but again this is no=
t
> necessary including with people having a reject policy like yahoo.com.
>=20
> In the FreeBSD project for the mailing list we use mlmmj, we don't never m=
unge
> the from, we make sure we don't alter fields that are used for dkim signat=
ures,
> meaning no control/prefix control/footer and we have plenty of subscribers=
 from
> yahoo.com without any problem.
>=20
> Best regards,
> Bapt
>=20
>=20
>> On Sun 05 May 09:39, Kent wrote:
>> Hi Baptiste,
>>=20
>> With the enforcement of SPF / DKIM / DMARC,  acting as a mailing list whe=
re senders aren't on the same mail server as you host is problematic for mai=
ling lists where you are essentially forwarding/sending email on behalf of s=
omeone on another domain.
>>=20
>> I raised this issue on this mailing list recently and you replied that it=
's semi possible when using 1.4.1, but would need to configure something bef=
ore mlmmj like rspamd.
>>=20
>> I appreciate that From-munging is a horrible workaround (I personally don=
't like it either) - but this is the approach that Google takes with their m=
ailing lists and it's the only workaround I've identified that works if the s=
enders SPF / DKIM / Dmarc records for their domain are set to reject email f=
rom other domains.
>>=20
>>=20
>> Do you think this is something you could add to mlmmj in 1.5 ?
>>=20
>> I'm thinking this would be a 'frommungle' file flag.  And when present, a=
utomatically:
>> - replaces the 'FROM' with the from specified within the file.
>> - strips any of the original senders headers that are part of the origina=
l senders SPF / DMARC / DKIM checks.
>> - perhaps adds a X-Original-=46rom header with the original senders email=
 address.
>>=20
>>=20
>>=20
>> Cheers
>> Kent
>>=20
>>=20
>>=20
>>>> On 4 May 2024, at 2:39=E2=80=AFAM, Baptiste Daroussin <[email protected]> w=
rote:
>>>=20
>>> Hello everyone,
>>>=20
>>> Now that mlmmj 1.4 seems to have properly settle, I would like to propos=
e a roadmap for mlmmj 1.5,
>>> please find here:
>>>=20
>>> https://codeberg.org/mlmmj/mlmmj/issues?type=3Dall&sort=3D&state=3Dopen&=
labels=3D&milestone=3D4774&project=3D0&assignee=3D0&poster=3D0
>>>=20
>>> The list of tasks I plan to do before releasing mlmmj 1.5.0
>>>=20
>>> Do not hesitate to comment, discuss and propose other tasks.
>>>=20
>>> Basically 1.4 was mostly: modernize the code base (this is not finished,=
 but advanced enough) and provide a test suite. for 1.5 I plan to cleanup fe=
atures which in my opinion do not make sense anymore because they break fiel=
ds used for DKIM signatures and implement the feature that has been requeste=
d by people here over the last year.
>>>=20
>>> I have no ETA for 1.5.0 it will be released when it will be released.
>>>=20
>>> Extra note, I would really love to get access to mlmmj.org to fix the ma=
iling list with dkim and to be able to update the website or point it to cod=
eberg.
>>>=20
>>> Best regards,
>>> Bapt
>>>=20
>>>=20
>>=20