Op 8/4/2015 om 5:03 PM schreef Christoph Gröver:
> Hello ML, Hello Stephan,
>
>> Hmm. Probably, the timezone configuration (i.e. the contents of TZ
>> timezone environment variable) somehow doesn't reach the final stages
>> of e-mail delivery.
> Well. I tried several ways of telling the lda or wha
Hello ML, Hello Stephan,
> Hmm. Probably, the timezone configuration (i.e. the contents of TZ
> timezone environment variable) somehow doesn't reach the final stages
> of e-mail delivery.
Well. I tried several ways of telling the lda or whatever is setting up
the INTERNALDATE to use the CEST +0
Hallo Stephan,
>
> Hmm. Probably, the timezone configuration (i.e. the contents of TZ
> timezone environment variable) somehow doesn't reach the final stages of
> e-mail delivery.
I investigated further.
I just did a telnet into the server and discoverered that dovecot knows the
localtime. If
Thanks Stephan for your answer.
>
> Hmm. Probably, the timezone configuration (i.e. the contents of TZ
> timezone environment variable) somehow doesn't reach the final stages of
> e-mail delivery.
Sorry, I just found out we had pigeonhole-0.4.3 running on the old server.
The sources of 0.2.5 w
Christoph Gröver schreef op 31-7-2015 om 16:01:
We are using the following setup:
Dovecot-2.2.18
Pigeonhole-0.4.8 (for Dovecot-2.2)
After the mail is finally delivered via a fileinto by the Sieve filter
it gets an updated timestamp (modification time).
The server has localtime setup correctl
Hi List,
We are using the following setup:
Dovecot-2.2.18
Pigeonhole-0.4.8 (for Dovecot-2.2)
After the mail is finally delivered via a fileinto by the Sieve filter
it gets an updated timestamp (modification time).
The server has localtime setup correctly IMO (UTC +0200), but still the
delivere
