stenur changed the topic of #mailx to: SysV mail/BSD Mail/POSIX mailx: send and receive Internet mail | May take a day, Sundays never | Logs: https://libera.irclog.whitequark.org/mailx
_whitelogger has joined #mailx
<stenur>
rahl: unfortunately not; will not work out; currently impossible to remove Date:, nor not to generate it.
<stenur>
rahl: thanks for the report, will be fixed soonish!
<stenur>
rahl: with credits to rahl@otaku.sdf.org, is that ok?
<stenur>
yep, we "know" about "Date:", this is why reject removing it via the digmsg command, which would otherwise have been the solution. As in
<stenur>
ie via on-compose-splice and then "digmsg create -" and "digmsg - header remove date".
<stenur>
Not comforting that on-compose-splice will be obsolete in v14.10 due to the much easier, safer and overly better on-compose-embed.
<stenur>
*sigh*
<stenur>
ok i have at least temporarily credited "rahl" with your sdf address; please say.
<stenur>
For now this works (on development branch) via
<stenur>
smtpserveroption = -~:/
<stenur>
smtpserveroption = -X define oce {
<stenur>
smtpserveroption = -X ~^ header remove date
<stenur>
However, maybe we should either remove Date: that comes via -t automatically, *or* instead simply take it "as-is".
<stenur>
I dimly remember i never wanted the latter, as it, hm, lies. Therefore the former it will likely be.
<stenur>
Bug in since at least 14.9.16 i think. Thanks again for reporting. I have not used git-send-email for a very long time, it sucks in so many dependencies that i dropped its usage. However here it now comes in automatically; on AlpineLinux it is luckily still missing.
<stenur>
Ie, i simply send the patch or series directly.
<stenur>
rahl: i also have implemented skipping Date: now, so above on-compose-embed is not necessary.
<stenur>
In v14.10 that is. For v15 there will then finally be the MIME rewrite, so that -t can actually dig complete MIME messages.
<stenur>
..and it *could* be that then Date: will be taken as-is. (Though the idea is that we then have a tree of objects, and either dump-to-user or dump-to-wire, ie, it will actually generate the "final product", which could use different MIME encodings etc.; i do not know yet. But anyway no user should ever have a need to think about all that.)