Asai skrev den 2020-08-06 00:08:
to allow clients you should enable ports submission (587) and
submissions
(465) in master.cf.
Thanks for your reply. We are already doing that. The main question
is just what will break if we allow TLS only. Do you have any
experience with this?
nothing
to allow clients you should enable ports submission (587) and submissions
(465) in master.cf.
Thanks for your reply. We are already doing that. The main question is
just what will break if we allow TLS only. Do you have any experience
with this?
Thank you,
Asai
John Regan wrote:
> Subject: Forwarding best practices
...
> Can someone recommend a set of best practices for using postfix to relay
> mail to yahoo/gmail in this way?
The Best Practice for forwarding today is not to do it. It has long
been a friendly allowed practice on the net. But as Yahoo,
On Wed, Aug 05, 2020 at 10:41:13AM -0300, SysAdmin EM wrote:
> My problem is that I cannot deliver the mail because the greylist does not
> allow it and in some cases I also receive the same error in the other MXs.
Receiving the same greylist error from the second MX has the positive
effect of
On Wed, Aug 05, 2020 at 11:11:45AM -0300, SysAdmin wrote in
:
I think I have found what I need, I must increase the value of the
parameter "transport_retry_time".
I will increase the value and I will see how it behaves thanks to everyone
for helping me, take good care
What matters most is
I think I have found what I need, I must increase the value of the
parameter "transport_retry_time".
### transport_retry_time (default: 60s)
The time between attempts by the Postfix queue manager to contact a
malfunctioning message delivery transport.
Time units: s (seconds), m (minutes), h
Is it possible to change the retransmission time to the second max?
El mié., 5 de ago. de 2020 a la(s) 10:41, SysAdmin EM (emaw...@gmail.com)
escribió:
> Viktor,
>
> My problem is that I cannot deliver the mail because the greylist does not
> allow it and in some cases I also receive the same
Viktor,
My problem is that I cannot deliver the mail because the greylist does not
allow it and in some cases I also receive the same error in the other MXs.
# Example
Jul 31 09:30:08 smarthost03-ded postfix/smtp[22475]: A88B418003D5B:
to=, relay=mx7.webfaction.com[185.20.49.162]:25,
delay=969,
On Wed, 5 Aug 2020 at 08:36, Guido Goluke, MajorLabel
wrote:
I have a setup where I filter smtp mail with:
smtpd_milters=unix:/spamass/spamass.sock,
unix:/var/run/opendkim/opendkim.sock
and non-smtp mail with
non_smtpd_milters=unix:/spamass/spamass.sock,
On Wed, 5 Aug 2020 at 08:36, Guido Goluke, MajorLabel
wrote:
I have a setup where I filter smtp mail with:
smtpd_milters=unix:/spamass/spamass.sock,
unix:/var/run/opendkim/opendkim.sock
and non-smtp mail with
non_smtpd_milters=unix:/spamass/spamass.sock,
On Wed, 5 Aug 2020 at 08:36, Guido Goluke, MajorLabel
wrote:
>
> I have a setup where I filter smtp mail with:
>
> smtpd_milters=unix:/spamass/spamass.sock,
> unix:/var/run/opendkim/opendkim.sock
>
> and non-smtp mail with
>
> non_smtpd_milters=unix:/spamass/spamass.sock,
>
I have a setup where I filter smtp mail with:
smtpd_milters=unix:/spamass/spamass.sock,
unix:/var/run/opendkim/opendkim.sock
and non-smtp mail with
non_smtpd_milters=unix:/spamass/spamass.sock,
unix:/var/run/opendkim/opendkim.sock
But when I receive non-smtp mail (typically LMTP, from a
12 matches
Mail list logo
