Re: Using Roundcube to send mail on localhost

[Stan Hoeppner]

On 10/25/2011 4:57 PM, Seth Kneller wrote:

> I apologise, the reason I have posted here is that I cannot see anything
> that is wrong with my roundcube configuration. However I suspect that
> maybe it can't cope with STARTTLS?

STARTTLS is meant for "over-the-wire" security.  It's unnecessary when
doing a memory-to-memory copy from one process to another within the
same physical box.  Do you don a fire suit just to take a pizza out of
the oven?  No.

Simply use the RC default method and it works:

// use this host for sending mails.
// to use SSL connection, set ssl://smtp.host.com
// if left blank, the PHP mail() function is used
// Use %h variable as replacement for user's IMAP hostname
$rcmail_config['smtp_server'] = '';

// SMTP port (default is 25; 465 for SSL)
$rcmail_config['smtp_port'] = 25;

I've been using this setting for years.  It works unless you're
requiring STARTTLS on TCP 25.  If that's the case you probably have
bigger problems...

-- 
Stan

Re: Using Roundcube to send mail on localhost

[Stan Hoeppner]

On 10/25/2011 5:19 PM, Noel Jones wrote:

> Probably the best solution is to uncomment the smtps wrappermode SSL
> master.cf entry, then configure roundcube to submit mail on ssl port
> 465.

Maybe I'm missing something Noel.  Why have RC use auth for relay
submission when both RC and Postfix reside on the same host?

It seems to me the proper solution is to run the submission (or 587)
service for remote relay submission clients and have RC submit on TCP 25
in plain text.

This is how I've always done it.  Works like champ.

-- 
Stan

Re: relay_recipient_maps and LDAP as backend

[Nerijus Kislauskas]

On 10/25/2011 03:09 PM, Nerijus Kislauskas wrote:
> So why it is important to return something from LDAP in order to be
> *sure* entry exists? Search without result_attribute responds with 1
> match. Why it can't be a key for descision, that there is a entry and
> let message to pass through? Thanks for clearing things out.

Any comments?

-- 
Pagarbiai,
Nerijus Kislauskas
KTU ITPI, Litnet valdymo centras
Studentu g. 48a - 101, Kaunas
tel.: (8~37) 30 06 45
mob. tel.: 8-614-93889
e-mail.: nerijus.kislaus...@ktu.lt

greylisting + postfix 101

[Razvan Chitu]

Hello all,
Please take a moment and point me in the right direction: I would 
like to set up a greylisting solution (such as postgrey or greylist.pl) 
only for one recipient (local delivery to *nix account). A link or any 
pointer in the right direction would be welcomed.


Cheers,

--
Razvan Chitu
Network Engineer

SC Top Edge Engineering SRL
Addr: Str. Calea Bucuresti, Bl. M18b, Craiova, 200529, Romania
Tel: 0251-413193 (int. 19)
Fax: 0251-413977
Mobile: 0722-636488

Re: relay_recipient_maps and LDAP as backend

[Nikolaos Milas]

On 26/10/2011 10:29 πμ, Nerijus Kislauskas wrote:


On 10/25/2011 03:09 PM, Nerijus Kislauskas wrote:

So why it is important to return something from LDAP in order to be
*sure* entry exists? Search without result_attribute responds with 1
match. Why it can't be a key for descision, that there is a entry and
let message to pass through? Thanks for clearing things out.


If you don't want to check users, use:

   relay_recipient_maps =

(i.e. without any value)

You may want to read this message: 
http://tech.groups.yahoo.com/group/postfix-users/message/279682 and the 
rest of that thread.


Nick



smime.p7s
Description: S/MIME Cryptographic Signature

Re: greylisting + postfix 101

[lst_hoe02]

Zitat von Razvan Chitu :


Hello all,
Please take a moment and point me in the right direction: I  
would like to set up a greylisting solution (such as postgrey or  
greylist.pl) only for one recipient (local delivery to *nix  
account). A link or any pointer in the right direction would be  
welcomed.


http://www.postfix.org/RESTRICTION_CLASS_README.html
http://www.postfix.org/SMTPD_POLICY_README.html

Regards

Andreas

Virtual Domain Restrictions

[Pa - Soscpd]

Hello List


My first time here so, please, point me any mistakes.

I need some special setup for my postfix server (running postfix-2.6.5 + mysql 
on x86_64 kernel 2.6.31) with 11 virtual domains.



I have several users that does not need to send email offsite, so I've managed 
to create accounts in another domain (and created a new virtual on postfix). 
That far, all is set and working. The problem is that users are using the new 
accounts to send mail off-site. I'm trying to figure how to block that 
communication, so far testing smtpd_recipient_restrictions using a hash, with 
not even a bit of success.


Last attempt, directly from postfix docs:

smtpd_recipient_restrictions =
check_sender_access hash:/etc/postfix/restricted_senders


smtpd_restriction_classes = local_only
local_only = check_recipient_access hash:/etc/postfix/local_domains, reject

/etc/postfix/restricted_senders:
internal.domain.1local_only
internal.domain.nlocal_only

/etc/postfix/local_domains:
allowed.domain.1 OK
allowed.domain.n OK


My setup need to allow all users from domains listed in restricted_senders to 
send and receive mail from other list of domains (local_domains).


If someone can point me any directions...


Thanks in advance








Regards
Rafael

Re: relay_recipient_maps and LDAP as backend

[Nerijus Kislauskas]

On 10/26/2011 11:02 AM, Nikolaos Milas wrote:
> On 26/10/2011 10:29 πμ, Nerijus Kislauskas wrote:
> If you don't want to check users, use:
> 
>relay_recipient_maps =
> 
> (i.e. without any value)
> 
> You may want to read this message:
> http://tech.groups.yahoo.com/group/postfix-users/message/279682 and the
> rest of that thread.

Hi Nick,

you miss a point. It's not about the usage of one or another postfix
config parameter. It is about postfix behavior based on LDAP protocol
search operation/results. I use relay_recipient_maps and I need it. The
real question is:

How postfix should decide, that user realy exists when used
relay_recipient_maps config parameter and LDAP backend.

As I can see now, postfix decides, that user exists when some attribute
(or set of attributes) is returned from a search operation. And in my
opinion that is wrong behavior. LDAP search operation returns DN (or set
of DN's) everytime the search query matches any object(s) and
attributes, if requested. if not, only DN's returned. That is all you
need to say, that there is one (more than one) object in DIT, message
will be delivered to. So you should not need to return attributes at all.

I would like to recieve Wietse's comment on that.
-- 
Pagarbiai,
Nerijus Kislauskas
KTU ITPI, Litnet valdymo centras
Studentu g. 48a - 101, Kaunas
tel.: (8~37) 30 06 45
mob. tel.: 8-614-93889
e-mail.: nerijus.kislaus...@ktu.lt

Re: Spammers attempting SASL auth.

[Duane Hill]

On Mon, 17 Oct 2011, Simon Brereton wrote:


Hi

This is a new one on me - I've never seen spammers attempt to use to SASL Auth 
to inject spam.  Has anyone else seen this?

Oct 17 15:07:16 mail postfix/smtpd[14422]: connect from unknown[208.86.147.92]
Oct 17 15:07:16 mail dovecot: auth(default): 
passdb(newslet...@mydomain.net,208.86.147.92): Attempted login with password 
having illegal chars
Oct 17 15:07:17 mail dovecot: pop3-login: Disconnected (auth failed, 1 attempts): 
user=, method=PLAIN, rip=208.86.147.92, lip=83.170.64.84
Oct 17 15:07:18 mail postfix/smtpd[14403]: warning: 208.86.147.92: hostname 
default-208-86-147-92.nsihosting.net verification failed: Name or service not 
known



Not new here. I'm using Dovecot auth in Postfix:

Oct 25 04:03:31 mailhost postfix/smtpd[4032]: connect from 
unknown[190.234.148.223]:4139
Oct 25 04:03:36 mailhost dovecot: auth: sql(n...@example.com,190.234.148.223): 
Password mismatch (SHA1 of given password: )
Oct 25 04:03:46 mailhost postfix/smtpd[4032]: disconnect from 
unknown[190.234.148.223]:4139

I'm using sshguard on FreeBSD to block these.

Re: Spammers attempting SASL auth.

[Patrick Ben Koetter]

* Duane Hill :
> On Mon, 17 Oct 2011, Simon Brereton wrote:
> >This is a new one on me - I've never seen spammers attempt to use to SASL 
> >Auth to inject spam.  Has anyone else seen this?
> >
> >Oct 17 15:07:16 mail postfix/smtpd[14422]: connect from 
> >unknown[208.86.147.92]
> >Oct 17 15:07:16 mail dovecot: auth(default): 
> >passdb(newslet...@mydomain.net,208.86.147.92): Attempted login with password 
> >having illegal chars
> >Oct 17 15:07:17 mail dovecot: pop3-login: Disconnected (auth failed, 1 
> >attempts): user=, method=PLAIN, rip=208.86.147.92, 
> >lip=83.170.64.84
> >Oct 17 15:07:18 mail postfix/smtpd[14403]: warning: 208.86.147.92: hostname 
> >default-208-86-147-92.nsihosting.net verification failed: Name or service 
> >not known
> >
> 
> Not new here. I'm using Dovecot auth in Postfix:
> 
> Oct 25 04:03:31 mailhost postfix/smtpd[4032]: connect from 
> unknown[190.234.148.223]:4139
> Oct 25 04:03:36 mailhost dovecot: auth: 
> sql(n...@example.com,190.234.148.223): Password mismatch (SHA1 of given 
> password: )
> Oct 25 04:03:46 mailhost postfix/smtpd[4032]: disconnect from 
> unknown[190.234.148.223]:4139
> 
> I'm using sshguard on FreeBSD to block these.

It's common. Require good passwords. Use fail2ban to block abuse attemtps.
Scan logs for unusual local sender behaviour i.e. outgoing spam.

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):

Re: relay_recipient_maps and LDAP as backend

[Nikolaos Milas]

On 26/10/2011 12:06 μμ, Nerijus Kislauskas wrote:


you miss a point. It's not about the usage of one or another postfix
config parameter. It is about postfix behavior based on LDAP protocol
search operation/results.


Sorry, I misread your initial post.

Nick



smime.p7s
Description: S/MIME Cryptographic Signature

Re: relay_recipient_maps and LDAP as backend

[lst_hoe02]

Zitat von Nerijus Kislauskas :


On 10/26/2011 11:02 AM, Nikolaos Milas wrote:

On 26/10/2011 10:29 πμ, Nerijus Kislauskas wrote:
If you don't want to check users, use:

   relay_recipient_maps =

(i.e. without any value)

You may want to read this message:
http://tech.groups.yahoo.com/group/postfix-users/message/279682 and the
rest of that thread.


Hi Nick,

you miss a point. It's not about the usage of one or another postfix
config parameter. It is about postfix behavior based on LDAP protocol
search operation/results. I use relay_recipient_maps and I need it. The
real question is:

How postfix should decide, that user realy exists when used
relay_recipient_maps config parameter and LDAP backend.

As I can see now, postfix decides, that user exists when some attribute
(or set of attributes) is returned from a search operation. And in my
opinion that is wrong behavior. LDAP search operation returns DN (or set
of DN's) everytime the search query matches any object(s) and
attributes, if requested. if not, only DN's returned. That is all you
need to say, that there is one (more than one) object in DIT, message
will be delivered to. So you should not need to return attributes at all.

I would like to recieve Wietse's comment on that.


For sure i'm not Wietse but IMHO the most error-free code is the one  
you don't write at all. In some cases the results from a database  
lookup are needed in others not, but to use this generic interface in  
all cases you have the need to always provide a result to get the  
lookup succeed.


Not sure which problem your trying to solve anyway.

Regards

Andreas

Re: relay_recipient_maps and LDAP as backend

[Noel Jones]

On 10/26/2011 4:06 AM, Nerijus Kislauskas wrote:

> As I can see now, postfix decides, that user exists when some attribute
> (or set of attributes) is returned from a search operation. And in my
> opinion that is wrong behavior. LDAP search operation returns DN (or set
> of DN's) everytime the search query matches any object(s) and
> attributes, if requested. if not, only DN's returned. That is all you
> need to say, that there is one (more than one) object in DIT, message
> will be delivered to. So you should not need to return attributes at all.

The postfix database interface is a general-purpose mechanism, not
an LDAP interface.  In the case of relay_recipient_maps, the
requirement is that a result must be returned, but the value is not
used.  As long as a lookup returns anything, the user is considered
valid.


  -- Noel Jones

Re: relay_recipient_maps and LDAP as backend

[Nerijus Kislauskas]

On 10/26/2011 01:28 PM, lst_ho...@kwsoft.de wrote:
> In some cases the results from a database lookup are
> needed in others not

Exactly. I should be able to get them, when I need them, and not when I
don't. It's not about problems, it's about protocols and the way they
are used.
-- 
Pagarbiai,
Nerijus Kislauskas
KTU ITPI, Litnet valdymo centras
Studentu g. 48a - 101, Kaunas
tel.: (8~37) 30 06 45
mob. tel.: 8-614-93889
e-mail.: nerijus.kislaus...@ktu.lt

Re: Using Roundcube to send mail on localhost

[Noel Jones]

On 10/26/2011 2:19 AM, Stan Hoeppner wrote:
> On 10/25/2011 5:19 PM, Noel Jones wrote:
> 
>> Probably the best solution is to uncomment the smtps wrappermode SSL
>> master.cf entry, then configure roundcube to submit mail on ssl port
>> 465.
> 
> Maybe I'm missing something Noel.  Why have RC use auth for relay
> submission when both RC and Postfix reside on the same host?
> 
> It seems to me the proper solution is to run the submission (or 587)
> service for remote relay submission clients and have RC submit on TCP 25
> in plain text.
> 
> This is how I've always done it.  Works like champ.
> 


Some people find it helpful to have the auth user recorded in the
postfix log.  It is certainly not required.

If you're going to use AUTH, it's easier to require TLS/SSL
everywhere rather than making exceptions in master.cf, although I
agree that TLS/SSL on the loopback interface is a noop.

And finally, I've had more consistent results using SSL/465 when
using software that might not fully implement SMTP, since it's a
simpler software interface.


  -- Noel Jones

Re: Virtual Domain Restrictions

[Noel Jones]

On 10/26/2011 2:56 AM, Pa - Soscpd wrote:
> 
> 
> Hello List
> 
> 
> My first time here so, please, point me any mistakes.
> 
> I need some special setup for my postfix server (running
> postfix-2.6.5 + mysql on x86_64 kernel 2.6.31) with 11 virtual domains.
> 
> 
> I have several users that does not need to send email offsite, so
> I've managed to create accounts in another domain (and created a new
> virtual on postfix). That far, all is set and working. The problem
> is that users are using the new accounts to send mail off-site. I'm
> trying to figure how to block that communication, so far testing
> smtpd_recipient_restrictions using a hash, with not even a bit of
> success.
> 
> Last attempt, directly from postfix docs:
> 
> smtpd_recipient_restrictions =
> check_sender_access hash:/etc/postfix/restricted_senders
> 
> 
> smtpd_restriction_classes = local_only
> local_only = check_recipient_access
> hash:/etc/postfix/local_domains, reject
> 
> /etc/postfix/restricted_senders:
> internal.domain.1local_only
> internal.domain.nlocal_only
> 
> /etc/postfix/local_domains:
> allowed.domain.1 OK
> allowed.domain.n OK
> 
> 
> My setup need to allow all users from domains listed in
> restricted_senders to send and receive mail from other list of
> domains (local_domains).
> 
> If someone can point me any directions...


Note that smtpd_*_restrictions are not used for mail submitted via
the sendmail(1) command.



  -- Noel Jones

Re: Using Roundcube to send mail on localhost

[Seth Kneller]

On 26.10.2011 07:58, Tobias Hachmer wrote:

On 26.10.2011 02:20, Harald Koch wrote:

On 25/10/2011 5:29 PM, Seth Kneller wrote:
I have postfix and roundcube installed on the same server, postfix 
is

setup to use SASL auth and STARTTLS and I can send messages from
remote clients. However I cannot send messages from roundcube on 
the

localhost.

Can anyone help or point me to where to go next?


FWIW, I have roundcube configured with smtp_server set to
'ssl://localhost' on port 465, instead of using tls://localhost on
port 587. I no longer recall whether that was because STARTTLS 
didn't

work, or for some other reason...


Well, this config with roundcube here works quite well without any 
issues:


Thanks Tobias, the tls://server.name setting in Roundcube worked a 
charm!


Apologies for clogging up Postfix list with RC issues.

Seth

--
Seth Kneller
http://www.autismisanotherworld.com/~seth/blog

Re: Protocol error: postfix-2.3 vs. 2.9

[Wietse Venema]

Ralf Hildebrandt:
> relay=mail.charite.de[141.42.202.200]:25, delay=6.4, delays=0.27/0.01/6.1/0, 
> dsn=5.5.0, status=bounced (Protocol error: host
> mail.charite.de[141.42.202.200] refused to talk to me: 220-mail.charite.de 
> ESMTP 421-4.3.2 All server ports are busy 421 4.3.2

This is fixed in postscreen in snapshot 20111025; a smallest possible
workaround will be released for postfix-2.8.7.

Wietse

Re: Protocol error: postfix-2.3 vs. 2.9

[Ralf Hildebrandt]

* Wietse Venema :
> Ralf Hildebrandt:
> > relay=mail.charite.de[141.42.202.200]:25, delay=6.4, 
> > delays=0.27/0.01/6.1/0, dsn=5.5.0, status=bounced (Protocol error: host
> > mail.charite.de[141.42.202.200] refused to talk to me: 220-mail.charite.de 
> > ESMTP 421-4.3.2 All server ports are busy 421 4.3.2
> 
> This is fixed in postscreen in snapshot 20111025; a smallest possible
> workaround will be released for postfix-2.8.7.

I installed it this morning.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: relay_recipient_maps and LDAP as backend

[Nerijus Kislauskas]

On 10/26/2011 02:09 PM, Noel Jones wrote:
> The postfix database interface is a general-purpose mechanism, not
> an LDAP interface.  In the case of relay_recipient_maps, the
> requirement is that a result must be returned, but the value is not
> used.  As long as a lookup returns anything, the user is considered
> valid.

It depends how you understand "lookup returns". It may be:

a) 0 DN's, 0 attrs
b) 1 DN's, 0 attrs
c) 1 DN's, 1 or more attrs
d) many DN's, 0 attrs
e) many DN's, 1 or more attrs

You talk about option c only. maybe  e will be ok from your point of
view. Option b is also successful result. It returns DN, which match
query_filter with attrs="1.1" (or no attrs requested).

Why option(s) c (and probably e) suites, when b (and probably d) not?

>From my point of view, option a only may result "lookup failed" while
other options - "lookup returned something". Am I not correct?
-- 
Pagarbiai,
Nerijus Kislauskas
KTU ITPI, Litnet valdymo centras
Studentu g. 48a - 101, Kaunas
tel.: (8~37) 30 06 45
mob. tel.: 8-614-93889
e-mail.: nerijus.kislaus...@ktu.lt

Using Postfix to check and verify SPF

[Simon Brereton]

Hi

I finally got around to implementing SPF for my mail server and domains.  A lot 
easier than I thought it would be, certainly much easier than DKIM and I'm 
ashamed I didn't do it earlier.

In the course of doing that, I noticed that gmail/yahoo both add X-Headers 
about the validity of the SPF record.  I would like to do the same.

It doesn't, however, seem sensible to me to have the MTA do that if the 
content-filter will do it - so I fiddled around with amavis, installed 
Mail::SPF and now amavis purports to check the SPF record.  Well, and good, 
except that a) it doesn't add a specific tag line about the SPF validity 
(unless it's a fail) and b) I probably want to REJECT forged mail and not 
DISCARD or TAG..  Although the last option isn't the worst option in the world.

Looking at how to get postfix to do the lifting on this, I find on 
http://www.postfix.org/addon.html that " Note: Postfix already ships with SPF 
support, in the form of a plug-in policy daemon. This is the preferred 
integration model, at least until SPF is mandated by standards."

Well and good - but I don't seem to find further information in the 
documentation.  Added to which, I already pass incoming mail off to 
postfix-policyd for greylisting.  Do I really want to pass it off to a separate 
content filter adding even more hops?

On http://www.postfix.org/docs.html I found 
http://www.freesoftwaremagazine.com/articles/focus_spam_postfix?page=0%2C1# 
which says " use the smtpd-policy.pl script that ships with Postfix to handle 
SPF, and Postgrey as an add-on greylisting policy server. They’re defined in my 
master.cf file as:
spfpolicy unix  -   nn   -  -   spawn
   user=nobody argv=/usr/bin/perl 
 /usr/local/libexec/postfix/smtpd-policy.pl"

But I don't find smtpd-policy.pl in the files installed with Postfix - so I 
assume that's poetic licence..?  And it's actually installed from 
postfix-policyd-spf-perl, yes?  But I notice there's also a python option - 
postfix-policyd-spf-python.  

So my obvious question to the list is - Can I get amavis to explicity add a 
header with the SPF validity, and if not, can I do this with policyd?  And if 
not, and I must install postfix-policyd-spf-python or postfix-policyd-spf-perl 
which do you recommend and why?


Thanks.

Simon

Re: Using Postfix to check and verify SPF

[Scott Kitterman]

On 10/26/2011 10:17 AM, Simon Brereton wrote:
...

So my obvious question to the list is - Can I get amavis to explicity
add a header with the SPF validity, and if not, can I do this with
policyd?  And if not, and I must install postfix-policyd-spf-python
or postfix-policyd-spf-perl which do you recommend and why?


There is an amavis user list that you should consult for amavis support.

postfix-policyd-spf-perl is very simple and is, IMO, not suitable for 
anything other than hobby installs.  postfix-policyd-spf-python is well 
documented, supports a wide variety of configurations for different uses 
and is much more complete.


I'm the last one to do any work on the Perl implementation and the 
developer of the Python implementation.  Unless you are severely 
allergic to Python and prepared to read/modify Perl source, I'd use the 
Python one.  It is available as a distribution package in many distros.


Scott K

Re: relay_recipient_maps and LDAP as backend

[Wietse Venema]

Nerijus Kislauskas:
> On 10/26/2011 02:09 PM, Noel Jones wrote:
> > The postfix database interface is a general-purpose mechanism, not
> > an LDAP interface.  In the case of relay_recipient_maps, the
> > requirement is that a result must be returned, but the value is not
> > used.  As long as a lookup returns anything, the user is considered
> > valid.
> 
> It depends how you understand "lookup returns". It may be:

With Postfix, it means that the ldap_table(5) query returns NO RESULT.
Whatever it takes in the LDAP query that is what will be needed.

Wietse

Re: relay_recipient_maps and LDAP as backend

[Noel Jones]

On 10/26/2011 8:56 AM, Nerijus Kislauskas wrote:
> On 10/26/2011 02:09 PM, Noel Jones wrote:
>> The postfix database interface is a general-purpose mechanism, not
>> an LDAP interface.  In the case of relay_recipient_maps, the
>> requirement is that a result must be returned, but the value is not
>> used.  As long as a lookup returns anything, the user is considered
>> valid.
> 
> It depends how you understand "lookup returns". It may be:
> 
>...

You miss the point.  Postfix is database-agnostic.  The result from
any table lookup must be a non-empty value or "not found".  Outside
of the LDAP interface, postfix doesn't know what a DN or an attr is,
only "key" and "result".  The query you construct for LDAP must
return what postfix expects.

I'm sure there could be a great number of optimizations made to
lookups if postfix used LDAP (or any single table type) exclusively,
but that's not how it works.

If you can figure out optimizations to the LDAP interface without
breaking other supported table types, feel free to submit a patch.



  -- Noel Jones

Re: Using Postfix to check and verify SPF

[Simon Brereton]

On 26 October 2011 10:27, Scott Kitterman  wrote:
> On 10/26/2011 10:17 AM, Simon Brereton wrote:
> ...
>>
>> So my obvious question to the list is - Can I get amavis to explicity
>> add a header with the SPF validity, and if not, can I do this with
>> policyd?  And if not, and I must install postfix-policyd-spf-python
>> or postfix-policyd-spf-perl which do you recommend and why?
>
> There is an amavis user list that you should consult for amavis support.

True - but most people use it.  Googling didn't help, so it's unlikely
that it can do it - still worth asking the wise people here though.

> postfix-policyd-spf-perl is very simple and is, IMO, not suitable for
> anything other than hobby installs.  postfix-policyd-spf-python is well
> documented, supports a wide variety of configurations for different uses and
> is much more complete.
>
> I'm the last one to do any work on the Perl implementation and the developer
> of the Python implementation.  Unless you are severely allergic to Python
> and prepared to read/modify Perl source, I'd use the Python one.  It is
> available as a distribution package in many distros.

Thanks for the advice.  Curiously for a "hobby installs" package it
has more howtos and documentation on Google.  I'm not adverse to
python, but I'd still like reassurance that two policy filters is the
way to go..  For my edification, where would you put it in my
restrictions?

smtpd_recipient_restrictions = reject_non_fqdn_sender,
reject_non_fqdn_recipient,
permit_sasl_authenticated,
reject_sender_login_mismatch,
check_helo_access hash:/etc/postfix/helo_checks,
check_sender_access hash:/etc/postfix/ip_whitelist,
check_recipient_access hash:/etc/postfix/laxdomains,
check_sender_access hash:/etc/postfix/backscatter
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre
permit_mynetworks,
check_policy_service inet:127.0.0.1:10031,
reject_unlisted_recipient,
reject_unauth_destination,
reject_rbl_client bl.spamcop.net,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client blackholes.mail-abuse.org,
reject_rbl_client tw.countries.nerd.dk,
reject_rbl_client kr.countries.nerd.dk,
reject_rbl_client cn.countries.nerd.dk,
reject_rbl_client relays.mail-abuse.org,
reject_rhsbl_sender dsn.rfc-ignorant.org,
warn_if_reject,
reject_unknown_client,
warn_if_reject,
reject_rhsbl_client dsn.rfc-ignorant.org,
warn_if_reject,
reject_rbl_client dnsbl.sorbs.net,
warn_if_reject,
reject_rbl_client dnsbl.njabl.org,
warn_if_reject,
reject_rbl_client dul.dnsbl.sorbs.net,
permit


Simon

Re: Using Postfix to check and verify SPF

[Scott Kitterman]

On 10/26/2011 10:44 AM, Simon Brereton wrote:

On 26 October 2011 10:27, Scott Kitterman  wrote:

On 10/26/2011 10:17 AM, Simon Brereton wrote:
...


So my obvious question to the list is - Can I get amavis to explicity
add a header with the SPF validity, and if not, can I do this with
policyd?  And if not, and I must install postfix-policyd-spf-python
or postfix-policyd-spf-perl which do you recommend and why?

...

postfix-policyd-spf-perl is very simple and is, IMO, not suitable for
anything other than hobby installs.  postfix-policyd-spf-python is well
documented, supports a wide variety of configurations for different uses and
is much more complete.

I'm the last one to do any work on the Perl implementation and the developer
of the Python implementation.  Unless you are severely allergic to Python
and prepared to read/modify Perl source, I'd use the Python one.  It is
available as a distribution package in many distros.


Thanks for the advice.  Curiously for a "hobby installs" package it
has more howtos and documentation on Google.  I'm not adverse to
python, but I'd still like reassurance that two policy filters is the
way to go..  For my edification, where would you put it in my
restrictions?


I'm not sure I understand the rationale behind your current setup well 
enough to make a specific recommendation. I think the documentation 
shipped with both policy servers should give sufficient guidance.


The Perl implementation was done several years before the Python one and 
was, for many years, shipped with Postfix, so it's not surprising that 
it would show up that way.  If it works for you as is, it's fine, but it 
is missing a lot of options supported in the new Python implementation 
(grab the source and read the documentation for details).


Scott K

Hourly postfix consultant needed

[Dan Richman]

Hello -

We are in need of an hourly resource to ask questions & get configuration help 
for postfix from time to time.

Email me privately if you're interested:  d...@danrichman.com


Thanks -

Re: Hourly postfix consultant needed

[Dan Richman]

Update:  Found someone.  That was fast.

Thanks!

Re: relay_recipient_maps and LDAP as backend

[Viktor Dukhovni]

On Wed, Oct 26, 2011 at 04:56:40PM +0300, Nerijus Kislauskas wrote:
> On 10/26/2011 02:09 PM, Noel Jones wrote:
> > The postfix database interface is a general-purpose mechanism, not
> > an LDAP interface.  In the case of relay_recipient_maps, the
> > requirement is that a result must be returned, but the value is not
> > used.  As long as a lookup returns anything, the user is considered
> > valid.
> 
> It depends how you understand "lookup returns". It may be:

The LDAP table driver considers entries that match the query filter,
but which lack the requested attributes, or have only empty values
for the requested attributes to not be matching attributes. The Postfix
dictionary abstraction above the Postfix LDAP driver therefore only sees
entries with non-empty result (or leaf or terminal) attributes.

-- 
Viktor.

Re: relay_recipient_maps and LDAP as backend

[Nerijus Kislauskas]

On 10/26/2011 08:11 PM, Viktor Dukhovni wrote:
> The LDAP table driver considers entries that match the query filter,
> but which lack the requested attributes, or have only empty values
> for the requested attributes to not be matching attributes. The Postfix
> dictionary abstraction above the Postfix LDAP driver therefore only sees
> entries with non-empty result (or leaf or terminal) attributes.

Hi Victor and others,

So in other words you want to say, that "our implementation of ldap
lookup table is strongly tied to LDAP ACLs. When I have enought rights
to read something from LDAP, entry exists, and when my drunk LDAP admin
thinks, that I have too much rights, lookup will fail, even when I got 1
entry match". Wake up guys. When you are doing lookups especialy when
result is not used anywhere, why do you care you can read something from
LDAP or not? When you get a DN (and DN you get always if there is a
match), that's it, entry found.

LDAP protocol is a beauty. The masterpiece is how you are using it.
-- 
Pagarbiai,
Nerijus Kislauskas
KTU ITPI, Litnet valdymo centras
Studentu g. 48a - 101, Kaunas
tel.: (8~37) 30 06 45
mob. tel.: 8-614-93889
e-mail.: nerijus.kislaus...@ktu.lt

Re: A Problem No One Has Solved According To Googling

[Jeroen Geilman]

On 2011-10-26 01:37, Jack Fredrikson wrote:


**Hey, everybody: thanks so much for trying to help. I really 
appreciate it. But I've killed a week and before I kill myself, I'm 
throwing in the towel until I build that new server.




Yes, because everybody knows that building a NEW server while not 
understanding what was wrong with the old one is the solution to every 
problem.



--
J.

Re: Using Postfix to check and verify SPF

[Steve Fatula]

So my obvious question to the list is - Can I get amavis to explicity add a 
header with the SPF validity, and if not, can I do this with policyd?  And if 
not, and I must install postfix-policyd-spf-python or postfix-policyd-spf-perl 
which do you recommend and why?
>
>Can't help you with Amavis, but, I use mailfromd. It's fast (C), and, can add 
>headers or do most anything. We do use it to add our own SPF header. This in 
>turn feeds dspam, and, we also greylist those not passing the SPF check 
>(unless FAIL, where we do reject the message). So, if none of the others work 
>out, mailfromd certainly will.

Re: relay_recipient_maps and LDAP as backend

[Wietse Venema]

Nerijus Kislauskas:
> On 10/26/2011 08:11 PM, Viktor Dukhovni wrote:
> > The LDAP table driver considers entries that match the query filter,
> > but which lack the requested attributes, or have only empty values
> > for the requested attributes to not be matching attributes. The Postfix
> > dictionary abstraction above the Postfix LDAP driver therefore only sees
> > entries with non-empty result (or leaf or terminal) attributes.
> 
> Hi Victor and others,
> 
> So in other words you want to say, that "our implementation of ldap
> lookup table is strongly tied to LDAP ACLs. When I have enought rights
> to read something from LDAP, entry exists, and when my drunk LDAP admin
> thinks, that I have too much rights, lookup will fail, even when I got 1
> entry match". Wake up guys. [insults deleted]

You're welcome to provide a better design, provided that ***it does
not break the Postfix table lookup interface***.

You can start reading at http://www.postfix.org/DATABASE_README.html

Wietse

Re: relay_recipient_maps and LDAP as backend

[Viktor Dukhovni]

On Wed, Oct 26, 2011 at 09:17:17PM +0300, Nerijus Kislauskas wrote:
> On 10/26/2011 08:11 PM, Viktor Dukhovni wrote:
> > The LDAP table driver considers entries that match the query filter,
> > but which lack the requested attributes, or have only empty values
> > for the requested attributes to not be matching attributes. The Postfix
> > dictionary abstraction above the Postfix LDAP driver therefore only sees
> > entries with non-empty result (or leaf or terminal) attributes.
> 
> Hi Victor and others,
> 
> So in other words you want to say, that "our implementation of ldap
> lookup table is strongly tied to LDAP ACLs.

Nothing of the sort, in fact LDAP ACLs typically easily hide the entries
themselves not just the attributes, since otherwise I can discover the
attribute quickly by alphabetic search:

(&(attribute=a*)...)
(&(attribute=b*)...)
(&(attribute=c*)...) ... Until match, then
(&(attribute=ca*)...)
(&(attribute=cb*)...)
(&(attribute=cc*)...)
(&(attribute=cd*)...) ... Until match, ...

This does not take very long...

> When I have enough rights
> to read something from LDAP, entry exists, and when my drunk LDAP admin
> thinks, that I have too much rights, lookup will fail, even when I got 1
> entry match".

Nonsense, you are the mercy of your drunk LDAP admin when you choose to
use LDAP. The admin can also delete all the entries, hide a sub-tree, ...

> Wake up guys.

Lose the attitude or go away.  You're new here, it rather presumptuous
to start lecturing people who've been here for 10+ years.

The Postfix LDAP driver does not know
whether the result is wanted or not, that's much higher up in the
stack. Its job is to retrieve results, and there are no results to
return when the attribute is missing, in fact this is desirable
when groups contain members with no email address for reasons
unrelated to email, ...

The treatment of empty attribute values was chosen to be least
surprising to most users where blank and missing work interchangeably,
rather than Postfix returning configuration errors and warnings
about bad table results.

-- 
Viktor.

Re: Virtual Domain Restrictions

[Pa - Soscpd]

Em 26/10/2011 09:23, Noel Jones escreveu:

On 10/26/2011 2:56 AM, Pa - Soscpd wrote:


Hello List


My first time here so, please, point me any mistakes.

I need some special setup for my postfix server (running
postfix-2.6.5 + mysql on x86_64 kernel 2.6.31) with 11 virtual domains.


I have several users that does not need to send email offsite, so
I've managed to create accounts in another domain (and created a new
virtual on postfix). That far, all is set and working. The problem
is that users are using the new accounts to send mail off-site. I'm
trying to figure how to block that communication, so far testing
smtpd_recipient_restrictions using a hash, with not even a bit of
success.

Last attempt, directly from postfix docs:

smtpd_recipient_restrictions =
 check_sender_access hash:/etc/postfix/restricted_senders


smtpd_restriction_classes = local_only
 local_only = check_recipient_access
hash:/etc/postfix/local_domains, reject

/etc/postfix/restricted_senders:
 internal.domain.1local_only
 internal.domain.nlocal_only

/etc/postfix/local_domains:
allowed.domain.1 OK
allowed.domain.n OK


My setup need to allow all users from domains listed in
restricted_senders to send and receive mail from other list of
domains (local_domains).

If someone can point me any directions...


Note that smtpd_*_restrictions are not used for mail submitted via
the sendmail(1) command.



   -- Noel Jones


Hi Noel

I'm testing with roundcube using IMAP, so I guess that's not the issue (and the 
incomming mail restriction rule also does not work). I think no restriction at 
all is matching.



Thanks for your reply.


Regards
Rafael

Config check

[IT geek 31]

Hi,

I'm trying to achieve the following:

Stop spammers (obviously)
Permit relaying when I'm outside the network (using SASL)

After reading through postconf, to prevent duplicate checks I removed
a number of checks from smtpd_sender_restrictions, so that it now
looks like this:

smtpd_sender_restrictions = reject_unknown_sender_domain,
reject_non_fqdn_sender, permit

smtpd_recipient_restrictions = permit_sasl_authenticated,
reject_unauth_destination, check_recipient_access
hash:/usr/pkg/etc/postfix/access, reject_unauth_pipelining,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
reject_rbl_client zen.spamhaus.org, check_policy_service
inet:127.0.0.1:10023, permit

I have also set smtpd_delay_reject = yes

However my access file does not appear to be being used (specifies an
address to be rejected, but it isn't).

Please can someone sanity check the smtpd_recipient_restrictions line
for me and verify the order is correct.  I'm looking to move to 2.8,
but I want to make sure my config is correct before I do.

postconf -n attached.

Many thanks,


-Mark


postconf
Description: Binary data

Re: relay_recipient_maps and LDAP as backend

[Nerijus Kislauskas]

On 10/26/2011 11:06 PM, Viktor Dukhovni wrote:
> Lose the attitude or go away.  You're new here, it rather presumptuous
> to start lecturing people who've been here for 10+ years.

Then I will hit myself in the cheek.

> The Postfix LDAP driver does not know
> whether the result is wanted or not

There are 2 types of lookups:

a) lookups which needs to return something, for example
virtual_mailbox_maps
virtual_uid_maps
virtual_gid_maps
address rewriting maps and so on.

b) lookups which doesn't need to return anything useful
relay_recipient_maps
local_recipient_maps
etc

(a) group needs "read" permission on result_attribute attributes, while
(b) group needs only "search" permission. What I want from all ot this,
that postfix would be able to work with minimal required ldap access
permissions. And now you require "read" for both of them. Pity.
-- 
Pagarbiai,
Nerijus Kislauskas
KTU ITPI, Litnet valdymo centras
Studentu g. 48a - 101, Kaunas
tel.: (8~37) 30 06 45
mob. tel.: 8-614-93889
e-mail.: nerijus.kislaus...@ktu.lt

Re: Config check

[/dev/rob0]

On Wednesday 26 October 2011 16:28:43 IT geek 31 wrote:
> I'm trying to achieve the following:
> 
> Stop spammers (obviously)
> Permit relaying when I'm outside the network (using SASL)
> 
> After reading through postconf, to prevent duplicate checks I
> removed a number of checks from smtpd_sender_restrictions, so that
> it now looks like this:
> 
> smtpd_sender_restrictions = reject_unknown_sender_domain,
> reject_non_fqdn_sender, permit
> 
> smtpd_recipient_restrictions = permit_sasl_authenticated,
> reject_unauth_destination,

For simplicity, you could insert the reject_* sender restrictions 
here, and eliminate smtpd_sender_restrictions.

> check_recipient_access hash:/usr/pkg/etc/postfix/access,

"access" is a bad name for this. Since you're checking recipient 
addresses, I would suggest a name of "rcpt_access", or similar.

> reject_unauth_pipelining,
> reject_non_fqdn_recipient, reject_unknown_recipient_domain,

These two will do nothing useful. They don't hurt, but it might be 
useful for you to consider what they are. Spammers are going to be 
hitting you with addresses@your.actual.domains. They are probably not 
trying to hit "addresses@localhost" and the like.

> reject_rbl_client zen.spamhaus.org, check_policy_service
> inet:127.0.0.1:10023, permit
> 
> I have also set smtpd_delay_reject = yes

There is no need to set that, as "yes" is the default value.

> However my access file does not appear to be being used (specifies
> an address to be rejected, but it isn't).

I don't suppose we can help with that without the relevant logs and 
portions of /usr/pkg/etc/postfix/access that you think should have 
matched. But before you post again, note again that it is called as a 
*recipient* address lookup. It will not be searched for client, helo, 
nor sender addresses.

> Please can someone sanity check the smtpd_recipient_restrictions
> line for me and verify the order is correct.  I'm looking to move
> to 2.8, but I want to make sure my config is correct before I do.
> 
> postconf -n attached.

> smtpd_helo_restrictions = check_helo_access
> hash:/usr/pkg/etc/postfix/helo_access, reject_non_fqdn_hostname,
> reject_invalid_hostname, reject_unknown_hostname, permit

This check_helo_access file, /usr/pkg/etc/postfix/helo_access, has a 
better name. You are using the old syntax for 
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, and 
reject_unknown_helo_hostname, but that is not a problem.

Do, however, consider that the latter will block a great deal of non-
spam. There are many MTAs behind NAT which will use a HELO name which 
does not resolve in the global DNS. (The non-FQDN and invalid checks 
are safe and effective.)

Finally, you likewise might consider it easier to consolidate these 
into the recipient restriction stage, but do not do that if you're 
using helo_access as a whitelist. This is covered in the 
SMTPD_ACCESS_README, "dangerous use of smtpd_recipient_restrictions" 
section.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Good tutorial on basic, outgoing-only mail

[René Fournier]

I'm slowly switching all my UNIX needs over to Macports packages, from Mac OS X 
Server's Admin console. This means learning a few new things, such as mail in 
general, and Postfix in particular.

Now, I've found lots of tutorials on Postfix that cover a range of topics, 
seemingly for moderate-to-complex needs. Mine are pretty simple. I have a 
server that simply needs to send out notification emails on a regular, 
high-volume basis. I would like to avoid blacklists and spam algorithms (since 
my application is not spam), and therefore do things "the right way" -- but 
without adding unnecessary complexity (virus scanning, web mail (there are no 
user accounts here), etc.).

Any suggestions where to start? I suppose there's a bit of DNS stuff I need to 
do to in terms of pointing an MX record at this machines public IP address, 
etc. Anyway, any suggestion are highly appreciated. Thanks!

…Rene

Re: Config check

[IT geek 31]

Hi Rob

Thanks for your reply - that's certainly cleared a few things up!

>> check_recipient_access hash:/usr/pkg/etc/postfix/access,
>
> "access" is a bad name for this. Since you're checking recipient
> addresses, I would suggest a name of "rcpt_access", or similar.

I've renamed this to sender_access (see below).

>> reject_unauth_pipelining,
>> reject_non_fqdn_recipient, reject_unknown_recipient_domain,
>
> These two will do nothing useful. They don't hurt, but it might be
> useful for you to consider what they are. Spammers are going to be
> hitting you with addresses@your.actual.domains. They are probably not
> trying to hit "addresses@localhost" and the like.

Removed.

>> I have also set smtpd_delay_reject = yes
>
> There is no need to set that, as "yes" is the default value.

Removed.

>> However my access file does not appear to be being used (specifies
>> an address to be rejected, but it isn't).

My access file actually listed senders, so that's why that obviously
didn't work.

> I don't suppose we can help with that without the relevant logs and
> portions of /usr/pkg/etc/postfix/access that you think should have
> matched. But before you post again, note again that it is called as a
> *recipient* address lookup. It will not be searched for client, helo,
> nor sender addresses.

I guess what I'm after is a way to whitelist certain senders.  ie. if
they're okay, then no further processing is needed - just deliver.  Is
this possible?  If so, presumably smtpd_sender_restrictions =
check_sender_access hash:/sender_access is the place to put it?

> This check_helo_access file, /usr/pkg/etc/postfix/helo_access, has a
> better name. You are using the old syntax for
> reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, and
> reject_unknown_helo_hostname, but that is not a problem.

I have replaced these with up-to-date syntax.

Fresh postconf -n attached.

Re: Good tutorial on basic, outgoing-only mail

[Wietse Venema]

Ren? Fournier:
> I'm slowly switching all my UNIX needs over to Macports packages,
> from Mac OS X Server's Admin console. This means learning a few
> new things, such as mail in general, and Postfix in particular.
>
> Now, I've found lots of tutorials on Postfix that cover a range
> of topics, seemingly for moderate-to-complex needs. Mine are pretty
> simple. I have a server that simply needs to send out notification
> emails on a regular, high-volume basis. I would like to avoid
> blacklists and spam algorithms (since my application is not spam),
> and therefore do things "the right way" -- but without adding
> unnecessary complexity (virus scanning, web mail (there are no
> user accounts here), etc.).

With high enough volume it may be more productive to hire a
professional email service provider (ESP). I'm not in that business.

> Any suggestions where to start? I suppose there's a bit of DNS
> stuff I need to do to in terms of pointing an MX record at this
> machines public IP address, etc. Anyway, any suggestion are highly
> appreciated. Thanks!

High-volume email is not covered in Postfix documentation as the
requirements are complex and subject to change. For an overview
see http://wiki.wordtothewise.com/Main_Page

Wietse

Re: Odd postfix LDAP behavior

[Quanah Gibson-Mount]

--On October 26, 2011 6:08:56 AM + Viktor Dukhovni 
 wrote:



On Tue, Oct 25, 2011 at 10:14:39PM -0700, Quanah Gibson-Mount wrote:


Ok, logs were still on the server I was using earlier.  Here's part
of one of the connections in question.


LDAP server logs are no way to report a suspected Postfix issue to
this list. They are for LDAP administrators, not Postfix experts.


Generally I would agree with you.  However the fact that postfix clearly 
continues its session after receiving error from the LDAP server clearly 
indicates a bug in the postfix code.



To report a Postfix LDAP issue, post the output of:

postmap -v -q lookup-key ldap:/some/table.cf

Naturally also post the Postfix table definition, which will indicate
whether you're using simple or SASL binds. If possible try both,
and report any difference in behaviour, since as you know the SASL
bind code is relatively new, perhaps there are subtleties in the
LDAP API that were not taken into account, but I prefer to not
speculate on the likelihood of such an issue with no usable
information.


I'm using simple binds as I have since postfix 2.3.  I actually was not 
aware the code for using SASL mechanism binds had been added to postfix. 
Very happy to know that. ;)  I have my own test server set up now so I can 
better get the information you're asking for.


First, a normal postmap -q when the user exists and it has a working 
password:


zimbra@zre-ldap002:~$ postmap -q testus...@zre-ldap002.eng.vmware.com 
ldap:/opt/zimbra/conf/ldap-transport.cf

lmtp:zre-ldap002.eng.vmware.com:7025

Now, I change the password to something else entirely.  postmap reports 
"success" binding and proceeds with the query, when in fact it did not bind 
successfully.


postmap: dict_ldap_lookup: In dict_ldap_lookup
postmap: dict_ldap_lookup: No existing connection for LDAP source 
/opt/zimbra/conf/ldap-transport.cf, reopening
postmap: dict_ldap_connect: Connecting to server 
ldap://zre-ldap002.eng.vmware.com:389

postmap: dict_ldap_connect: Actual Protocol version used is 3.
postmap: dict_ldap_connect: Binding to server 
ldap://zre-ldap002.eng.vmware.com:389 with dn 
uid=zmpostfix,cn=appaccts,cn=zimbra
postmap: dict_ldap_connect: Successful bind to server 
ldap://zre-ldap002.eng.vmware.com:389 with dn 
uid=zmpostfix,cn=appaccts,cn=zimbra
postmap: dict_ldap_connect: Cached connection handle for LDAP source 
/opt/zimbra/conf/ldap-transport.cf
postmap: dict_ldap_lookup: /opt/zimbra/conf/ldap-transport.cf: Searching 
with filter 
(&(|(zimbraMailDeliveryAddress=testus...@zre-ldap002.eng.vmware.com)(zimbraDomainName=testus...@zre-ldap002.eng.vmware.com))(zimbraMailStatus=enabled))

postmap: dict_ldap_get_values[1]: Search found 0 match(es)
postmap: dict_ldap_get_values[1]: Leaving dict_ldap_get_values
postmap: dict_ldap_lookup: Search returned nothing
postmap: dict_ldap_close: Closed connection handle for LDAP source 
/opt/zimbra/conf/ldap-transport.cf




Please also try to report results from ldapsearch(1) performing the
same query with identical authentication/connection settings.


zimbra@zre-ldap002:~$ ldapsearch -LLL -H ldap://zre-ldap002.eng.vmware.com 
-x -D "uid=zmpostfix,cn=appaccts,cn=zimbra" -w zimbra 
"(&(|(zimbraMailDeliveryAddress=testus...@zre-ldap002.eng.vmware.com)(zimbraDomainName=testus...@zre-ldap002.eng.vmware.com))(zimbraMailStatus=enabled))"

ldap_bind: Invalid credentials (49)

(and disconnect)

With valid credentials, it returns the correct results:

zimbra@zre-ldap002:~$ ldapsearch -LLL -H ldap://zre-ldap002.eng.vmware.com 
-x -D "uid=zmpostfix,cn=appaccts,cn=zimbra" -w zimbra123 
"(&(|(zimbraMailDeliveryAddress=testus...@zre-ldap002.eng.vmware.com)(zimbraDomainName=testus...@zre-ldap002.eng.vmware.com))(zimbraMailStatus=enabled))"

dn: uid=testuser1,ou=people,dc=zre-ldap002,dc=eng,dc=vmware,dc=com
objectClass: inetOrgPerson
objectClass: zimbraAccount
objectClass: amavisAccount
zimbraId: 6d672aa4-dc4c-48b2-bc6f-95009014dd6f
zimbraMailHost: zre-ldap002.eng.vmware.com
zimbraMailTransport: lmtp:zre-ldap002.eng.vmware.com:7025
zimbraMailStatus: enabled
zimbraMailDeliveryAddress: testus...@zre-ldap002.eng.vmware.com
mail: testus...@zre-ldap002.eng.vmware.com
cn: testuser1
sn: testuser1
uid: testuser1

--Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Odd postfix LDAP behavior

[Quanah Gibson-Mount]

--On October 26, 2011 4:45:01 PM -0700 Quanah Gibson-Mount 
 wrote:



I'm using simple binds as I have since postfix 2.3.  I actually was not
aware the code for using SASL mechanism binds had been added to postfix.
Very happy to know that. ;)  I have my own test server set up now so I
can better get the information you're asking for.

First, a normal postmap -q when the user exists and it has a working
password:

zimbra@zre-ldap002:~$ postmap -q testus...@zre-ldap002.eng.vmware.com
ldap:/opt/zimbra/conf/ldap-transport.cf
lmtp:zre-ldap002.eng.vmware.com:7025


Here is the ldap-transport.cf file:

root@zre-ldap002:/opt/zimbra/conf# cat ldap-transport.cf
server_host = ldap://zre-ldap002.eng.vmware.com:389
server_port = 389
search_base =
query_filter = 
(&(|(zimbraMailDeliveryAddress=%s)(zimbraDomainName=%s))(zimbraMailStatus=enabled))

result_attribute = zimbraMailTransport
version = 3
start_tls = yes
tls_ca_cert_dir = /opt/zimbra/conf/ca
bind = yes
bind_dn = uid=zmpostfix,cn=appaccts,cn=zimbra
bind_pw = zimbra
timeout = 30

I will note that I build with -DUSE_LDAP_SASL and use OpenLDAP as the API. 
It *looks* like this should use the old dict_ldap_bind_st function, but 
since there is no logging in it or dict_ldap_bind_sasl specifically noting 
which is used, I can't be 100% sure.


--Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Good tutorial on basic, outgoing-only mail

[René Fournier]

On 2011-10-26, at 5:41 PM, Wietse Venema wrote:
> 
> With high enough volume it may be more productive to hire a
> professional email service provider (ESP). I'm not in that business.

For a variety of reasons, this isn't an option for us.

>> Any suggestions where to start? I suppose there's a bit of DNS
>> stuff I need to do to in terms of pointing an MX record at this
>> machines public IP address, etc. Anyway, any suggestion are highly
>> appreciated. Thanks!
> 
> High-volume email is not covered in Postfix documentation as the
> requirements are complex and subject to change. 

Well, high volume is maybe overstating it. I would guess a few hundred outgoing 
emails a day, mostly to different people. Our current Server Admin Mail server 
in 10.6 Server works great. Just gotta to do the same with Postfix at the 
command-line.

…Rene

Re: Good tutorial on basic, outgoing-only mail

[/dev/rob0]

On Wednesday 26 October 2011 18:09:56 René Fournier wrote:
> Now, I've found lots of tutorials on Postfix that cover a range of
> topics, seemingly for moderate-to-complex needs. Mine are pretty
> simple. I have a server that simply needs to send out notification
> emails on a regular, high-volume basis. I would like to avoid
> blacklists and spam algorithms (since my application is not spam),
> and therefore do things "the right way" -- but without adding

The best "trick" to avoid blacklisting is just that: do it right. 
Don't send unsolicited bulk mails. Send out one confirmation mail; 
don't send anything else if that is not confirmed.

Some folks think that IP-address-hopping is a good way to avoid 
listings. On the contrary: you want to build and maintain a good 
reputation. Sign up with DNSWL.org.

> unnecessary complexity (virus scanning, web mail (there are no
> user accounts here), etc.).
> 
> Any suggestions where to start? I suppose there's a bit of DNS
> stuff I need to do to in terms of pointing an MX record at this

MX is only for receiving mail, but of course you are right: there can 
be no such thing as "outgoing-only mail." You need to publish and 
monitor an abuse address. You probably WILL get a few complaints, no 
matter how well you do things "the right way".

(The abuse address can be hosted elsewhere, but you should get and 
read mail for postmaster@ and abuse@ your $myhostname anyway.)

A sending host needs forward-confirmed reverse DNS, and that PTR name 
should be your $myhostname in Postfix. The IP address must be "clean" 
and hosted by an upstream provider with good anti-abuse policies.

> machines public IP address, etc. Anyway, any suggestion are highly
> appreciated. Thanks!

The ESP suggestion was very good. "Doing it right" in the email world 
is very difficult. If money is at stake, spend a little of it. It may 
end up saving you far more than you spend!
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Good tutorial on basic, outgoing-only mail

[Viktor Dukhovni]

On Wed, Oct 26, 2011 at 07:42:54PM -0600, Ren? Fournier wrote:

> > High-volume email is not covered in Postfix documentation as the
> > requirements are complex and subject to change. 
> 
> Well, high volume is maybe overstating it. I would guess a few
> hundred outgoing emails a day, mostly to different people. Our
> current Server Admin Mail server in 10.6 Server works great. Just
> gotta to do the same with Postfix at the command-line.

This is funny. High volume on this list means O(100) (typical
range from 10 to 300) msgs/sec, not 100 msgs/day. Your volume
would be called "negligible". :-)

Your Postfix requires no performance tuning, use it in good health.

-- 
Viktor.

PROPOSED PATCH. Please test (was: Odd postfix LDAP behavior)

[Viktor Dukhovni]

On Wed, Oct 26, 2011 at 05:10:41PM -0700, Quanah Gibson-Mount wrote:

> >I'm using simple binds as I have since postfix 2.3.  I actually was not
> >aware the code for using SASL mechanism binds had been added to postfix.
> >Very happy to know that. ;)  I have my own test server set up now so I
> >can better get the information you're asking for.
> >
> >First, a normal postmap -q when the user exists and it has a working
> >password:
> 
> I will note that I build with -DUSE_LDAP_SASL and use OpenLDAP as
> the API. It *looks* like this should use the old dict_ldap_bind_st
> function, but since there is no logging in it or dict_ldap_bind_sasl
> specifically noting which is used, I can't be 100% sure.

I hate people who document interface semantics poorly and then have
the gall to change said undocumented sematics!

Someone "clever" decided to change the implementation of
ldap_parse_sasl_bind_result() between OpenLDAP 2.3 and OpenLDAP
2.4. The 2.3 version returned an error when the bind failed. The
2.4 version sets ld->ld_error as a side-effect and returns
LDAP_SUCCESS.  Apparently, the routine now just tells you whether
the result was decoded successfully, and the the decoded failure
status has to be determined by the caller.

I think this change was unwise. That said, there appears to be
a related issue in the Postfix code that should have the issue
in ldap_result() rather than in ldap_parse_sasl_bind_result().

Therefore, I propose the following Postfix fix/work-around which
is required for anyone running Postfix 2.3 or later, linked with
OpenLDAP 2.4 or later (perhaps even late 2.3.x releases, I just
compared OpenLDAP 2.3.4 with 2.4.23).

By the way, switching to "bind = sasl" may solve the problem for
you, if "sasl_mechs = plain" is compatible with "simple" binds in
your server. The new SASL code leaves more of the error handling
to the LDAP library, since the state-machine for SASL is not exposed
by OpenLDAP to applications to handle timeouts, and getting timeouts
right in this case would in any case probably not justify the extra
code, since we could still block in Kerberos libraries, ... (it
is turtles all the way down!).

Index: src/global/dict_ldap.c
--- src/global/dict_ldap.c  1 Mar 2011 04:44:42 -   1.1.1.2
+++ src/global/dict_ldap.c  27 Oct 2011 04:04:11 -
@@ -498,6 +498,7 @@
 static int dict_ldap_result(LDAP *ld, int msgid, int timeout, LDAPMessage 
**res)
 {
 struct timeval mytimeval;
+int err;
 
 mytimeval.tv_sec = timeout;
 mytimeval.tv_usec = 0;
@@ -506,10 +507,14 @@
 if (ldap_result(ld, msgid, GET_ALL, &mytimeval, res) == -1)
return (dict_ldap_get_errno(ld));
 
-if (dict_ldap_get_errno(ld) == LDAP_TIMEOUT) {
-   (void) dict_ldap_abandon(ld, msgid);
-   return (dict_ldap_set_errno(ld, LDAP_TIMEOUT));
+if ((err = dict_ldap_get_errno(ld)) != LDAP_SUCCESS) {
+   if (err == LDAP_TIMEOUT) {
+   (void) dict_ldap_abandon(ld, msgid);
+   return (dict_ldap_set_errno(ld, LDAP_TIMEOUT));
+   }
+   return err;
 }
+
 return LDAP_SUCCESS;
 }
 

-- 
Viktor.

Re: PROPOSED PATCH. Please test (was: Odd postfix LDAP behavior)

[Quanah Gibson-Mount]

--On October 27, 2011 4:14:12 AM + Viktor Dukhovni 
 wrote:



Therefore, I propose the following Postfix fix/work-around which
is required for anyone running Postfix 2.3 or later, linked with
OpenLDAP 2.4 or later (perhaps even late 2.3.x releases, I just
compared OpenLDAP 2.3.4 with 2.4.23).


Hi Viktor,

Doing a new build with the patch now.

--Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: relay_recipient_maps and LDAP as backend

[Nikolaos Milas]

On 27/10/2011 12:59 πμ, Nerijus Kislauskas wrote:


(a) group needs "read" permission on result_attribute attributes, while
(b) group needs only "search" permission. What I want from all ot this,
that postfix would be able to work with minimal required ldap access
permissions. And now you require "read" for both of them. Pity.


Now come on, Nerijus, there is no associated security risk with that. If 
you feel uneasy, create a separate LDAP user with proper access rights 
just for postfix use. Providing postfix user with read access to lookup 
tables won't cause any harm to LDAP security.


If you feel this is an imperfect scenario (which is debatable), keep in 
mind that we can not bring things to perfection. Have you perfected all 
your other coding and/or administrative tasks?


We are all striving for perfection, but some things might not or should 
not need to be stretched more than they are because we live in a world 
of priorities and time/effort is a scarce resource. And Postfix is close 
to perfection anyway (at least for most of people). :-)


Nick



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Good tutorial on basic, outgoing-only mail

[René Fournier]

Well, I checked, I was off a bit. About 10,000 per day. Still low though it 
seems.

On 2011-10-26, at 9:40 PM, Viktor Dukhovni wrote:

> On Wed, Oct 26, 2011 at 07:42:54PM -0600, Ren? Fournier wrote:
> 
>>> High-volume email is not covered in Postfix documentation as the
>>> requirements are complex and subject to change. 
>> 
>> Well, high volume is maybe overstating it. I would guess a few
>> hundred outgoing emails a day, mostly to different people. Our
>> current Server Admin Mail server in 10.6 Server works great. Just
>> gotta to do the same with Postfix at the command-line.
> 
> This is funny. High volume on this list means O(100) (typical
> range from 10 to 300) msgs/sec, not 100 msgs/day. Your volume
> would be called "negligible". :-)
> 
> Your Postfix requires no performance tuning, use it in good health.
> 
> -- 
>   Viktor.

Re: Config check

[Jeroen Geilman]

On 2011-10-27 01:35, IT geek 31 wrote:

I guess what I'm after is a way to whitelist certain senders.  ie. if
they're okay, then no further processing is needed - just deliver.  Is
this possible?  If so, presumably smtpd_sender_restrictions =
check_sender_access hash:/sender_access is the place to put it?


No, since that will only whitelist the sender part; 
smtpd_recipient_restrictions may still reject the message or the 
recipient(s).

Put the sender check in smtpd_recipient_restrictions instead.


--
J.