With one is better and why do you think so?
I’m going to chose one and would like to know your opinion
regards
vonProteus
Flamebait question, but I happened to configure both (repository versions)
recently, so here's one opinion. Both are useable, and used. Exim is sold as
easier to configure, but IMO it doesn't deliver on this - probably simple
config is just an impossible thing for universal SMTP MTA. On the othe
Is there a simple way to temporarily stop postfix delivering mail into the
/var/vmail mail boxes, instead queueing them up? The purpose being to get a
clean backup of /var/vmail without stopping receipt of mail from the internet.
Then restart mail delivery so the queue is emptied into the approp
On 2017-12-25 09:31:07 (+0100), vonProteus wrote:
With one is better and why do you think so?
I’m going to chose one and would like to know your opinion
Well ... you're asking on the Postfix mailing list. Obviously people
are going to answer Postfix. :)
To be honest, I never looked at Exim.
my ultimate goal is to configure MTA in that way that i'm able to use it as
a mail relay station
sorry for my not fully technical and poor language
my idea is that i recently encounter more and more email forms which do not
allow me to use + addressing
so my idea is to setup my own MTA which will r
On 25.12.2017 11:14, Black Sheep wrote:
> Is there a simple way to temporarily stop postfix delivering mail into
> the /var/vmail mail boxes [...]
The following method works (I'm not certain if reloading is even
required):
#!/bin/bash
# Temporarily disable local delivery
postconf -e defer_transp
[Please don't top-post. Formatting repaired.]
On 2017-12-25 11:20:40 (+0100), vonProteus wrote:
On Mon, Dec 25, 2017 at 10:04 AM, Marat Khalili wrote:
Flamebait question, but I happened to configure both (repository
versions) recently, so here's one opinion. Both are useable, and used.
Exim
Thanks, looks good. I’d think the reload probably is necessary.
Martin
On 25 Dec 2017, 10:30 +, Ralph Seichter ,
wrote:
> On 25.12.2017 11:14, Black Sheep wrote:
>
> > Is there a simple way to temporarily stop postfix delivering mail into
> > the /var/vmail mail boxes [...]
>
> The following
Black Sheep:
> Is there a simple way to temporarily stop postfix delivering mail
> into the /var/vmail mail boxes, instead queueing them up? The
> purpose being to get a clean backup of /var/vmail without stopping
> receipt of mail from the internet. Then restart mail delivery so
> the queue is emp
On 12/25/2017 12:31 AM, vonProteus wrote:
With one is better and why do you think so?
I’m going to chose one and would like to know your opinion
Interesting you should ask this on the Postfix mailing list. Especially
since because there is no "right" answer.
Over the years, I've worked with
Before taking backup or other action that requires stopping mail delivery I usually just stop all postfix instances which MX record points.
> On Dec 25, 2017, at 3:31 AM, vonProteus
> wrote:
>
> With one is better and why do you think so?
> I’m going to chose one and would like to know your opinion
Disclaimer: I am a Postfix developer and user, and hang out on the
Exim lists only because I've contributed some DANE-related code to
> On Dec 25, 2017, at 5:14 AM, Black Sheep
> wrote:
>
> Is there a simple way to temporarily stop postfix delivering mail into the
> /var/vmail mail boxes, instead queueing them up? The purpose being to get a
> clean backup of /var/vmail without stopping receipt of mail from the
> internet.
Wietse Venema:
> Black Sheep:
> > Is there a simple way to temporarily stop postfix delivering mail
> > into the /var/vmail mail boxes, instead queueing them up? The
> > purpose being to get a clean backup of /var/vmail without stopping
> > receipt of mail from the internet. Then restart mail deliv
On 2017-12-25 13:58:53 (-0500), Wietse Venema wrote:
Wietse Venema:
Black Sheep:
> Is there a simple way to temporarily stop postfix delivering mail
> into the /var/vmail mail boxes, instead queueing them up? The
> purpose being to get a clean backup of /var/vmail without stopping
> receipt of m
I quickly checked my policyd-spf setting after read your email. I
noticed that the policyd-spf in my system is not running as a service.
I guess you are using debian. I am using CentOS7 and I installed
pypolicyd-spf from EPEL. So is there a big advantage to running it as a
daemon service? How
I'd like to update and migrate my current Postfix 2.1 to an up to date
version, it's a Postfix/Dovecot/MySQL/smtp auth/ virtual domains/users
I've installed new Centos 7 with ghettoforge postfix 3.2.4 /dovecot, and,
copied over /etc/postfix etc/dovecot, after some minor edits (remove
policyd 1.x,
whilst installing/configuring 2.1 to 3.2.x migration
(using 2.1 main/master on 3.2 install), noticed these errors:
anything to worry about ?
# grep 'TLS library problem' /var/log/maillog*
/var/log/maillog:Dec 25 08:39:21 geko postfix/smtpd[9701]: warning: TLS
library problem: error:140760FC:SSL
I figured I would middle post, so skip down a bit.
On Mon, 25 Dec 2017 11:56:02 -0800
Gao wrote:
> I quickly checked my policyd-spf setting after read your email. I
> noticed that the policyd-spf in my system is not running as a service.
>
> I guess you are using debian. I am using CentOS7 and
> On Dec 25, 2017, at 8:57 PM, li...@sbt.net.au wrote:
>
> anything to worry about ?
Generally no. There are some SMTP clients that both TLS,
they'll either retry in the clear, or they are likely shoddy
spamware.
> # grep 'TLS library problem' /var/log/maillog*
> /var/log/maillog:Dec 25 08:39
>> On Dec 25, 2017, at 8:57 PM, li...@sbt.net.au wrote:
>>
>> anything to worry about ?
>
> Generally no. There are some SMTP clients that both TLS,
> they'll either retry in the clear, or they are likely shoddy
> spamware.
> Other log messages will show the IP address of the client. If you weren
>> On Dec 25, 2017, at 8:57 PM, li...@sbt.net.au wrote:
> This of course assumes you've not configured particularly exotic TLS
> settings on your end.
Viktor,
thanks again, I hope it's not exotic, not to my knowledge, anyhow:
that that show what it is ? suggestions and corrections appreciated
> On Dec 26, 2017, at 1:34 AM, li...@sbt.net.au wrote:
>
>>
>> Generally no. There are some SMTP clients that both TLS,
s/both/botch/
Hope that's less confusing.
>> they'll either retry in the clear, or they are likely shoddy
>> spamware.
>> Other log messages will show the IP addre
> On Dec 26, 2017, at 1:39 AM, li...@sbt.net.au wrote:
Overall quite standard. Nothing to worry about.
> smtpd_tls_session_cache_timeout = 36000s
10 hours is perhaps too long to be useful. Just let the default stand.
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
On December 25, 2017 10:25:42 PM EST, "li...@lazygranch.com"
wrote:
>I figured I would middle post, so skip down a bit.
>
>On Mon, 25 Dec 2017 11:56:02 -0800
>Gao wrote:
>
>> I quickly checked my policyd-spf setting after read your email. I
>> noticed that the policyd-spf in my system is not
>> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>
> With Postfix 2.11 or later, just leave this empty, session tickets work
> better.
Viktor, thanks
does 'leave empty' means have it present on main.cf up to '=' ?
as so ?
smtpd_tls_session_cache_database =
26 matches
Mail list logo
