> That is a compiler bug. 620 static ATTR_OVER_TIME time_table[] = { 621
> 7 + VAR_MILT_CONN_TIME, DEF_MILT_CONN_TIME, 0, 1, 0,
> VAR_MILT_CONN_TIME is a constant ("milter_connect_timeout") therefore
> 7 + VAR_MILT_CONN_TIME ("connect_timeout") is a constant.
Good hint, thank you. I was able to
Jan P. Kessler:
>
> > That is a compiler bug. 620 static ATTR_OVER_TIME time_table[] = { 621
> > 7 + VAR_MILT_CONN_TIME, DEF_MILT_CONN_TIME, 0, 1, 0,
> > VAR_MILT_CONN_TIME is a constant ("milter_connect_timeout") therefore
> > 7 + VAR_MILT_CONN_TIME ("connect_timeout") is a constant.
>
> Good
Pali Roh?r:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> On Wednesday 16 January 2019 07:21:49 Wietse Venema wrote:
> > Pali Roh?r:
> > > Hello, it is possible to accept emails with 5xx status code?
> >
> > By replying with 5XX after SMTP end-of-data.
>
> And
Matus UHLAR - fantomas:
[ Charset ISO-8859-2 converted... ]
> >> Pali Roh?r:
> >> > Hello, it is possible to accept emails with 5xx status code?
>
> >On Wednesday 16 January 2019 07:21:49 Wietse Venema wrote:
> >> By replying with 5XX after SMTP end-of-data.
>
> On 20.01.19 17:36, Pali Roh?r
On Wednesday 16 January 2019 07:21:49 Wietse Venema wrote:
> Pali Roh?r:
> > Hello, it is possible to accept emails with 5xx status code?
>
> By replying with 5XX after SMTP end-of-data.
And how to configure it? In postconf.5 I do not see anything which could
be used for this purpose.
--
Pali
Pali Roh?r:
> Hello, it is possible to accept emails with 5xx status code?
On Wednesday 16 January 2019 07:21:49 Wietse Venema wrote:
By replying with 5XX after SMTP end-of-data.
On 20.01.19 17:36, Pali Rohár wrote:
And how to configure it? In postconf.5 I do not see anything which could
Jan P. Kessler:
>
> > No idea. It if works, great. Otherwise, try compiling with this
> > workaround:
>
> It works! Thanks to postfix and easy "make upgrade" the migration took
> only seconds. I didn't even had to clear caches (tls,
> recipient_verification) or such. Cool! Case closed.
To
> "Durga" == Durga Prasad Malyala writes:
Durga> Correct. I would recommend linode or digitalocean any time over
Durga> AWS SES. AWS is a good option for heavy transactional mail
Durga> alerts etc.
The only problem with Digital Ocean right now is that Charter/Spectrum
in the US has
> No idea. It if works, great. Otherwise, try compiling with this
> workaround:
It works! Thanks to postfix and easy "make upgrade" the migration took
only seconds. I didn't even had to clear caches (tls,
recipient_verification) or such. Cool! Case closed.
Btw - nice for me to see, that
Randomly postfix is marking this as expired certificate and after some time
marking certificate as valid.
I have verified that certificate is not expired by taking pcap. Let me know
if is there any known defect in postfix of this sort ?
certificate details :
On Mon, Jan 21, 2019 at 12:40:52AM -0700, phoenixsagar wrote:
> Logs are like :
> postfix/backend/smtp[95117]: CA certificate verification failed for
> abc-abc.mail.abc.outlook.com[111.111.111.111]:25: certificate has expired
> postfix/backend/smtp[95117]: Untrusted TLS connection established to
I have Postfix Admin’s Vacation setup and would like to use the Perl at
/usr/local/bin/perl rather than /usr/bin/perl.
I have:
vacationunix- n n - - pipe
flags=DRhu user=_vacation argv="/usr/local/bin/perl
/var/spool/vacation/vacation.pl" -f
On 21 Jan 2019, at 3:59 pm, James Brown wrote:
>
> I have Postfix Admin’s Vacation setup and would like to use the Perl at
> /usr/local/bin/perl rather than /usr/bin/perl.
>
> I have:
>
> vacationunix- n n - - pipe
>flags=DRhu user=_vacation
13 matches
Mail list logo
