Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote:
> On Fri, Jan 26, 2018 at 6:32 PM, Michal Suchánek <msuchanek@xxxxxxx> wrote:
> > This is wrong because the message will most likely not get delivered
> > when the author date differs from current time.
Even by a few seconds? I guess it depends on how many patches
you're sending at once. It uses number of patches to set Date:
header:
$time = time - scalar $#files;
(and does $time++ for each patch)
> Others have covered other bases here, but I just wanted to ask about
> this. Are there really mail setups that refuse to deliver or accept
> messages whose Date headers don't match what the expect? I would think
> that such issues wouldn't be present in the wild since SMTP daemons
> need to deal with messages that are e.g. held locally somewhere, or
> the only make it to your server days afterwards due to your own
> downtime + client retries.
Having a Date that's far off is one of many indicators used to
determine spam. SpamAssassin has a rules and scores which do
this, but it looks like the smallest one is for 3 and 6 hours
in the past (DATE_IN_PAST_03_06) so one would need 10800 patches
to trigger it (!?)
I definitely had problems back in the day with author date
being used as the Date: header, see:
commit 1d6a003a42b3c23ad7883b0bbe6a034728e51836
("git-send-email: do not pass custom Date: header")
