Re: whitelist from spamhaus

[Pascal Volk]

On 18.03.2009 08:55 K bharathan wrote:
> Hi
> can i whitelist one domain from checking spamhaus ?
> thanks

smtpd_recipient_restrictions =
  ...
  reject_unauth_destination
  ...
  check_client_access hash:/etc/postfix/whitelist_clients
  check_sender_access hash:/etc/postfix/whitelist_senders
  reject_rbl_client zen.spamhaus.org
  ...

/etc/postfix/whitelist_clients:
mailout.trusteddoma.in  OK
# or ip address of trusted hosts

/etc/postfix/whitelist_senders:
u...@trusteddoma.in OK


Regards,
Pascal
-- 
The trapper recommends today: defaced.0907...@localdomain.org

Re: whitelist from spamhaus

[/dev/rob0]

On Wed March 18 2009 03:06:40 Pascal Volk wrote:
> > can i whitelist one domain from checking spamhaus ?
> > thanks
>
> smtpd_recipient_restrictions =
>   ...
>   reject_unauth_destination
>   ...
>   check_client_access hash:/etc/postfix/whitelist_clients
>   check_sender_access hash:/etc/postfix/whitelist_senders
>   reject_rbl_client zen.spamhaus.org
>   ...
>
> /etc/postfix/whitelist_clients:
> mailout.trusteddoma.in  OK
> # or ip address of trusted hosts
>
> /etc/postfix/whitelist_senders:
> u...@trusteddoma.in OK

Some comments I would add:

1. I consider it best practice to use "permit_auth_destination" rather
   than "OK" for whitelisting. That's an extra safety check in case you
   accidentally put smtpd_recipient_restrictions in the wrong order.
2. check_sender_access is never really safe for whitelisting. Consider
   the common scenario of a virus on a Windows machine, sending mail
   purporting to be "from" the person who set up Outlook Express (or
   whatever they call it now) on that machine. If that spam goes
   direct-to-MX, it would likely be blocked by Zen.
3. If mailout.trusteddoma.in is listed in Zen, they have issues that
   really do need to be addressed. Are you sure you want them
   whitelisted? Whitelisting is a slippery slope, seldom the right
   answer to the real problem.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: whitelist from spamhaus

[Wietse Venema]

/dev/rob0:
> On Wed March 18 2009 03:06:40 Pascal Volk wrote:
> > > can i whitelist one domain from checking spamhaus ?
> > > thanks
> >
> > smtpd_recipient_restrictions =
> >   ...
> >   reject_unauth_destination
> >   ...
> >   check_client_access hash:/etc/postfix/whitelist_clients
> >   check_sender_access hash:/etc/postfix/whitelist_senders
> >   reject_rbl_client zen.spamhaus.org
> >   ...
> >
> > /etc/postfix/whitelist_clients:
> > mailout.trusteddoma.in  OK
> > # or ip address of trusted hosts
> >
> > /etc/postfix/whitelist_senders:
> > u...@trusteddoma.in OK
> 
> Some comments I would add:
> 
> 1. I consider it best practice to use "permit_auth_destination" rather
>than "OK" for whitelisting. That's an extra safety check in case you
>accidentally put smtpd_recipient_restrictions in the wrong order.

That is a good point. I wonder how much would break with

/etc/postfix/main.cf
restriction_classes = ok [... other names ...]
ok = permit_auth_destination

This would change the meaning of OK such that it works like
permit_auth_destination in access(5) maps. It's a gross hack, but
then, restriction_classes was also a gross hack.

Wietse

> 2. check_sender_access is never really safe for whitelisting. Consider
>the common scenario of a virus on a Windows machine, sending mail
>purporting to be "from" the person who set up Outlook Express (or
>whatever they call it now) on that machine. If that spam goes
>direct-to-MX, it would likely be blocked by Zen.
> 3. If mailout.trusteddoma.in is listed in Zen, they have issues that
>really do need to be addressed. Are you sure you want them
>whitelisted? Whitelisting is a slippery slope, seldom the right
>answer to the real problem.
> -- 
> Offlist mail to this address is discarded unless
> "/dev/rob0" or "not-spam" is in Subject: header
> 
> 

Re: whitelist from spamhaus

[Victor Duchovni]

On Wed, Mar 18, 2009 at 12:56:48PM -0400, Wietse Venema wrote:

> /dev/rob0:
> > On Wed March 18 2009 03:06:40 Pascal Volk wrote:
> > > > can i whitelist one domain from checking spamhaus ?
> > > > thanks
> > >
> > > smtpd_recipient_restrictions =
> > >   ...
> > >   reject_unauth_destination
> > >   ...
> > >   check_client_access hash:/etc/postfix/whitelist_clients
> > >   check_sender_access hash:/etc/postfix/whitelist_senders
> > >   reject_rbl_client zen.spamhaus.org
> > >   ...
> > >
> > > /etc/postfix/whitelist_clients:
> > > mailout.trusteddoma.in  OK
> > > # or ip address of trusted hosts
> > >
> > > /etc/postfix/whitelist_senders:
> > > u...@trusteddoma.in OK
> > 
> > Some comments I would add:
> > 
> > 1. I consider it best practice to use "permit_auth_destination" rather
> >than "OK" for whitelisting. That's an extra safety check in case you
> >accidentally put smtpd_recipient_restrictions in the wrong order.
> 
> That is a good point. I wonder how much would break with
> 
> /etc/postfix/main.cf
> restriction_classes = ok [... other names ...]
> ok = permit_auth_destination

Well, "check_client_access" and "check_recipient_access" may not work
correctly at sites where these are used to permit access for additional
clients or to additional recipients. Should be safe in most cases.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: whitelist from spamhaus

[Wietse Venema]

Victor Duchovni:
> On Wed, Mar 18, 2009 at 12:56:48PM -0400, Wietse Venema wrote:
> > /dev/rob0:
> > > Some comments I would add:
> > > 
> > > 1. I consider it best practice to use "permit_auth_destination" rather
> > >than "OK" for whitelisting. That's an extra safety check in case you
> > >accidentally put smtpd_recipient_restrictions in the wrong order.
> > 
> > That is a good point. I wonder how much would break with
> > 
> > /etc/postfix/main.cf
> > restriction_classes = ok [... other names ...]
> > ok = permit_auth_destination
> 
> Well, "check_client_access" and "check_recipient_access" may not work
> correctly at sites where these are used to permit access for additional
> clients or to additional recipients. Should be safe in most cases.

I just checked the source, and it's currently not possible to
override built-in names with restriction_classes.

Both access(5) maps and smtpd_mumble_restrictions will try the
built-in names first.

It does simplify support, though.

Wietse

Re: whitelist from spamhaus

[K bharathan]

my relay server has got multiple relay domains and i want only exempt mails
to one particular domain from checking spamhaus; given below
smtpd_recipient_restrictions =
reject_non_fqdn_recipient
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/roleaccount_exceptions
reject_non_fqdn_hostname
reject_invalid_hostname
check_client_access cidr:/etc/postfix/spam_cidr
check_helo_access pcre:/etc/postfix/helo_checks
reject_rbl_client  zen.spamhaus.org
reject_rhsbl_sender dsn.rfc-ignorant.org
permit
where in this order i can put permit_auth_destination; if i put this all the
listed domains will get  whitelisted? which i dont want
i'm learning postfix...



On Wed, Mar 18, 2009 at 7:32 PM, Victor Duchovni <
victor.ducho...@morganstanley.com> wrote:

> On Wed, Mar 18, 2009 at 12:56:48PM -0400, Wietse Venema wrote:
>
> > /dev/rob0:
> > > On Wed March 18 2009 03:06:40 Pascal Volk wrote:
> > > > > can i whitelist one domain from checking spamhaus ?
> > > > > thanks
> > > >
> > > > smtpd_recipient_restrictions =
> > > >   ...
> > > >   reject_unauth_destination
> > > >   ...
> > > >   check_client_access hash:/etc/postfix/whitelist_clients
> > > >   check_sender_access hash:/etc/postfix/whitelist_senders
> > > >   reject_rbl_client zen.spamhaus.org
> > > >   ...
> > > >
> > > > /etc/postfix/whitelist_clients:
> > > > mailout.trusteddoma.in  OK
> > > > # or ip address of trusted hosts
> > > >
> > > > /etc/postfix/whitelist_senders:
> > > > u...@trusteddoma.in OK
> > >
> > > Some comments I would add:
> > >
> > > 1. I consider it best practice to use "permit_auth_destination" rather
> > >than "OK" for whitelisting. That's an extra safety check in case you
> > >accidentally put smtpd_recipient_restrictions in the wrong order.
> >
> > That is a good point. I wonder how much would break with
> >
> > /etc/postfix/main.cf
> > restriction_classes = ok [... other names ...]
> > ok = permit_auth_destination
>
> Well, "check_client_access" and "check_recipient_access" may not work
> correctly at sites where these are used to permit access for additional
> clients or to additional recipients. Should be safe in most cases.
>
> --
>Viktor.
>
> Disclaimer: off-list followups get on-list replies or get ignored.
> Please do not ignore the "Reply-To" header.
>
> To unsubscribe from the postfix-users list, visit
> http://www.postfix.org/lists.html or click the link below:
> 
>
> If my response solves your problem, the best way to thank me is to not
> send an "it worked, thanks" follow-up. If you must respond, please put
> "It worked, thanks" in the "Subject" so I can delete these quickly.
>

Re: whitelist from spamhaus

[Noel Jones]

K bharathan wrote:
my relay server has got multiple relay domains and i want only exempt 
mails to one particular domain from checking spamhaus; given below 
smtpd_recipient_restrictions =

reject_non_fqdn_recipient
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/roleaccount_exceptions
reject_non_fqdn_hostname
reject_invalid_hostname
check_client_access cidr:/etc/postfix/spam_cidr
check_helo_access pcre:/etc/postfix/helo_checks


insert here:
  check_recipient_access 
hash:/etc/postfix/whitelist_recipients




reject_rbl_client  zen.spamhaus.org 
reject_rhsbl_sender dsn.rfc-ignorant.org 


permit
where in this order i can put permit_auth_destination; if i put this all 
the listed domains will get  whitelisted? which i dont want

i'm learning postfix...



Please don't top post.  Please use plain-text only, no html.

# Contents of whitelist_recipients:
example.com  permit_auth_destination


  -- Noel Jones

Re: whitelist from spamhaus

[mouss]

Wietse Venema a écrit :
> /dev/rob0:
>> On Wed March 18 2009 03:06:40 Pascal Volk wrote:
 can i whitelist one domain from checking spamhaus ?
 thanks
>>> smtpd_recipient_restrictions =
>>>   ...
>>>   reject_unauth_destination
>>>   ...
>>>   check_client_access hash:/etc/postfix/whitelist_clients
>>>   check_sender_access hash:/etc/postfix/whitelist_senders
>>>   reject_rbl_client zen.spamhaus.org
>>>   ...
>>>
>>> /etc/postfix/whitelist_clients:
>>> mailout.trusteddoma.in  OK
>>> # or ip address of trusted hosts
>>>
>>> /etc/postfix/whitelist_senders:
>>> u...@trusteddoma.in OK
>> Some comments I would add:
>>
>> 1. I consider it best practice to use "permit_auth_destination" rather
>>than "OK" for whitelisting. That's an extra safety check in case you
>>accidentally put smtpd_recipient_restrictions in the wrong order.
> 
> That is a good point. I wonder how much would break with
> 
> /etc/postfix/main.cf
> restriction_classes = ok [... other names ...]
> ok = permit_auth_destination
> 
> This would change the meaning of OK such that it works like
> permit_auth_destination in access(5) maps. It's a gross hack, but
> then, restriction_classes was also a gross hack.
> 

I would suggest separating relay control from other checks. something like

smtpd_relay_restrictions =
permit_mynetworks
permit_sasl_authenticated

Re: whitelist from spamhaus

[Victor Duchovni]

On Thu, Mar 19, 2009 at 11:58:52PM +0100, mouss wrote:

> I would suggest separating relay control from other checks. something like
> 
> smtpd_relay_restrictions =
>   permit_mynetworks
>   permit_sasl_authenticated

This has been proposed before.

http://archives.neohapsis.com/archives/postfix/2006-05/0598.html

Perhaps some day, it would be a major change, and the question is whether
it is worth the effort if it is only an interim design. When you change
something this big, the new feature should be stable for a long time.

Changing the interface with every release becomes unpopular with users.
So the current design for all its flaws is stable, and has proved
reasonably flexible. A new design would need a lot of scrutiny to make
sure we have a solid solution good for another decade of releases.

One could, take this to the extreme and introduce a new (not replacement,
but alternative) SMTP server called "pysmtpd" that bolts a Python
interpreter into Postfix, and provides all the restriction building blocks
(various lookups, ...) as functions in the Python interpreter. Then, in
"pysmtpd" you'd tweak Python code to make access decisions. There'd be
of stock rules and a gentle configuration syntax for non-programmers,
but the underlying rule engine would be a full programming language
extensible by module writers and advanced users.

Lots of other possibilities. Which approach is right?

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: whitelist from spamhaus

[Wietse Venema]

Victor Duchovni:
> On Thu, Mar 19, 2009 at 11:58:52PM +0100, mouss wrote:
> 
> > I would suggest separating relay control from other checks. something like
> > 
> > smtpd_relay_restrictions =
> > permit_mynetworks
> > permit_sasl_authenticated
> 
> This has been proposed before.
> 
> http://archives.neohapsis.com/archives/postfix/2006-05/0598.html
> 
> Perhaps some day, it would be a major change, and the question is whether
> it is worth the effort if it is only an interim design. When you change
> something this big, the new feature should be stable for a long time.
> 
> Changing the interface with every release becomes unpopular with users.
> So the current design for all its flaws is stable, and has proved
> reasonably flexible. A new design would need a lot of scrutiny to make
> sure we have a solid solution good for another decade of releases.
> 
> One could, take this to the extreme and introduce a new (not replacement,
> but alternative) SMTP server called "pysmtpd" that bolts a Python
> interpreter into Postfix, and provides all the restriction building blocks
> (various lookups, ...) as functions in the Python interpreter. Then, in
> "pysmtpd" you'd tweak Python code to make access decisions. There'd be
> of stock rules and a gentle configuration syntax for non-programmers,
> but the underlying rule engine would be a full programming language
> extensible by module writers and advanced users.
> 
> Lots of other possibilities. Which approach is right?

One of the goals of Postfix was to provide a system that is more
secure than other MTAs. For this reason I would not build something
as complex as perl/php/python/etc.  into a process that is directly
exposed to the network. If I wanted to do that, I would have built
Postfix like other MTAs. 

Instead, an architecture based on delegation can provide the
necessary isolation and functionality: one process to weed out
connections from botnets and spammers at minimal resource cost,
while delegating complex policies and SMTP handling to less exposed
and more expensive helpers. While process creation remains relatively
expensive and needs to be minimized, IPC is cheap enough.

Wietse