and check_policy_service
An: Postfix users
Klaus Tachtler via Postfix-users:
Hello,
just so I understand correctly, the recommendation would be to use
smtpd_end_of_data_restrictions, despite the warning in the Dovecot log?
No. The recommendation is to use the software as intended by
Klaus Tachtler via Postfix-users:
> Hello,
>
> just so I understand correctly, the recommendation would be to use
> smtpd_end_of_data_restrictions, despite the warning in the Dovecot log?
No. The recommendation is to use the software as intended by its
author, not at end-of-data.
Wietse
smtpd_end_of_data_restrictions. In the
documentation under the following link
https://www.postfix.org/SMTPD_ACCESS_README.html#lists there is an
example which looks like this:
# Enforce mail volume quota via policy service callouts.
smtpd_end_of_data_restrictions = check_policy_service
ce mail volume quota via policy service callouts.
> smtpd_end_of_data_restrictions = check_policy_service unix:private/policy
>
> If I configure this as follows:
>
> smtpd_end_of_data_restrictions = check_policy_service
> inet:imap.server.tld:12340
>
> I get
.
smtpd_end_of_data_restrictions = check_policy_service
unix:private/policy
If I configure this as follows:
smtpd_end_of_data_restrictions = check_policy_service
inet:imap.server.tld:12340
I get the following WARNING message in the Dovecot log:
quota-status(5043): Warning: Received policy query from MTA in
On Wed, Mar 27, 2024 at 10:41:08AM -0400, Wietse Venema via Postfix-users wrote:
> Viktor Dukhovni via Postfix-users:
> > On Tue, Mar 26, 2024 at 02:20:55PM -0400, Wietse Venema via Postfix-users
> > wrote:
> > > Viktor Dukhovni via Postfix-users:
> > > > That's fine, the SRV records can be keyed
Viktor Dukhovni via Postfix-users:
> On Tue, Mar 26, 2024 at 02:20:55PM -0400, Wietse Venema via Postfix-users
> wrote:
> > Viktor Dukhovni via Postfix-users:
> > > That's fine, the SRV records can be keyed by destination domain.
> >
> > Locally-managed SRV records, keyed by the final destination
On Tue, Mar 26, 2024 at 02:20:55PM -0400, Wietse Venema via Postfix-users wrote:
> Viktor Dukhovni via Postfix-users:
> > That's fine, the SRV records can be keyed by destination domain.
>
> Locally-managed SRV records, keyed by the final destination domain
> name, to select a local relay host?
Y
Viktor Dukhovni via Postfix-users:
> That's fine, the SRV records can be keyed by destination domain.
Locally-managed SRV records, keyed by the final destination domain
name, to select a local relay host?
Wietse
___
Postfix-users mailing list --
On Tue, Mar 26, 2024 at 05:22:52PM +, Colin McKinnon wrote:
> > What kind of "load balancing"? Why won't MX records do? For uneven
> > weights, you can even use SRV records:
>
> I'm trying to setup load balancing across a cluster of relays for a
> SAAS application. There's several problems
Hi Viktor,
Wietse also replied to say I wasn't able to solve this with Postfix.
>
> What kind of "load balancing"? Why won't MX records do? For uneven
> weights, you can even use SRV records:
>
I'm trying to setup load balancing across a cluster of relays for a
SAAS application. There's several
;.
It isn't actually a good tool for this, since it cannot affect
fine-grained per-recipient routing in multi-recipient messages.
It can only return FILTER actions which affect all recipients,
and the intent is to support content scanning, not fine-tune
routing.
> 1) Can I use check_
ent_restrictions'. I tried provisioning using:
Unfortunately, check_policy_service is documented and supported
only for smtpd_mumble_restrictions.
transport_maps queries one or more (key, value) stores. Given one
key, it returns one corresponding value (or not found, or error).
A policy is di
Hi,
Stuck again.
Using
smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:8822
smtpd_policy_service_default_action = DUNNO
I get:
Mar 26 15:49:03 test106 postfix/smtpd[163532]: warning: access
table inet:127.0.0.1:8822 has entry with lookup table:
smtp:[test105
Hi all,
I found that check_policy_service works (maybe*) in
`smtpd_end_of_data_restrictions =`. So I'm guessing it might work in
any *_restrictions configuration.
(*still having some issues getting this to work as expected, but I'll
come back here if I get stuck)
Colin
On Tue, 26 M
x.org/SMTPD_POLICY_README.html)
seems to be ideal for my requirements since I get both recipient_name
and helo_name, however the documentation only covers its use in the
context of 'smtpd_recipient_restrictions'. I tried provisioning using:
transport_maps = check_policy_service inet:127.0.0.1:8822
ha
Matus UHLAR - fantomas via Postfix-users:
> On 07.03.24 12:14, Wietse Venema via Postfix-users wrote:
> >The Postfix SMTP server counts only the recipients that it accepts,
> >not the ones that it rejects.
> >
> >That is, a DATA or BDAT command after all recipients are rejected
> >will result in a
On 07.03.24 12:14, Wietse Venema via Postfix-users wrote:
The Postfix SMTP server counts only the recipients that it accepts,
not the ones that it rejects.
That is, a DATA or BDAT command after all recipients are rejected
will result in a "554 5.5.1 Error: no valid recipients".
So I guess ther
Ralf Hildebrandt via Postfix-users:
> * Viktor Dukhovni via Postfix-users :
>
> > Note that if you want the actual recipient addresses, (not just a
> > count),
>
> I just need the count in this case
>
> > you'll need to also intercept recipient restrictions.
>
> oh!
>
> > The Postfix smtpd(8)
* Viktor Dukhovni via Postfix-users :
> Note that if you want the actual recipient addresses, (not just a
> count),
I just need the count in this case
> you'll need to also intercept recipient restrictions.
oh!
> The Postfix smtpd(8) server does not keep the recipient list in memory, the
> lis
On Thu, Mar 07, 2024 at 04:24:56PM +0100, Ralf Hildebrandt via Postfix-users
wrote:
> * Matus UHLAR - fantomas via Postfix-users :
>
> > > envelope sender address and number of recipients.
> >
> > not authenticated user? ;-)
>
> Yes, I'm also checking if the come from our exchangeserver.
>
> >
* Matus UHLAR - fantomas via Postfix-users :
> > envelope sender address and number of recipients.
>
> not authenticated user? ;-)
Yes, I'm also checking if the come from our exchangeserver.
> if you want to see/process mail size, using it in
> smtpd_end_of_data_restrictions is necessary.
> if
each a low
number of internal recipients before being restricted) as well as our
internal users (they can only reach a low number of external
recipients before being subject to inspection)
The integration into postfix boils down to:
smtpd_end_of_data_restrictions =
check_policy_service inet:
hey can only reach a low number of external
recipients before being subject to inspection)
The integration into postfix boils down to:
smtpd_end_of_data_restrictions =
check_policy_service inet:127.0.0.1:10040
Now postfwd3 is written in Perl, and that thing is hogging the CPU:
# ltrace
Wietse Venema:
> AFTER the message is received, the message size is known.
Thanks, Wietse. Makes sense now. Like this it works:
smtpd_recipient_restrictions = reject_unauth_destination
smtpd_end_of_data_restrictions = \
check_policy_service inet:localhost:12340
It's just a bit
Wietse Venema:
> Christoph Haas:
> > request=smtpd_access_policy
> > protocol_state=RCPT
> ...
> > size=0
>
> The RCPT TO command is received before the message is
> received, therefore the message size is not known.
Also, the client did not specify a message size when it sent the
MAIL FROM comma
Christoph Haas:
> request=smtpd_access_policy
> protocol_state=RCPT
...
> size=0
The RCPT TO command is received before the message is
received, therefore the message size is not known.
> My Postfix log shows though:
>
> postfix/qmgr[43700]: A031B9D69C: from=, size=501,
> nrcpt=1 (queue active)
lugin/#quota-service
Relevant Postfix config:
smtpd_recipient_restrictions = \
reject_unauth_destination \
check_policy_service inet:localhost:12340
I usually test any mail server using swaks
(http://jetmore.org/john/code/swaks/). So I ran:
swaks --to t...@bullseye.example.org
The test us
>>Matus UHLAR - fantomas:
>>>I was curious if I could do a script that would do the same, with the same
>>>possible issues.
>>>
>>>I can do perl, but it looks neither python nor perl have interface to postfix
>>>what could e.g. expand maps without calling external commands.
On 01.07.21 22:49, Kev
Matus UHLAR - fantomas:
> >>Matus UHLAR - fantomas:
> >>>I was curious if I could do a script that would do the same, with the same
> >>>possible issues.
> >>>
> >>>I can do perl, but it looks neither python nor perl have interface to
> >>>postfix
> >>>what could e.g. expand maps without calling e
Matus UHLAR - fantomas:
I was curious if I could do a script that would do the same, with the same
possible issues.
I can do perl, but it looks neither python nor perl have interface to postfix
what could e.g. expand maps without calling external commands.
On 01.07.21 22:49, Kevin N. wrote:
Am
Matus UHLAR - fantomas:
I was curious if I could do a script that would do the same, with the same
possible issues.
I can do perl, but it looks neither python nor perl have interface to postfix
what could e.g. expand maps without calling external commands.
Among other things, it mainly acted a
Matus UHLAR - fantomas:
> I was curious if I could do a script that would do the same, with the same
> possible issues.
>
> I can do perl, but it looks neither python nor perl have interface to postfix
> what could e.g. expand maps without calling external commands.
One solution is when the table
wn service, whenever check_policy_service needs
it.
From what I can see postconf and postmap are called using Python's
subprocess.Popen, like so:
subprocess.Popen(args, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT, encoding='utf-8', shell=False)
where:
Hi Viktor,
Thank you for the suggestion.
Are there any other general areas that I should be looking out for in
this kind of situations?
Cheers,
K.
It appears that some care has been taken to do it right. In principle
something like this should be sufficient. You'll need to review the
code
On Thu, Jul 01, 2021 at 02:18:06PM +0300, Kevin N. wrote:
> From what I can see postconf and postmap are called using Python's
> subprocess.Popen, like so:
>
> subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
>encoding='utf-8', shell=False)
>
> whe
Postfix's spawn service, whenever check_policy_service needs it.
From what I can see postconf and postmap are called using Python's
subprocess.Popen, like so:
subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
encoding='utf-8', shell=False)
where:
Kevin N.:
> Hello everybody,
>
> On one of our internal Postfix system I noticed that one of the
> check_policy_service script is using postconf and postmap to perform
> some alias lookups. It uses postconf to get the virtual_alias_maps
> parameter, which is then used by post
Hello everybody,
On one of our internal Postfix system I noticed that one of the
check_policy_service script is using postconf and postmap to perform
some alias lookups. It uses postconf to get the virtual_alias_maps
parameter, which is then used by postmap to perform the lookups.
Now, the
On Wed, 2018-09-26 at 13:46 -0400, Wietse Venema wrote:
> Christian Ejlertsen:
> > Postfix version 2.10.1
> >
> > I'm adding a check_policy_service for some quota checking, with the
> > following arguments
> >
> > check_policy_service inet:imap01.e
Christian Ejlertsen:
> Postfix version 2.10.1
>
> I'm adding a check_policy_service for some quota checking, with the
> following arguments
>
> check_policy_service inet:imap01.example.com:12340
>
> If i configure the line like this in main.cf it fails with the
>
Postfix version 2.10.1
I'm adding a check_policy_service for some quota checking, with the
following arguments
check_policy_service inet:imap01.example.com:12340
If i configure the line like this in main.cf it fails with the
following message
fatal: host/service imap01.litmail.dk/1234
Hello postfix community,
for an unknown reason i've been unable to pin down, my postfix suddenly seems
to have stopped processing inbound emails with my policyd-spf-perl
check_policy_service.
it's been working fine and then poof, gone. no headers written from it and no
maill
On Mon, Nov 09, 2015 at 03:09:39PM +1100, Robert Mueller wrote:
> > Alternatively, I guess you could add something like a
> > smtpd_end_of_session_restrictions that runs after the cleanup commit is
> > complete?
At that point is already either queued or rejected by cleanup. So
such a "callback"
> I see that there are smtp_header_checks that must run during the smtp
> sending phase, would it be worth adding smtpd_header_checks (with some
> restrictions likes the smtp_* ones) that run in smtpd during the message
> reading phase?
Having a look at the code, this appears annoying. It appears
Robert Mueller:
> Am I missing something? Is there no way to tell in the
> smtpd_end_of_data_restrictions check_policy_service request if the
smtpd_xxx_restrictions is a first line of defense. It executes when
Postfix receives "xxx" (where xxx is helo, sender, recipient, ...,
end
essage
reading phase?
Alternatively, would it be possible to add a "run_cleanup" action that
could be put in smtpd_end_of_data_restrictions to explicitly run cleanup
and wait for the response? So you could have:
smtpd_end_of_data_restrictions =
run_cleanup
check_policy_service ...blah...
er
and body checks.
> The problem is that even though the REJECT in header_checks works to
> have the email rejected, the check_policy_service still runs in the
> smtpd_end_of_data_restrictions phase, which increases the receipt count
> for that user, even though we didn't actuall
Hi
We have a setup where we use a check_policy_service in
smtpd_end_of_data_restrictions to track the rate users are receiving
emails.
Recently a user came under attack from someone using a distributed set
of compromised websites. Fortunately it was fairly easy to find a header
in the majority
query load over different
proxymap server instances. Having to change all mumble_clnt APIs
can be invasive.
> > Can you update the patch?
>
> The attached patch has updated parameter names.
>
> Now it will look like that:
>
> check_policy_service { inet:localhost:
updated parameter names.
Now it will look like that:
check_policy_service { inet:localhost:12345, timeout=10s,
default_action=DUNNO, policy_context=accounting }
and:
request=smtpd_access_policy
policy_context=reputation
...
I'll implement the policy_context attribute in mtpoli
t;vhost". To avoid collisions
with future protocol extensions I would make the name more specifc,
and use "policy_context" or something like that.
> > In main.cf:
> >
> > smtpd_client_restrictions =
> > check_policy_service { inet:localhost:12345, t
vhost". something like "query" or
"context" or similar would be better.
> In main.cf:
>
> smtpd_client_restrictions =
> check_policy_service { inet:localhost:12345, timeout=10s,
> default_action=DUNNO, vhost=reputation }
> check_policy_serv
ck
similar to the Host: header in HTTP?
The attached patch adds a smtpd_policy_service_vhost option which
is sent to the policy daemon.
In main.cf:
smtpd_client_restrictions =
check_policy_service { inet:localhost:12345, timeout=10s,
default_action=DUNNO, vhost=reputation }
check_poli
Istvan Prosinger:
> On 2015-08-06 13:50, Istvan Prosinger wrote:
> > Got it.
> > I have made a small perl script as a service that would only return
> > reject as a policy (that sould have rendered most of the mailing
> > impossibble), and postfix was still mailing happily. Since I have
> > recompi
On 2015-08-06 13:50, Istvan Prosinger wrote:
Got it.
I have made a small perl script as a service that would only return
reject as a policy (that sould have rendered most of the mailing
impossibble), and postfix was still mailing happily. Since I have
recompiled Postfix from the source, it was ou
Got it.
I have made a small perl script as a service that would only return
reject as a policy (that sould have rendered most of the mailing
impossibble), and postfix was still mailing happily. Since I have
recompiled Postfix from the source, it was out of the question the the
process was faul
les
sender_bcc_maps = hash:/etc/postfix/bcc
sendmail_path = /usr/sbin/sendmail.postfix
smtpd_end_of_data_restrictions = check_policy_service
inet:127.0.0.1:10031
smtpd_recipient_restrictions = check_policy_service
inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sas
On Mon, Aug 03, 2015 at 09:48:35AM -0400, Postfix User wrote:
> On Mon, 03 Aug 2015 14:52:33 +0200, Istvan Prosinger stated:
>
> > Yeah when I took the server for audit, Postfix was dead and couldn't
> > start -the config file was (and stil is) in mess.
> >
> > Nevertheless, accepting SMTP is n
On Mon, 03 Aug 2015 14:52:33 +0200, Istvan Prosinger stated:
> Yeah when I took the server for audit, Postfix was dead and couldn't
> start -the config file was (and stil is) in mess.
>
> Nevertheless, accepting SMTP is not the issue at this moment.
> The issue is that it seems to be disregardin
erday, thinking that it might
be damaged, but no effect...
On 2015-08-02 23:14, Viktor Dukhovni wrote:
On Sun, Aug 02, 2015 at 10:53:35PM +0200, Istvan Prosinger wrote:
smtpd_end_of_data_restrictions = check_policy_service
inet:127.0.0.1:10031
smtpd_recipient_restrictions = check_policy_service
On Sun, Aug 02, 2015 at 10:53:35PM +0200, Istvan Prosinger wrote:
> smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10031
> smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10031,
> permit_mynetworks, permit_sasl_auth
10.1/samples
sender_bcc_maps = hash:/etc/postfix/bcc
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = no
smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10031
smtpd_recipient_restrictions = check_policy_service
inet:127.0.0.1:10031, permit_mynetw
ger/policyd)
> >>
> >>smtpd_recipient_restrictions = check_policy_service
> >>inet:127.0.0.1:10031,
> >> permit_mynetworks,
> >> permit_sasl_authenticated,
> >>
Istvan Prosinger:
On 2015-07-30 17:23, wie...@porcupine.org wrote:
> Istvan Prosinger:
>> Hello everyone,
>>
>> I have this im main.cf (I'ts actually an attempt to implement
>> cluebringer/policyd)
>>
>> smtpd_recipient_restrictions =
Istvan Prosinger:
> On 2015-07-30 17:23, wie...@porcupine.org wrote:
> > Istvan Prosinger:
> >> Hello everyone,
> >>
> >> I have this im main.cf (I'ts actually an attempt to implement
> >> cluebringer/policyd)
> >>
> >> smt
On Fri, 31 Jul 2015 14:28:35 +0200
Istvan Prosinger wrote:
> I don't think so. I've tried to give false parameters here to Postfix
> that sould produce an error in the maillog, but Postfix is all happy,
> carrying on...
what false parameters you tried? share with us your conf.
On 2015-07-30 17:23, wie...@porcupine.org wrote:
Istvan Prosinger:
Hello everyone,
I have this im main.cf (I'ts actually an attempt to implement
cluebringer/policyd)
smtpd_recipient_restrictions = check_policy_service
inet:127.0.0.1:10031,
permit_mynet
Istvan Prosinger:
> Hello everyone,
>
> I have this im main.cf (I'ts actually an attempt to implement
> cluebringer/policyd)
>
> smtpd_recipient_restrictions = check_policy_service
> inet:127.0.0.1:10031,
>
Hello everyone,
I have this im main.cf (I'ts actually an attempt to implement
cluebringer/policyd)
smtpd_recipient_restrictions = check_policy_service
inet:127.0.0.1:10031,
permit_mynetworks,
permit_sasl_authenti
Edgaras Luko?evi?ius:
> What is the solution? Other than running some wrapper on local server and
> feeding it as policy service for postfix?
>
> On 02 Apr 2015, at 16:58, Wietse Venema wrote:
Have multiple IP addresses for the policy service hostname,
or find/build a policy daemon proxy that d
service is
> used:
> > smtpd_recipient_restrictions =
> > ...
> >check_policy_service inet:mailstore.example.com:12340
>
> While in my setup I have users distributed over a cluster and i?m using:
> > transport_maps = proxy:mysql:/etc/postfix/mysql/virtual_transport.cf
>
>
Hi,
i’m trying to do quota limits by this tutorial:
https://sys4.de/en/blog/2013/04/08/postfix-dovecot-mailbox-quota/
I have all the parts working, but in the tutorial only one policy service is
used:
> smtpd_recipient_restrictions =
>...
>check_polic
On 20/01/2015 23:03, Noel Jones wrote:
On 1/20/2015 2:08 PM, Chris Robinson wrote:
On 20/01/2015 19:48, Wietse Venema wrote:
To answer the question:
man 5 postconf
sender_dependent_relayhost_maps (default: empty)
...
This information is overruled with relay_transport,
sender
On 1/20/2015 2:08 PM, Chris Robinson wrote:
>
> On 20/01/2015 19:48, Wietse Venema wrote:
>> To answer the question:
>>
>> man 5 postconf
>> sender_dependent_relayhost_maps (default: empty)
>> ...
>> This information is overruled with relay_transport,
>> sender_dependent_default_tra
On 20/01/2015 19:48, Wietse Venema wrote:
To answer the question:
man 5 postconf
sender_dependent_relayhost_maps (default: empty)
...
This information is overruled with relay_transport,
sender_dependent_default_transport_maps, default_transport and
with the transport(5) tabl
To answer the question:
man 5 postconf
sender_dependent_relayhost_maps (default: empty)
...
This information is overruled with relay_transport,
sender_dependent_default_transport_maps, default_transport and
with the transport(5) table.
So that is no good. But there is a solution:
http://comments.gmane.org/gmane.mail.postfix.user/205963:
I have the policy daemon postfwd running with the following entry:
id=RULE-SIZE-RELAY; protocol_state==END-OF-MESSAGE; size>800;
sasl_username=~/^\S+$/ action=FILTER smtp:[127.0.0.1]25;
main.cf:
smtpd_end_of_data_restrictions = check_policy_serv
thanks Noel, i will make a try
results notes to the list when is finished
must be checked
>
> is really easy fullfill any of them separatelly but no matter what i
> have done, they don't work the way i need with both of them, this 2
> can easily be implemented very easily with postfwd and
> postfix-policyd-spf [perl or python version]
>
> is p
don't work the way i need with both of them, this 2 can
easily be implemented very easily with postfwd and postfix-policyd-spf
[perl or python version]
is possible use two lines with check_policy_service without going in
open-relay condition ?
somebody can help me ?
this is the last c
Hi,
On Tue, May 13, 2014 at 5:29 PM, Jan P. Kessler wrote:
>
>I'm using postfix-2.10.3 on fedora20 with sqlgrey, distributed across
> three separate servers through mysql. I've configured it using:
>
> check_policy_service inet:127.0.0.1:2501
>
> in
> I'm using postfix-2.10.3 on fedora20 with sqlgrey, distributed across
> three separate servers through mysql. I've configured it using:
>
> check_policy_service inet:127.0.0.1:2501 <http://127.0.0.1:2501>
>
> in main.cf <http://main.cf>. However, this d
Alex:
> When I run it manually from the command-line, it reports that it's binded
> successfully to the postfix socket.
Then, you cannot run it under the spawn daemon, which requires
that the program reads and writes (NOT LISTENS) on stdin/stdout.
Wietse
Hi,
On Thu, May 8, 2014 at 3:47 PM, Wietse Venema wrote:
> Alex:
> > Hi,
> >
> > I'm using postfix-2.10.3 on fedora20 with sqlgrey, distributed across
> three
> > separate servers through mysql. I've configured it using:
> >
> > check_p
Alex:
> Hi,
>
> I'm using postfix-2.10.3 on fedora20 with sqlgrey, distributed across three
> separate servers through mysql. I've configured it using:
>
> check_policy_service inet:127.0.0.1:2501
>
> in main.cf. However, this doesn't provide fa
Hi,
I'm using postfix-2.10.3 on fedora20 with sqlgrey, distributed across three
separate servers through mysql. I've configured it using:
check_policy_service inet:127.0.0.1:2501
in main.cf. However, this doesn't provide fault protection in the same way
as the greylist.pl exam
Cassidy Larson:
> Figured it out. Returning a "DUNNO" from the policy service for valid
> under-quota and unknown users causes postfix to proceed to the checking of
> aliases/users. This allows the mailbox over-quota rejection to work
> successfully for valid users, and allows virtual aliases to b
pted
while denying messages to over-quota users. Although aliases that deliver
to an over-quota user are also accepted, but that's another investigative
trip to the manual. Thanks.
On Sat, Jul 13, 2013 at 6:09 PM, Wietse Venema wrote:
> Cassidy Larson:
> > I'm trying to get check
Cassidy Larson:
> I'm trying to get check_policy_service working right by returning an error
> on a full mailbox to avoid back scatter. The check_policy_service works
> fine, except when it comes to virtual alias mappings. When running the
> check_policy_service on the virt
I'm trying to get check_policy_service working right by returning an error
on a full mailbox to avoid back scatter. The check_policy_service works
fine, except when it comes to virtual alias mappings. When running the
check_policy_service on the virtual alias user my
smtpd_recipient_restric
?
smtpd_recipient_restrictions = check_policy_service
unix:private/policy,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject
/Jonas
mtpd_recipient_restrictions = check_policy_service
> unix:private/policy,
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_unauth_destination,
> reject
>
On Mon, 10 Jun 2013, Dudi Goldenberg wrote:
Any ideas?
smtpd_recipient_restrictions = check_policy_service unix:private/policy,
permit_mynetworks,
permit_sasl_authenticated
>Any ideas?
>
>smtpd_recipient_restrictions = check_policy_service unix:private/policy,
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_
Am 2013-06-10 07:13, schrieb j...@soe.se:
I have written a small policy service.
But I whish to not use it for those emails which are rejected. Only
permited emails (permit_mynetworks and permit_sasl_authenticated)
Any ideas?
smtpd_recipient_restrictions = check_policy_service
unix:private
Hello,
I have written a small policy service.
But I whish to not use it for those emails which are rejected. Only permited
emails (permit_mynetworks and permit_sasl_authenticated)
Any ideas?
smtpd_recipient_restrictions = check_policy_service unix:private/policy
Titanus Eramius skrev den 2013-03-21 14:49:
I have set Postfix only to allow relaying through submission on port
587, and as extra safety, I have installed the PolicyD* service to
run
some rate limiting, and is trying to configure it with Postfix.
i still have to see why sending one msg pr da
mail that gets relayed, I
> am trying to call it from the submission block in master.cf like so:
>
> submission inet n - - - - smtpd
> ...
> -o ... ,check_policy_service inet:127.0.0.1:10031,reject
>
> But it does not work. The log gives t
Thu, 21 Mar 2013 12:25:24 -0400 skrev Brian Evans
:
> > submission inet n - - - - smtpd
> >...
> > -o ... ,check_policy_service inet:127.0.0.1:10031,reject
>
> Change this to
> "-o ... ,check_policy_service,inet:127.0.0
1 - 100 of 141 matches
Mail list logo
