Helo all,
What I am trying to do is whitelist cidr ranges stored in a mysql database and
fallback to smtp auth for the previous unmatched ip addresses. This is the
pseudocode:
if (client_ip in whitelist_mysql_cidr_ranges){ accept
} else if (sender is smtp_authenticated ) { accept} else {
Hi,
i want to insiders_only classes per user is it possible
i mean i want to give send access our mail dist. list per user:
thanks in advance.
/etc/postfix/insiders:
my.domain OK *matches my.domain and subdomains*
another.domain OK *matches another.domain and subdomains*
*
On 8/14/2014 1:53 PM, li...@rhsoft.net wrote:
>
>
> Am 08.08.2014 um 18:16 schrieb Noel Jones:
>> On 8/8/2014 11:06 AM, li...@rhsoft.net wrote:
>>> Am 08.08.2014 um 16:19 schrieb Noel Jones:
On 8/8/2014 8:56 AM, li...@rhsoft.net wrote:
> Am 08.08.2014 um 13:18 schrieb Noel Jones:
>>
Am 08.08.2014 um 18:16 schrieb Noel Jones:
> On 8/8/2014 11:06 AM, li...@rhsoft.net wrote:
>> Am 08.08.2014 um 16:19 schrieb Noel Jones:
>>> On 8/8/2014 8:56 AM, li...@rhsoft.net wrote:
Am 08.08.2014 um 13:18 schrieb Noel Jones:
> On 8/8/2014 4:58 AM, li...@rhsoft.net wrote:
>> dream
On 8/8/2014 11:06 AM, li...@rhsoft.net wrote:
> Am 08.08.2014 um 16:19 schrieb Noel Jones:
>> On 8/8/2014 8:56 AM, li...@rhsoft.net wrote:
>>> Am 08.08.2014 um 13:18 schrieb Noel Jones:
On 8/8/2014 4:58 AM, li...@rhsoft.net wrote:
> dreamed about like below but dreams don't always become t
Am 08.08.2014 um 16:19 schrieb Noel Jones:
> On 8/8/2014 8:56 AM, li...@rhsoft.net wrote:
>> Am 08.08.2014 um 13:18 schrieb Noel Jones:
>>> On 8/8/2014 4:58 AM, li...@rhsoft.net wrote:
dreamed about like below but dreams don't always become true :-)
smtpd_milters = unix:/run/clamav-m
On 8/8/2014 8:56 AM, li...@rhsoft.net wrote:
> Am 08.08.2014 um 13:18 schrieb Noel Jones:
>> On 8/8/2014 4:58 AM, li...@rhsoft.net wrote:
>>> dreamed about like below but dreams don't always become true :-)
>>>
>>> smtpd_milters = unix:/run/clamav-milter/clamav-milter.socket
>>> permit_dnswl_clien
Am 08.08.2014 um 13:18 schrieb Noel Jones:
> On 8/8/2014 4:58 AM, li...@rhsoft.net wrote:
>> dreamed about like below but dreams don't always become true :-)
>>
>> smtpd_milters = unix:/run/clamav-milter/clamav-milter.socket
>> permit_dnswl_client list.dnswl.org
>> check_sender_access proxy:hash:
On 8/8/2014 4:58 AM, li...@rhsoft.net wrote:
> dreamed about like below but dreams don't always become true :-)
>
> smtpd_milters = unix:/run/clamav-milter/clamav-milter.socket
> permit_dnswl_client list.dnswl.org
> check_sender_access proxy:hash:/etc/postfix/disable-sender-contentfilter.cf
> c
>>
>> but is there a way to combine it with restriction classes and
>> other rules while running as milter just because before-queue
>> to avoid become a backscatter?
>> ___
>>
>> below an theoretical example how i
On Fri, Jul 25, 2014 at 11:50:22AM -0500, Noel Jones wrote:
> On 7/24/2014 10:58 PM, Will Yardley wrote:
> > On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:
> >>> and then have
> >>> recommended =
> >>
> >> Yes, that should work as expected.
> >
> > This seemed to work as expected in
On 7/24/2014 10:58 PM, Will Yardley wrote:
> On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:
>>> and then have
>>> recommended =
>>
>> Yes, that should work as expected.
>
> This seemed to work as expected in my tests on 2.6.x. However, on 2.3.3,
> I get:
>
> postfix/smtpd[5673]: fat
On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:
> > and then have
> > recommended =
>
> Yes, that should work as expected.
This seemed to work as expected in my tests on 2.6.x. However, on 2.3.3,
I get:
postfix/smtpd[5673]: fatal: restriction class `recommended' needs a definition
Thanks so much for the helpful response - just wanted to make sure I was
heading in the right direction, and this was exactly what I needed.
On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:
> > My thought was that maybe I should do something like this instead:
> >
> > reject_non
On 7/22/2014 7:34 PM, Will Yardley wrote:
> I'm wondering if someone can help me make sure I get the order right for
> some recipient classes. I had hoped to just phase these out in favor of
> a more unified system
>
> The *intent* was to have the recommended class behave the same as a user
> with
I'm wondering if someone can help me make sure I get the order right for
some recipient classes. I had hoped to just phase these out in favor of
a more unified system
The *intent* was to have the recommended class behave the same as a user
without the attribute set to 'recommended'.
Right now, th
El 17/10/13 11:21, Dominik George escribió:
> Dominik George schrieb:
> >>> Viktor Dukhovni schrieb:
> On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
> LDAP is not SQL, and inverse relations (groups of user, rather
> > than
> users of group) are very difficult to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dominik George schrieb:
>>> Viktor Dukhovni schrieb:
>>> > On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
>>> > LDAP is not SQL, and inverse relations (groups of user, rather
>than
>>> > users of group) are very difficult to expre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
>> Viktor Dukhovni schrieb:
>> > On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
>> > LDAP is not SQL, and inverse relations (groups of user, rather than
>> > users of group) are very difficult to express.
On second thought, Viktor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Carlos R Laguna schrieb:
>Dominik George you mind to explain yourseld a little more further.
If your LDAP users are regular system users, i.e., have the posixAccount class,
and your mail servers uses them for local authentication, then obviously,
El 17/10/13 10:25, Dominik George escribió:
> Viktor Dukhovni schrieb:
> > On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
> > LDAP is not SQL, and inverse relations (groups of user, rather than
> > users of group) are very difficult to express.
>
> Whereas, if the LDAP users are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Viktor Dukhovni schrieb:
>On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
>LDAP is not SQL, and inverse relations (groups of user, rather than
>users of group) are very difficult to express.
Whereas, if the LDAP users are system us
On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
> Hello everyone, for a while now i have ben using ldap groups to create
> restriccion classes for manage the access of my users like this
>
> correose_search_base = ou=Groups,dc=jovenclub,dc=cu
> correose_query_filter = (&(|(cn=Cor
Hello everyone, for a while now i have ben using ldap groups to create
restriccion classes for manage the access of my users like this
correose_search_base = ou=Groups,dc=jovenclub,dc=cu
correose_query_filter = (&(|(cn=CorreoSE))(memberUid=%u))
correose_result_attribute = cn
So i get the cn of th
On 4/24/2012 10:20 AM, Chad M Stewart wrote:
>
> Is it possible to put the use of a smtpd_milter into a restriction class?
No, the milter connection happens before postfix knows anything
about the client.
-- Noel Jones
Is it possible to put the use of a smtpd_milter into a restriction class? From
what I've read so far I'm suspect the answer is no. In which case I'll have to
put the functionality into the milter itself, MIMEDefang in my case. I'd
prefer to keep the restriction classes
Original-Nachricht
> Datum: Tue, 4 Aug 2009 23:57:41 -0500
> Von: "/dev/rob0"
> An: postfix-users@postfix.org
> Betreff: Re: Question regarding Restriction Classes
> On Tuesday 04 August 2009 13:51:31 Steve wrote:
> > > But I don't think
d_*_restrictions.
smtpd_*_restrictions themselves are each "estriction stages".
"Subclass" is not a Postfix term. I was using it to mean "subdivide
your restriction classes into smaller classes." And I think you got
that part.
> But I understand now better. Your text
Original-Nachricht
> Datum: Tue, 4 Aug 2009 13:01:12 -0500
> Von: "/dev/rob0"
> An: postfix-users@postfix.org
> Betreff: Re: Question regarding Restriction Classes
> On Tuesday 04 August 2009 07:48:12 Steve wrote:
> > I have a problem with r
On Tuesday 04 August 2009 07:48:12 Steve wrote:
> I have a problem with restriction classes that I can't solve. I have a
> bunch of restriction classes. In order to simplify this mail I am only
> using two. One for SPF checking and the other for Greylisting. Now I would
> like to
Hi,
I have a problem with restriction classes that I can't solve. I have a bunch of
restriction classes. In order to simplify this mail I am only using two. One
for SPF checking and the other for Greylisting. Now I would like to have for
each of the restriction classes a bunch of conditio
.com is
> >>> 1.2.3.4 (or perhaps 1.2.3.0/24). I want to prevent any other host from
> >>> sending a message having an envelope sender other than 1.2.3.0/24.
> >>> However, I NEED for 1.2.3.4 to be able to send messages from all other
> >>> envelope s
particular internal host in question is a IBM Mainframe and I'm
afraid I'm not terribly knowledgeable on its SMTP server at the moment.
No need for restriction classes if the requirement is:
{allow any sender from the specified client}
{reject your domains as sender from
Kevin P. Knox:
> My Postfix server is running 2.2.10, so I don't "think" I can use CIDRs, but
> can possibly list the internal servers as 32 bit addresses?
CDIR table lookups were introduced with Postfix 2.1.
Wietse
.com is
> >>> 1.2.3.4 (or perhaps 1.2.3.0/24). I want to prevent any other host from
> >>> sending a message having an envelope sender other than 1.2.3.0/24.
> >>> However, I NEED for 1.2.3.4 to be able to send messages from all other
> >>> envelope s
wever, I NEED
> > for 1.2.3.4 to be able to send messages from all other envelope senders.
> > This particular internal host in question is a IBM Mainframe and I'm
> > afraid I'm not terribly knowledgeable on its SMTP server at the moment.
>
> No need for restriction
m afraid I'm not terribly knowledgeable on its SMTP
server at the moment.
No need for restriction classes if the requirement is:
{allow any sender from the specified client}
{reject your domains as sender from any other client}.
# main.cf
smtpd_sender_restrictions =
check_client_acce
terribly knowledgeable on its SMTP
server at the moment.
I was able to get this working by using restriction classes, but it had the
unfortunate side effect of blocking mail forwarded from our internal SMTP
servers (particularly the mainframe) which preserve the envelope sender of
outside SMTP
mouss a écrit :
Sam Przyswa wrote:
Hi all,
I succeed to limit some local users to send mail only on my local
domain, but I would like to limit the mail received ONLY from the
local users too for these users, no mails from internet (others
domains).
There is my actual Postfix config:
/e
Sam Przyswa wrote:
Hi all,
I succeed to limit some local users to send mail only on my local
domain, but I would like to limit the mail received ONLY from the local
users too for these users, no mails from internet (others domains).
There is my actual Postfix config:
/etc/postfix/main.cf:
Hi all,
I succeed to limit some local users to send mail only on my local
domain, but I would like to limit the mail received ONLY from the local
users too for these users, no mails from internet (others domains).
There is my actual Postfix config:
/etc/postfix/main.cf:
...
smtpd_recipient_
Ralf Hildebrandt wrote:
If a smtpd_restriction_class return NEITHER OK NOR REJECT, what
happens? Postfix continues in the "calling" set of restrictions?
as in check_mumble_access and the like, the default is to continue.
restriction classes are simply a "holder" (you
* Ralf Hildebrandt <[EMAIL PROTECTED]>:
> If a smtpd_restriction_class return NEITHER OK NOR REJECT, what
> happens? Postfix continues in the "calling" set of restrictions?
Somebody built a testcase on the German lists, and yes, Postfix
continues in the "calling" set of restrictions
--
Ralf Hild
If a smtpd_restriction_class return NEITHER OK NOR REJECT, what
happens? Postfix continues in the "calling" set of restrictions?
--
Ralf Hildebrandt ([EMAIL PROTECTED]) [EMAIL PROTECTED]
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
mouss wrote:
> Brian Evans - Postfix List wrote:
>> [snip]
>>
>> ndr_only = check_recipient_access hash:/etc/postfix/ndr_senders,reject
>>
>
> if you want to check the recipient, rename your map.
> if you want to check the sender, rename your check.
>
>> $ cat /etc/postfix/ndr_senders
>> <> OK
Brian Evans - Postfix List wrote:
[snip]
ndr_only = check_recipient_access hash:/etc/postfix/ndr_senders,reject
if you want to check the recipient, rename your map.
if you want to check the sender, rename your check.
$ cat /etc/postfix/ndr_senders
<> OK
This will never match a recipi
Brian Evans - Postfix List wrote:
Noel Jones wrote:
Brian Evans - Postfix List wrote:
I want a single account to only accept NDRs. Other email should be
rejected.
Would the following work correctly?
smtpd_recipient_restrictions:
...
check_recipient_access hash:/etc/postfix/receieve_only
...
Noel Jones wrote:
> Brian Evans - Postfix List wrote:
>> I want a single account to only accept NDRs. Other email should be
>> rejected.
>>
>> Would the following work correctly?
>>
>> smtpd_recipient_restrictions:
>> ...
>> check_recipient_access hash:/etc/postfix/receieve_only
>> ...
>>
>> /etc/p
Brian Evans - Postfix List wrote:
I want a single account to only accept NDRs. Other email should be
rejected.
Would the following work correctly?
smtpd_recipient_restrictions:
...
check_recipient_access hash:/etc/postfix/receieve_only
...
/etc/postfix/receieve_only:
[EMAIL PROTECTED] check
I want a single account to only accept NDRs. Other email should be rejected.
Would the following work correctly?
smtpd_recipient_restrictions:
...
check_recipient_access hash:/etc/postfix/receieve_only
...
/etc/postfix/receieve_only:
[EMAIL PROTECTED] check_sender_access hash:/etc/postfix/ndr
50 matches
Mail list logo
