I have a situation where my primary/final MX server will be down for
an indefinite period of time, possibly up to a week. During that time
I would like to have the secondary MX server to keep every message
queued, and keep on retrying, without ever "timing out" and without
sending any
On Fri, Jan 04, 2019 at 10:40:21PM -0200, Rafael Azevedo wrote:
> > postfix -c /etc/postfix/ start
>
> this is how we start postfix intances since this server has multiple
> testing configurations.
Because the correct command is just "postfix start". And you want
multiple instances read
> No you did not. By default "MAIL_CONFIG=/etc/postfix" with no trailing "/".
> Perhaps you're starting Postfix via:
>
> postfix -c /etc/postfix/ start
this is how we start postfix intances since this server has multiple
testing configurations.
> don't do that.
why?
and why shall I
On Fri, Jan 04, 2019 at 10:22:28PM -0200, Rafael Azevedo wrote:
> Ok, got it back to default config.
> # postmulti -l
> - - y /etc/postfix
>
> # pgrep -x qmgr | while read pid; do ps -o pid,ppid,args -p "$pid";
> xargs -0n1 < /proc/$pid/environ; done
> PID
> Well, I don't recall any mention of multiple Postfix configurations
> until now. For "sendmail" to work in a non-default Postfix instance
> the associated configuration directory must be listed in the default
> instance's main.cf file's "alternate_config_directories" parameter.
Ok, got it back
On Fri, Jan 04, 2019 at 09:57:53PM -0200, Rafael Azevedo wrote:
> I've provided all information you asked.
Well, but you've provided detailed configuration information.
See http://www.postfix.org/DEBUG_README.html#mail
> This is a lab server.
> It has about 8 IPs and multiple postfix
Hi Viktor,
Thanks for your reply.
I've provided all information you asked.
This is a lab server.
It has about 8 IPs and multiple postfix configurations (from older tests).
Although this server has multiple IPs, I'm not running multiple
instances at this time.
The pourpose of this test is to
> On Jan 4, 2019, at 6:18 PM, Rafael Azevedo wrote:
>
> # postmulti -l
> - - y /etc/postfix
>
> # postfix status
> postfix: Postfix is running with backwards-compatible default settings
> postfix: See http://www.postfix.org/COMPATIBILITY_README.html for
# postmulti -l
- - y /etc/postfix
# postfix status
postfix: Postfix is running with backwards-compatible default settings
postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details
postfix: To disable backwards compatibility use "postconf
> On Jan 4, 2019, at 5:13 PM, Rafael Azevedo wrote:
>
> They don't. But there might be some variable with undesired default value.
>
> # cd /etc/postfix/
> lab postfix # grep 'config_directory' main.cf master.cf
So the unwanted value was acquired at runtime.
Post the output of:
# postmulti
They don't. But there might be some variable with undesired default value.
# cd /etc/postfix/
lab postfix # grep 'config_directory' main.cf master.cf
lab postfix #
Em sex, 4 de jan de 2019 às 20:11, Viktor Dukhovni
escreveu:
>
>
>
> > On Jan 4, 2019, at 4:59 PM, Rafael Azevedo wrote:
> >
>
great idea, but recipient verification is not something, remote servers
like.really like.
Am Freitag, 4. Januar 2019 schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:
>> On Jan 4, 2019, at 9:10 AM, Matus UHLAR - fantomas
wrote:
>>
>> this looks to me that you search for connection between
> THAT IS POLICY DELEGATION PROTOCOL NOT CONTENT FILTER.
What are the differences?
> On Jan 4, 2019, at 4:59 PM, Rafael Azevedo wrote:
>
>>> Jan 4 17:41:54 lab postfix/pipe[2027085]: EE5D013E179F:
>>> to=, relay=post_queue_content_filter, delay=1.1,
>>> delays=0.04/0/0/1, dsn=4.3.0, status=deferred (temporary failure.
>>> Command output: postdrop: error: untrusted
In fact I didn't.
There's no config_directory set in my main.cf file.
Em sex, 4 de jan de 2019 às 18:46, Viktor Dukhovni
escreveu:
>
> > On Jan 4, 2019, at 3:37 PM, Rafael Azevedo wrote:
> >
> > Jan 4 17:41:54 lab postfix/pipe[2027085]: EE5D013E179F:
> > to=, relay=post_queue_content_filter,
On 04.01.19 18:41, Rafael Azevedo wrote:
Thanks a lot for the help.
I tried setting the FILTER to localhost:otherport-with-no-filter but
had same behavior.
action=FILTER localhost:10026
where did you set it? it's your own filter, it's not postfix, I have no idea
what you need to set ...
Em
On Fri, 4 Jan 2019 15:22:08 -0500 (EST)
Wietse Venema wrote:
> Celejar:
> > On Fri, 4 Jan 2019 13:19:10 -0500 (EST)
> > Wietse Venema wrote:
> >
> > > Celejar:
> > > > Okay, by testing with swaks I've confirmed the suspicion that I broached
> > > > in my previous mail: on the problematic
> On Jan 4, 2019, at 3:37 PM, Rafael Azevedo wrote:
>
> Jan 4 17:41:54 lab postfix/pipe[2027085]: EE5D013E179F:
> to=, relay=post_queue_content_filter, delay=1.1,
> delays=0.04/0/0/1, dsn=4.3.0, status=deferred (temporary failure.
> Command output: postdrop: error: untrusted configuration
Hi Matus,
Thanks a lot for the help.
I tried setting the FILTER to localhost:otherport-with-no-filter but
had same behavior.
action=FILTER localhost:10026
no success.
Em sex, 4 de jan de 2019 às 18:36, Matus UHLAR - fantomas
escreveu:
>
> >> You forgot to send it back into Postfix.
>
> On
> FILTER_README has examples for doing that with /usr/sbin/sendmail
> and with SMTP.
Has anybody ever made that example work?
There's no way.
post_queue_content_filterunix- n n - -
pipe
flags=Rq user=myuser null_sender=
You forgot to send it back into Postfix.
On 04.01.19 16:47, Rafael Azevedo wrote:
Would you please tell me how to send it back to POSTFIX ?
call sendmail and pass te message to it, or sent it to postfix via
SMTP/LMTP, apparently on different port where content_filter is turned off,
so
Celejar:
> On Fri, 4 Jan 2019 13:19:10 -0500 (EST)
> Wietse Venema wrote:
>
> > Celejar:
> > > Okay, by testing with swaks I've confirmed the suspicion that I broached
> > > in my previous mail: on the problematic system, the rewrite of the email
> > > header 'From: root' is to 'From: (root)',
> On Jan 4, 2019, at 2:56 PM, Celejar wrote:
>
> And I'm using 3.1.8, where the rewriting isn't acceptable to my mail
> provider, and this feature isn't available ;) So I guess I'm stuck,
> unless I can upgrade Postfix?
Your other option, if possible, is to inject email into Postfix
with the
On Fri, 4 Jan 2019 13:19:10 -0500 (EST)
Wietse Venema wrote:
> Celejar:
> > Okay, by testing with swaks I've confirmed the suspicion that I broached
> > in my previous mail: on the problematic system, the rewrite of the email
> > header 'From: root' is to 'From: (root)', which
> > causes the
Rafael Azevedo:
> Another attempt:
>
> Jan 4 16:39:21 lab postfix/pipe[2026654]: 82B8813DF90D:
> to=, relay=post_queue_content_filter, delay=0.07,
> delays=0.04/0/0/0.03, dsn=2.0.0, status=sent (delivered via
> post_queue_content_filter service (action=FILTER localhost:10026))
THAT IS POLICY
Rafael Azevedo:
> Hi Wietse,
>
> Thanks for your help.
>
> > You forgot to send it back into Postfix.
>
> Would you please tell me how to send it back to POSTFIX ?
FILTER_README has examples for doing that with /usr/sbin/sendmail
and with SMTP.
Wietse
Another attempt:
Jan 4 16:39:21 lab postfix/pipe[2026654]: 82B8813DF90D:
to=, relay=post_queue_content_filter, delay=0.07,
delays=0.04/0/0/0.03, dsn=2.0.0, status=sent (delivered via
post_queue_content_filter service (action=FILTER localhost:10026))
NOTE:
action=FILTER localhost:10026
The
Digging on FILTER_README, I've noticed that:
The content_filter setting has lower precedence than a FILTER
action that is specified in an access(5), header_checks(5) or
body_checks(5) table.
Even using OK, PREPEND, the message could not go back into queue.
JIT:
ACCEPT ACTIONS
OK
On 04.01.19 15:23, Christopher R. Gabriel wrote:
I have a generator server which injects (via smtp) into postfix, the
actual sender, and when burst of delivery happens, the receiving
postfix stuck before answering to the generator, which causes the
generator queues to fill up.
Nov 30 09:11:58
Hi Wietse,
Thanks for your help.
> You forgot to send it back into Postfix.
Would you please tell me how to send it back to POSTFIX ?
> BTW what is that "action=PERMIT" stuff? There is no such feature
> with Postfix filters. Are you confusing SMTPD_POLICY_README and
> FILTER_README?
Yes, I
Rafael Azevedo:
> Looking my log files:
>
> Jan 4 13:58:19 lab postfix/pipe[2025749]: 193EA13DB044: to=,
> > orig_to=, relay=post_queue_content_filter, delay=0.11,
> > delays=0.09/0/0/0.02, dsn=2.0.0, status=sent (delivered via
> > post_queue_content_filter service (action=PERMIT))
>
> After
Try create another postfix instance and force your filter send message to it.
De: owner-postfix-us...@postfix.org em nome
de Rafael Azevedo
Enviado: sexta-feira, 4 de janeiro de 2019 16:21
Para: Postfix users
Assunto: Re: Content filter - reijnect message back
Viktor,
After doing as explained @ http://www.postfix.org/FILTER_README.html, I'm
still having same behavior.
Jan 4 15:23:16 zimuslab postfix/pipe[2026324]: 90FAD13DE3B1: to=,
relay=post_queue_content_filter, delay=0.07, delays=0.04/0/0/0.02,
dsn=2.0.0, status=sent (delivered via
On Wed, 2 Jan 2019 19:58:18 -0500
Viktor Dukhovni wrote:
> > On Jan 2, 2019, at 7:12 PM, Celejar wrote:
> >
> > I'm configuring Postfix to relay mail via a smarthost, and I need to
> > rewrite the sender address in order for the smarthost to accept the
> > mail (and not reject it as
Hi Viktor,
Thanks for the tip.
I did my best within my knowledges to archive that goal.
After reading that document so many times this was the farther I could go.
Another tip would be much appreciated.
BR,
Em sex, 4 de jan de 2019 às 15:28, Viktor Dukhovni <
postfix-us...@dukhovni.org>
> On Jan 4, 2019, at 11:54 AM, Rafael Azevedo wrote:
>
> So I kindly ask you guys how can I re-inject message back into queue.
http://www.postfix.org/FILTER_README.html
--
Viktor.
Hi there,
I'm trying to build my own content filter so I can actually filter outgoing
messages and take appropriated actions upon spam messages.
After some time I was able to make postfix send messages to the content
filter.
The documentation says that content_filter expects a "transport:maps"
On 4 Jan 2019, at 10:36, Stefan Bauer wrote:
Would it be possible to have FILTER as action in policy server
Yes, but FILTER behaves as documented in the access(5) man page. The
first 5 words there describing what FILTER does are critical, but you
should read it all...
(in
On Fri, 2019-01-04 at 10:26 -0500, Viktor Dukhovni wrote:
> > On Jan 4, 2019, at 10:04 AM, Christopher R. Gabriel <
> > christopher.gabr...@gmail.com> wrote:
> >
> > > Or some tables you're using in cleanup are slow.
> >
> > I only have a header_checks table with 1 single rule to log a
> >
> On Jan 4, 2019, at 9:10 AM, Matus UHLAR - fantomas wrote:
>
> this looks to me that you search for connection between
> smtpd_recipient_restrictions
> and smtp_tls_policy_maps, and there is none.
>
> the "check_policy_service private/policy" communicates via unix socket
> private/policy
Would it be possible to have FILTER as action in policy server (in
recipient_restrictions) and send it to smtp process that uses header_checks
do have mailroute based on subject?
Am Fr., 4. Jan. 2019 um 16:08 Uhr schrieb Bill Cole <
postfixlists-070...@billmail.scconsult.com>:
> On 4 Jan
> On Jan 4, 2019, at 10:04 AM, Christopher R. Gabriel
> wrote:
>
>> Or some tables you're using in cleanup are slow.
>
> I only have a header_checks table with 1 single rule to log a specific
> header, and a transport map redis-based. Exactly the same configuration
> I have on postfix 2.x.
On 4 Jan 2019, at 9:36, Stefan Bauer wrote:
is there a way to bypass policy server in smtp_recipient_restrictions,
in
case, subject contains special string?
No. As documented, smtp_recipient_restrictions is evaluated for each
RCPT command, all of which occur before the DATA command, which
On Fri, 2019-01-04 at 09:49 -0500, Viktor Dukhovni wrote:
> > On Jan 4, 2019, at 9:23 AM, Christopher R. Gabriel <
> > christopher.gabr...@gmail.com> wrote:
> >
> > Nov 30 09:11:31 postfix01 postfix-main/smtpd[31800]: rec_put: type
> > E
> > len 0 data
> > Nov 30 09:11:31 postfix01
> On Jan 4, 2019, at 7:23 AM, Wietse Venema wrote:
>
> For one delivery request, the Postfix SMTP client gets up to
> five ($smtp_mx_address_limit) addresses from DNS, and burns through
> those addresses in a split second as they fail with ECONNREFUSED.
> Instantly, he has used up his entire 5
> On Jan 4, 2019, at 9:23 AM, Christopher R. Gabriel
> wrote:
>
> Nov 30 09:11:31 postfix01 postfix-main/smtpd[31800]: rec_put: type E
> len 0 data
> Nov 30 09:11:31 postfix01 postfix-main/smtpd[31800]:
> vstream_fflush_some: fd 18 flush 2433
> Nov 30 09:11:58 postfix01
Hi,
is there a way to bypass policy server in smtp_recipient_restrictions, in
case, subject contains special string?
smtpd_recipient_restrictions = check_policy_service unix:private/policy
header_checks:
/^Subject: .*string.*/ FILTER no-policy-service:
header_checks could reroute by subject
Understood. Thank you.
Am Fr., 4. Jan. 2019 um 15:11 Uhr schrieb Matus UHLAR - fantomas <
uh...@fantomas.sk>:
> On 04.01.19 14:44, Stefan Bauer wrote:
> >we have enforced TLS to all remote sites and have appropriate tls policy
> >server, that checks if TLS is avail before accepting mails. That
Hi,
after upgrading to Debian 9 (thus Postfix 3.1.8) I'm experiecing an odd
behaviour, which causes slowness on all the infrastructure.
I have a generator server which injects (via smtp) into postfix, the
actual sender, and when burst of delivery happens, the receiving
postfix stuck before
On 04.01.19 14:44, Stefan Bauer wrote:
we have enforced TLS to all remote sites and have appropriate tls policy
server, that checks if TLS is avail before accepting mails. That works as
expected. we also only accept users with auth.
smtpd_relay_restrictions = permit_mynetworks
Hi,
we have enforced TLS to all remote sites and have appropriate tls policy
server, that checks if TLS is avail before accepting mails. That works as
expected. we also only accept users with auth.
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
reject_unauth_destination
Viktor Dukhovni:
> Likely I am missing some key insight, please pardon any confusion...
The ISP provides a budget of 5 connections/second, enforced at the
firewall level. The OP's logging shows ECONNREFUSED when the Postfix
scheduler rate limits to <1 delivery request per second. How can
that be?
52 matches
Mail list logo
