Re: backwards compatibility of OK in header_checks still needed?

[Magnus Bäck]

On Sunday, March 15, 2009 at 07:13 CET,
 Roger Marquis  wrote:

> Noel Jones wrote:
> 
> > There is no bypass method for header_checks.
> 
> Have you tried a filter action at the beginning of the file?
> Destination can be another postfix instance, another smtpd,
> or a content_filter like amavis or spamd:
> 
>  /^Received: from .*\.mx\.aol.com (.*\.mx\.aol\.com/ FILTER 
>  smtp:[127.0.0.1]:25

That still doesn't bypass the rest of the header checks.

-- 
Magnus Bäck
mag...@dsek.lth.se

Re: backwards compatibility of OK in header_checks still needed?

[mouss]

Henk van Oers a écrit :
> [snip]
>> Doing a proper job requires an external content filter.
> 
> I want to reject as mutch as posible, so i have a header_checks file.
> To bypass the header check for trusted senders i tryed:
>  if /^Return-Path:/
>  /trusted_sender/ OK
>  endif
> 
> As i now understand it, i have to put this header check in a
> separate file and the other header_check file will be ignored.
> Right?
> 
> (and, yes i know, the sender can be spoofed,
> but the spammer will be rejected before the data fase)

There is _no_ _way_ to skip header checks, however creative you can be.

one thing I needed was to be able to do some header checks to reject
some mail, except if it comes from a mailing list or a forwarder. The
solution was to use different domains (@ml.netoyen.net for lists and
another domain for forwarding) which allows setting up different MXs.

Alternatively, you can use a proxy_filter or a milter. you can then use
a stripped down version of spamassassin.

Re: backwards compatibility of OK in header_checks still needed?

[Michael Tokarev]

Bill Cole wrote:

Michael Tokarev wrote, On 3/14/09 4:13 PM:

Henk van Oers wrote:

[...]

I the case of multiple recipients there can be rejects for some,
no tests for some others (OK), a few test for DUNNO recipients
and all the checks for the rest. Right?


Yes.  For each recipient independently.


I don't believe this to be correct.

With SMTP, accepting or rejecting a message based on its content is only 
possible for all recipients. There is no way to respond to the SMTP DATA 
command that expresses different handling for different recipients.


The only place in the SMTP transaction that you can discriminate between 
recipients is the RCPT phase.


This is exactly what I was talking about.

smtpd_recipient_restrictions evaluates AT RCPT TIME (which is the stage in
the smtp transaction when smtpd_recipient_restriction triggers) for EVERY
RECIPIENT, independently.

Analogously to that, header_checks evaluates - AT DATA TIME (which is the
stage in the SMTP transaction where header_checks triggers) for EVERY
HEADER, independently.

I see no contrary in what I said, or, at least, what I were intended to
say.  Do you see it still?

/mjt

Re: backwards compatibility of OK in header_checks still needed?

[Wietse Venema]

Henk van Oers:
> 
> On Sat, 14 Mar 2009, Wietse Venema wrote:
> > Henk van Oers:
> >> 
> >> Quote from header_checks (5):
> >> ""
> >> DUNNO  Pretend  that the input line did not match any pat-
> >>tern, and inspect the next input line. This  action
> >>can be used to shorten the table search.
> >>
> >>For  backwards  compatibility reasons, Postfix also
> >>accepts OK but it is (and always has been)  treated
> >>as DUNNO.
> >> ""
> >> 
> >> I was trying to use action OK to jump out of header checks.
> >> That is: not only skip the next patterns, but also the next
> >> input lines.
> > 
> > According to the above documentation, Postfix does not work that
> > way.
> > 
> > Whitelisting based on a single header line is unsafe.
> 
> I know. spammers can insert/spoof whatever.
> 
> > Doing a proper job requires an external content filter.
> 
> I want to reject as mutch as posible, so i have a header_checks file.
> To bypass the header check for trusted senders i tryed:
>   if /^Return-Path:/
>   /trusted_sender/ OK
>   endif
> 
> As i now understand it, i have to put this header check in a
> separate file and the other header_check file will be ignored.
> Right?

Wrong. Is it so hard to read what the text actually says,
instead of what you want it to say?

Wietse

> (and, yes i know, the sender can be spoofed,
> but the spammer will be rejected before the data fase)
> 
> 

Re: backwards compatibility of OK in header_checks still needed?

[Henk van Oers]

On Sun, 15 Mar 2009, Wietse Venema wrote:


Is it so hard to read what the text actually says,
instead of what you want it to say?


Yes. The semantics differ from what i'm used too in recipient_checks.

Re: smtpd_recipient_restrictions suddenly stopping mail

[Kevin Bailey]

Sahil Tandon wrote:
On Mar 3, 2009, at 1:14 PM, Kevin Bailey  
wrote:



Hiya,

We have had this setting on a mail server for a long time.

smtpd_recipient_restrictions =
permit_sasl_authenticated
reject_non_fqdn_recipient
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
reject_multi_recipient_bounce
reject_non_fqdn_hostname
reject_invalid_hostname
reject_rbl_client bl.spamcop.net
reject_rbl_client sbl.spamhaus.org
reject_rhsbl_sender dsn.rfc-ignorant.org
check_policy_service inet:127.0.0.1:6
permit

Today, about 80% of emails started getting bounced back with:

Action: failed
Status: 5.7.1
Remote-MTA: dns; mail.psctraining.co.uk
Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host
  [80.177.179.85] blocked using bl.spamcop.net

So we commented out the spamcop line...  then we got

Action: failed
Status: 5.7.1
Remote-MTA: dns; mail.psctraining.co.uk
Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host
  [80.177.179.85] blocked using sbl.spamhaus.org


So we commented out the spamhaus line...  then we got

: host 
mail.psctraining.co.uk[217.45.142.233] said:
  554 5.7.1 Service unavailable; Sender address 
[kbai...@freewayprojects.com]

  blocked using dsn.rfc-ignorant.org (in reply to RCPT TO command)


Then we commented out the rfc-ignorant.org line and the mail is 
getting through.  So the restrictions line now looks like:


smtpd_recipient_restrictions =
permit_sasl_authenticated
reject_non_fqdn_recipient
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
reject_multi_recipient_bounce
reject_non_fqdn_hostname
reject_invalid_hostname
# nstone - 03/03/2009
# commented to bypass the blacklists
#  reject_rbl_client bl.spamcop.net
#  reject_rbl_client sbl.spamhaus.org
#  reject_rhsbl_sender dsn.rfc-ignorant.org
check_policy_service inet:127.0.0.1:6
permit



OK.  We don't have full access to the routers etc.  We also can no 
longer access the web interface for their router which is on ports 81 
and 445.


My feeling is that something has changed with their firewall or traffic.

Now, if Postfix can not connect to bl.spamcop.net would it reject the 
mail by default?  Also, to test this connection - what port does 
Postfix try to connect to bl.spamcop.net on? - we could then try 
telnet to test the connection.  Also, what port(s) does 
bl.spamcop.net connect back on?


The RBLs are queried via DNS; you don't 'connect' or 'telnet' to them 
in the conventional sense.  I suspect something has gone awry with 
your DNS resolver.




Thanks for that and the other responses.

We indeed tracked it to DNS problems - in this case the onsite admin 
(who is a Windows only type) had set up a Smoothwall router and we were 
using it as our DNS server.  It seems to have been responding with bad data.


We changed the server to use OpenDNS servers and all's well.

Thanks again for the help.

Kevin

RE: smtpd_recipient_restrictions suddenly stopping mail

[Damon Miller]

> Thanks for that and the other responses.
> 
> We indeed tracked it to DNS problems - in this case the onsite admin
> (who is a Windows only type) had set up a Smoothwall router and we
were
> using it as our DNS server.  It seems to have been responding with bad
> data.
> 
> We changed the server to use OpenDNS servers and all's well.
> 
> Thanks again for the help.
> 
> Kevin

Be careful with OpenDNS:  They return false positives, e.g.:

> www.abcdefghijklmnop12345.com.
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
Name:www.abcdefghijklmnop12345.com
Address:  208.67.217.132

This is intended to direct queries for non-existent URLs to OpenDNS's
servers.  I can't guarantee this will interfere with DNS blacklist
operation, but it may.  The blacklist relies on NXDOMAIN responses to
indicate that a server is "safe".  As a result, you may end up
blacklisting every server on the Internet since OpenDNS will never
indicate a lookup failure.  Perhaps someone else can confirm this.

Damon 

Postfix and Samba best practice

[Kevin Bailey]

Hi,

We have a server which is going to be a Samba file server and a Postfix 
server where the users will access their mail over IMAP.


We normally prefer to use Maildir storage as it seems to be recommended 
over mailbox - for me, for example, I am subscribed to a dozen or so 
lists and have tens if not hundreds of thousands of emails on the 
server.  The combination of Postfix and Courier-imap has worked 
perfectly for a couple of years.


So - in /etc/postfix/main.cf we set

mailbox_command = /usr/bin/procmail -a "$EXTENSION" 
DEFAULT=$HOME/Maildir/ MAILDIR=$HOME/Maildir


to put the mail under my home directory and to enable procmail to work.  
(I can then use procmail to sort mail into subdirectories etc).


Now, if I set up Samba as default on Debian it shares out my home 
directory to Windows clients.  If I allow the viewing of hidden files 
then the .Maildir directory shows up on Windows where it can be explored 
or even deleted.


In my case it's not a problem because I won't (intentionally) delete 
that folder - but we're setting up a server for a client with normal users.


So, we want to separate the Maildir from the directory being shared out 
over Samba.


My question is this:

Is it better to store the mail somewhere else entirely - i.e. 
/var/mail/users or something or a new home directory (/home/mailstorage) 
or something?  In which case how best to set up permissions?  It seems 
that when the mail is stored it gets the username as the owner:group.  
This should mean that logging in over imap should allow that user to 
read/manipulate mail.


Or should I try to share out a different directory via Samba.  I.e. 
Leave the mail in /home/username/.Maildir and get Samba to share out 
/home/username/samba for example?


Obviously, I can bodge this around with permissions etc but would prefer 
any links to best practice so that we can implement the best way on all 
future installs.


BTW - I've (sorry!) cross posted this to the Samba/Postfix list to see 
what both sides say - hope that's OK.


Regards,

Kevin

Re: smtpd_tls_session_cache_database

[LuKreme]

On 14-Mar-2009, at 19:39, Wietse Venema wrote:

LuKreme:

In reading  and all the posts
in the last 15 months with 'smtpd_tls_session_cache_database' in the
subject (all 7 of them!), it is not clear to me how the
smtpd_tls_session_cache_database file is created, or what exactly it
contains. If the file is not present, postfix doesn't create it, but
logs a fatal error.


What are:

- the configuration


# TLS
 smtpd_tls_cert_file = /etc/postfix/server.pem
 smtpd_tls_key_file = $smtpd_tls_cert_file
 smtpd_tls_loglevel = 2 # will drop to 0 or 1 after setup is complete
 smtpd_tls_security_level = may
 smtpd_tls_session_cache_database = btree:$data_directory/ 
smtpd_sessions

 smtpd_tls_session_cache_timeout = 1800s # 30 minutes
 smtpd_starttls_timeout = 90s


- the corresponding error message


postfix/smtpd[67779]: fatal: open database /var/db/postfix/ 
smtpd_sessions.db: No such file or directory



--
Vernon: Now this is the thought that wakes me up in the middle of
the night. That when I get older, these kids are going to take
care of me
Carl: I wouldn't count on it.

Re: backwards compatibility of OK in header_checks still needed?

[Sahil Tandon]

On Mar 15, 2009, at 10:16 AM, Henk van Oers wrote:


On Sun, 15 Mar 2009, Wietse Venema wrote:


Is it so hard to read what the text actually says,
instead of what you want it to say?


Yes. The semantics differ from what i'm used too in recipient_checks.



Shall we close this thread?  header_checks != smtpd_recipient_checks,  
and the functionality of both is explained in the documentation.


--
Sahil Tandon 

Re: smtpd_tls_session_cache_database

[Wietse Venema]

LuKreme:
> On 14-Mar-2009, at 19:39, Wietse Venema wrote:
> > LuKreme:
> >> In reading  and all the posts
> >> in the last 15 months with 'smtpd_tls_session_cache_database' in the
> >> subject (all 7 of them!), it is not clear to me how the
> >> smtpd_tls_session_cache_database file is created, or what exactly it
> >> contains. If the file is not present, postfix doesn't create it, but
> >> logs a fatal error.
> >
> > What are:
> >
> > - the configuration
> 
> # TLS
>   smtpd_tls_cert_file = /etc/postfix/server.pem
>   smtpd_tls_key_file = $smtpd_tls_cert_file
>   smtpd_tls_loglevel = 2 # will drop to 0 or 1 after setup is complete
>   smtpd_tls_security_level = may
>   smtpd_tls_session_cache_database = btree:$data_directory/ 
> smtpd_sessions
>   smtpd_tls_session_cache_timeout = 1800s # 30 minutes
>   smtpd_starttls_timeout = 90s

Please stop wasting everyone's time and SHOW ACTUAL "postconf -n"
output, instead of what you believe was the configuration when you
made your mistake.

> > - the corresponding error message
> 
> postfix/smtpd[67779]: fatal: open database /var/db/postfix/ 
> smtpd_sessions.db: No such file or directory

smtpd never uses the smtpd_tls_session_cache_database setting.
You have that file configured via some other main.cf parameter.

Wietse

Re: smtpd_recipient_restrictions suddenly stopping mail

[Sahil Tandon]

On Mar 15, 2009, at 11:27 AM, Damon Miller wrote:


We changed the server to use OpenDNS servers and all's well.

Thanks again for the help.


Be careful with OpenDNS:  They return false positives, e.g.:


www.abcdefghijklmnop12345.com.

Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
Name:www.abcdefghijklmnop12345.com
Address:  208.67.217.132

This is intended to direct queries for non-existent URLs to OpenDNS's
servers.  I can't guarantee this will interfere with DNS blacklist
operation, but it may.  The blacklist relies on NXDOMAIN responses to
indicate that a server is "safe".  As a result, you may end up
blacklisting every server on the Internet since OpenDNS will never
indicate a lookup failure.  Perhaps someone else can confirm this.


Noel already addressed this false concern:

   http://marc.info/?l=postfix-users&m=123612736717968&w=2

OpenDNS will not blindly redirect DNS queries that look like DNSBL  
requests.  Notice the difference:


   % dig @resolver1.opendns.com www.abcdefghijklmnop12345.com +short
   208.69.32.132
   % dig @resolver1.opendns.com 40.30.20.10.www.abcdefghijklmnop12345.com 
 +short

   %

--
Sahil Tandon 

Re: smtpd_recipient_restrictions suddenly stopping mail

[Wietse Venema]

Sahil Tandon:
> OpenDNS will not blindly redirect DNS queries that look like DNSBL  
> requests.  Notice the difference:
> 
> % dig @resolver1.opendns.com www.abcdefghijklmnop12345.com +short
> 208.69.32.132
> % dig @resolver1.opendns.com 40.30.20.10.www.abcdefghijklmnop12345.com 
>   +short
> %

Note, this still breaks lookups of rfc-ignorant.org and other sites
that blacklist domain names instead of IP addresses.

If you must run an MX host, use a real DNS server.

Wietse

Re: smtpd_recipient_restrictions suddenly stopping mail

[Sahil Tandon]

On Sun, 15 Mar 2009, Wietse Venema wrote:

> Sahil Tandon:
> > OpenDNS will not blindly redirect DNS queries that look like DNSBL  
> > requests.  Notice the difference:
> > 
> > % dig @resolver1.opendns.com www.abcdefghijklmnop12345.com +short
> > 208.69.32.132
> > % dig @resolver1.opendns.com 40.30.20.10.www.abcdefghijklmnop12345.com 
> >   +short
> > %
> 
> Note, this still breaks lookups of rfc-ignorant.org and other sites
> that blacklist domain names instead of IP addresses.

FWIW, OpenDNS appears to work with rfc-ignorant.org, but that's only because
they know about it: http://www.opendns.com/support/article/33

> If you must run an MX host, use a real DNS server.

Agreed!

-- 
Sahil Tandon 

Re: smtpd_tls_session_cache_database

[Victor Duchovni]

On Sun, Mar 15, 2009 at 12:27:37PM -0400, Wietse Venema wrote:

> >   smtpd_tls_session_cache_database = btree:$data_directory/smtpd_sessions
> > 
> > postfix/smtpd[67779]: fatal: open database /var/db/postfix/ 
> > smtpd_sessions.db: No such file or directory
> 
> smtpd never uses the smtpd_tls_session_cache_database setting.
> You have that file configured via some other main.cf parameter.

Indeed this file is managed by trivial-rewrite(8), not smtpd(8).
Perhaps the OP is trying to this file as access table? In any case
no official Postfix release with TLS (2.2 or later) has smtpd(8)
accessing the cache directly.

-- 
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: smtpd_recipient_restrictions suddenly stopping mail

[Noel Jones]

Sahil Tandon wrote:

On Sun, 15 Mar 2009, Wietse Venema wrote:


Sahil Tandon:
OpenDNS will not blindly redirect DNS queries that look like DNSBL  
requests.  Notice the difference:


% dig @resolver1.opendns.com www.abcdefghijklmnop12345.com +short
208.69.32.132
% dig @resolver1.opendns.com 40.30.20.10.www.abcdefghijklmnop12345.com 
  +short

%

Note, this still breaks lookups of rfc-ignorant.org and other sites
that blacklist domain names instead of IP addresses.


FWIW, OpenDNS appears to work with rfc-ignorant.org, but that's only because
they know about it: http://www.opendns.com/support/article/33


If you must run an MX host, use a real DNS server.


Agreed!



If you sign up for a free account at OpenDNS you can turn off 
their helpful typo-correction feature.


Then OpenDNS works splendidly on an MX.
They do have a clue.

  -- Noel Jones

Re: non-alpha HELO

[LuKreme]

On 14-Mar-2009, at 22:53, Noel Jones wrote:
But you should really be testing with telnet and openssl s_client  
before you start testing with a MUA.


Yep. Like I said this was just a "let's see what we get in the logs"  
little test.  Mucking about some more with it, TLS at least is working  
now.


Authentication is another matter, but as I recall, that is outside  
postfix purview and I need to go dink with cyrus-sasl-saslauthd for  
that.


Mar 15 12:54:40 mail submit/smtpd[7403]: Anonymous TLS connection  
established from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]:  
TLSv1 with cipher AES128-SHA (128/128 bits)
Mar 15 12:54:41 mail submit/smtpd[7403]: warning: SASL authentication  
failure: no user in db


And I'm also seeing successful TLS connections with other mailservers.

So, postfix config is done.

--
The Steve is seen, rightly or wrongly, as the visionary, the
leader, the savant. Bill is the Boswell to The Steve's Johnson,
but lacking Boswell's wit, charm, and dynamic personality.

Re: non-alpha HELO

[Noel Jones]

LuKreme wrote:
Authentication is another matter, but as I recall, that is outside 
postfix purview and I need to go dink with cyrus-sasl-saslauthd for that.


Mar 15 12:54:40 mail submit/smtpd[7403]: Anonymous TLS connection 
established from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: 
TLSv1 with cipher AES128-SHA (128/128 bits)
Mar 15 12:54:41 mail submit/smtpd[7403]: warning: SASL authentication 
failure: no user in db


And I'm also seeing successful TLS connections with other mailservers.


Yes, it appears your TLS is working correctly.

You may start a new thread here about your AUTH failures. 
Include "postconf -n" and output from the saslfinger tool.


  -- Noel Jones

Re: backwards compatibility of OK in header_checks still needed?

[Roger Marquis]

Magnus wrote:

 /^Received: from .*\.mx\.aol.com (.*\.mx\.aol\.com/ FILTER
 smtp:[127.0.0.1]:25

That still doesn't bypass the rest of the header checks.


Works for us, has for years.  Even tested it using the exact same pattern
and HOLD immediately after the FILTER.  The messages are delivered as per
usual never hitting the hold rule.

This is how we accept spam reports from external clients without having to
setup yet another postfix instance.

Try it.

Roger Marquis

Re: backwards compatibility of OK in header_checks still needed?

[Magnus Bäck]

On Sunday, March 15, 2009 at 21:59 CET,
 Roger Marquis  wrote:

> Magnus wrote:
>
> > That still doesn't bypass the rest of the header checks.
>
> Works for us, has for years.  Even tested it using the exact same
> pattern and HOLD immediately after the FILTER.  The messages are
> delivered as per usual never hitting the hold rule.

This is because a single header line is only matched against the lookup
table once. In other words, if a line matches two expressions in the
file only the action of the first expression will ever be processed.

> This is how we accept spam reports from external clients without
> having to setup yet another postfix instance.

How, exactly, are you accomplishing this?

-- 
Magnus Bäck
mag...@dsek.lth.se

Re: smtpd_tls_session_cache_database

[LuKreme]

On 15-Mar-2009, at 14:25, Victor Duchovni wrote:


On Sun, Mar 15, 2009 at 12:27:37PM -0400, Wietse Venema wrote:

 smtpd_tls_session_cache_database = btree:$data_directory/ 
smtpd_sessions


postfix/smtpd[67779]: fatal: open database /var/db/postfix/
smtpd_sessions.db: No such file or directory


smtpd never uses the smtpd_tls_session_cache_database setting.
You have that file configured via some other main.cf parameter.


Indeed this file is managed by trivial-rewrite(8), not smtpd(8).
Perhaps the OP is trying to this file as access table? In any case
no official Postfix release with TLS (2.2 or later) has smtpd(8)
accessing the cache directly.


There was a leading space on the smtpd_tls* lines, so they got glommed  
onto the previous statement (smtpd_sender_restrictions).


I can connect now to the submission port from my MUA (mail.app) as  
long as I authenticate against the sasldb.  I cannot connect from the  
command-line with openssl s_client:


$ openssl s_client -connect mail.covisp.net:587
CONNECTED(0003)
4001:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown  
protocol:s23_clnt.c:601:


but from Mail.app:

CONNECTED Mar 15 15:21:03.180 [kCFStreamSocketSecurityLevelNone]  --  
host:mail.covisp.net -- port:587 -- socket:0x30226650 -- thread: 
0x326adb70


READ Mar 15 15:21:03.247 [kCFStreamSocketSecurityLevelNone]  --  
host:mail.covisp.net -- port:587 -- socket:0x30226650 -- thread: 
0x326adb70

220 mail.covisp.net ESMTP Postfix 2.5.6

etc.  I wonder at the SecurityLevelNone, but there is:

WROTE Mar 15 15:22:03.909 [kCFStreamSocketSecurityLevelNegotiatedSSL]   
-- host:mail.covisp.net -- port:993 -- socket:0x1eb59230 -- thread: 
0x3542dc40

1.251 LOGIN user 

READ Mar 15 15:22:03.951 [kCFStreamSocketSecurityLevelNegotiatedSSL]   
-- host:mail.covisp.net -- port:993 -- socket:0x1eb59230 -- thread: 
0x3542dc40

1.251 OK LOGIN Ok.

with

submission   inet  n   -   n   -   -   smtpd
  -o smtpd_enforce_tls=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o syslog_name=submit


Also, changing the password or login causes it to fail, so it is  
working from the MUA, just not from the CLI. Of course, I need it to  
authenticate against the postfixadmin sql database instead (and PAM),  
but that is an issue for a different list.



--
I do believe Marsellus Wallace, my husband, your boss, told you to
take *me* out and do *whatever I wanted*. Now I wanna dance, I
wanna win. I want that trophy, so dance good.

Re: backwards compatibility of OK in header_checks still needed?

[Noel Jones]

Roger Marquis wrote:

Magnus wrote:

 /^Received: from .*\.mx\.aol.com (.*\.mx\.aol\.com/ FILTER
 smtp:[127.0.0.1]:25

That still doesn't bypass the rest of the header checks.


Works for us, has for years.  Even tested it using the exact same pattern
and HOLD immediately after the FILTER.  The messages are delivered as per
usual never hitting the hold rule.

This is how we accept spam reports from external clients without having to
setup yet another postfix instance.

Try it.


The FILTER action doesn't take effect until after the mail has 
been queued, so no, it doesn't bypass header_checks.


In the header_checks file FILTER has the same effect as DUNNO; 
further checks on THAT HEADER are skipped.  In your example 
HOLD matching on the same input would not be reached.  Try:

/^Received.../ FILTER foo:
/./ HOLD
and see what happens (assuming some non-Received: headers).

There is no bypass mechanism for header_checks.



  -- Noel Jones

Issue with pipe mail to script

[Simon]

Hi There, We are running postfix on debian etch and are using mysql to
store the transport and alias info and having an issue that i need a
little assistance with please. Here is the config:

mydestination = mysql:/etc/postfix/mysql-transport.cf
transport_maps = mysql:/etc/postfix/mysql-transport.cf
virtual_alias_maps=mysql:/etc/postfix/mysql-aliases.cf

Here are the config files:

mail-in1:/etc/postfix# cat mysql-aliases.cf
user = mail-in1
password = password
hosts = 210.xx.xx.xxx
dbname = postfix
table = aliases
select_field = destination_address
where_field = origin_address

mail-in1:/etc/postfix# cat mysql-transport.cf
user = mail-in1
password = password
dbname = postfix
table = transport
hosts = 210.xx.xx.xxx
select_field = transport
where_field = domain

So, in the transport table we have:

domain = testdomain.co.nz
transport = dbmail-lmpt:210.xx.xx.xxx:24

and in the alises table we have:

orgin_address = t...@testdomain.co.nz
destination_address = t...@testdomain.co.nz

Now - this works fine.. But as soon as i add a pipe to the
destination_address like this:

orgin_address = t...@testdomain.co.nz
destination_address = |/usr/local/autoresponder/autoresponder.php

Then we get the following:

Mar 16 11:19:41 mail-in1 amavis[1100]: (01100-07) FWD via SMTP:
 ->
<|/usr/local/autoresponder/autoresponder@mail-in1>, 250 2.6.0 Ok,
id=01100-07, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as
3397D482CD
Mar 16 11:19:41 mail-in1 postfix/smtpd[31965]: disconnect from
localhost[127.0.0.1]
Mar 16 11:19:41 mail-in1 postfix/smtpd[31660]: connect from localhost[127.0.0.1]
Mar 16 11:19:41 mail-in1 postfix/smtpd[31660]: 413D048303:
client=localhost[127.0.0.1]
Mar 16 11:19:41 mail-in1 postfix/qmgr[7588]: 3397D482CD:
from=, size=4776, nrcpt=1 (queue active)
Mar 16 11:19:41 mail-in1 postfix/smtpd[1092]: connect from localhost[127.0.0.1]
Mar 16 11:19:41 mail-in1 postfix/smtpd[1092]: NOQUEUE: reject: RCPT
from localhost[127.0.0.1]: 550 5.1.1
<|/usr/local/autoresponder/autoresponder@mail-in1>: Recipient
address rejected: User unknown in local recipient table;
from=
to=<|/usr/local/autoresponder/autoresponder@mail-in1> proto=ESMTP
helo=
Mar 16 11:19:41 mail-in1 postfix/smtp[1096]: 3397D482CD:
to=<|/usr/local/autoresponder/autoresponder@mail-in1>,
relay=127.0.0.1[127.0.0.1]:587, delay=0.07, delays=0.06/0/0/0.01,
dsn=5.1.1, status=bounced (host 127.0.0.1[127.0.0.1] said: 550 5.1.1
<|/usr/local/autoresponder/autoresponder@mail-in1>: Recipient
address rejected: User unknown in local recipient table (in reply to
RCPT TO command))

Can someone please assist with this issue?

Thanks

Simon

Re: backwards compatibility of OK in header_checks still needed?

[mouss]

Sahil Tandon a écrit :
> On Mar 15, 2009, at 10:16 AM, Henk van Oers wrote:
> 
>> On Sun, 15 Mar 2009, Wietse Venema wrote:
>>
>>> Is it so hard to read what the text actually says,
>>> instead of what you want it to say?
>>
>> Yes. The semantics differ from what i'm used too in recipient_checks.
> 
> 
> Shall we close this thread?  header_checks != smtpd_recipient_checks,
> and the functionality of both is explained in the documentation.
> 

smtpd_recipient_checks? what's that?
just kidding of course...

Re: Issue with pipe mail to script

[Wietse Venema]

Simon:
> Hi There, We are running postfix on debian etch and are using mysql to
> store the transport and alias info and having an issue that i need a
> little assistance with please. Here is the config:
> 
> mydestination = mysql:/etc/postfix/mysql-transport.cf
> transport_maps = mysql:/etc/postfix/mysql-transport.cf
> virtual_alias_maps=mysql:/etc/postfix/mysql-aliases.cf

As documented you can't have commands in virtual alias maps.

To execute commands, see http://www.postfix.org/VIRTUAL_README.html

Wietse

Re: backwards compatibility of OK in header_checks still needed?

[Sahil Tandon]

On Sun, 15 Mar 2009, mouss wrote:

> Sahil Tandon a écrit :
> > On Mar 15, 2009, at 10:16 AM, Henk van Oers wrote:
> > 
> >> On Sun, 15 Mar 2009, Wietse Venema wrote:
> >>
> >>> Is it so hard to read what the text actually says,
> >>> instead of what you want it to say?
> >>
> >> Yes. The semantics differ from what i'm used too in recipient_checks.
> > 
> > 
> > Shall we close this thread?  header_checks != smtpd_recipient_checks,
> > and the functionality of both is explained in the documentation.
> > 
> 
> smtpd_recipient_checks? what's that?
> just kidding of course...

Mea culpa!  smtpd_recipient_restrictions! :-)

-- 
Sahil Tandon 

Re: backwards compatibility of OK in header_checks still needed?

[mouss]

Roger Marquis a écrit :
> Magnus wrote:
>>>  /^Received: from .*\.mx\.aol.com (.*\.mx\.aol\.com/ FILTER
>>>  smtp:[127.0.0.1]:25
>> That still doesn't bypass the rest of the header checks.
> 
> Works for us, has for years. 

does it have a green card? otherwise, "it" shouldn't work ;-p

> Even tested it using the exact same pattern
> and HOLD immediately after the FILTER.  The messages are delivered as per
> usual never hitting the hold rule.
> 
> This is how we accept spam reports from external clients without having to
> setup yet another postfix instance.
> 

whatever you may think, it doesn't work the way you think.

> Try it.

there's no need to try. it woks as documented, and the documentation is
clear: header_checks work on individual headers, one at a time, and the
result doesn't influence other header checks.

Re: Postfix and Samba best practice

[mouss]

Kevin Bailey a écrit :
> Hi,
> 
> We have a server which is going to be a Samba file server and a Postfix
> server where the users will access their mail over IMAP.
> 
> We normally prefer to use Maildir storage as it seems to be recommended
> over mailbox - for me, for example, I am subscribed to a dozen or so
> lists and have tens if not hundreds of thousands of emails on the
> server.  The combination of Postfix and Courier-imap has worked
> perfectly for a couple of years.
> 
> So - in /etc/postfix/main.cf we set
> 
> mailbox_command = /usr/bin/procmail -a "$EXTENSION"
> DEFAULT=$HOME/Maildir/ MAILDIR=$HOME/Maildir
> 

since you're using courier, why not use maildrop instead of the procmail?

> to put the mail under my home directory and to enable procmail to work. 
> (I can then use procmail to sort mail into subdirectories etc).
> 
> Now, if I set up Samba as default on Debian it shares out my home
> directory to Windows clients.  If I allow the viewing of hidden files
> then the .Maildir directory shows up on Windows where it can be explored
> or even deleted.
> 
> In my case it's not a problem because I won't (intentionally) delete
> that folder - but we're setting up a server for a client with normal users.
> 
> So, we want to separate the Maildir from the directory being shared out
> over Samba.
> 
> My question is this:
> 
> Is it better to store the mail somewhere else entirely - i.e.
> /var/mail/users or something or a new home directory (/home/mailstorage)
> or something?  In which case how best to set up permissions?  It seems
> that when the mail is stored it gets the username as the owner:group. 
> This should mean that logging in over imap should allow that user to
> read/manipulate mail.
> 

if you don't want the mail to belong to users, use virtual.
alternatively, configure procmail/maildrop to put mail in a place that
users don't "naturally" see.

> Or should I try to share out a different directory via Samba.  I.e.
> Leave the mail in /home/username/.Maildir and get Samba to share out
> /home/username/samba for example?
> 

no. if you share the homedir, share the homedir. if mail shouldn't be
shared, put it somewhere else.

> Obviously, I can bodge this around with permissions etc but would prefer
> any links to best practice so that we can implement the best way on all
> future installs.

Re: Issue with pipe mail to script

[Sahil Tandon]

On Mon, 16 Mar 2009, Simon wrote:

> Now - this works fine.. But as soon as i add a pipe to the
> destination_address like this:
> 
> orgin_address = t...@testdomain.co.nz
> destination_address = |/usr/local/autoresponder/autoresponder.php

For security reasons, virtual(8) does not support delivery to "|command".
See: http://www.postfix.org/VIRTUAL_README.html#autoreplies.

-- 
Sahil Tandon 

Re: smtpd_tls_session_cache_database

[mouss]

LuKreme a écrit :
>
> I can connect now to the submission port from my MUA (mail.app) as long
> as I authenticate against the sasldb.  I cannot connect from the
> command-line with openssl s_client:

no you can't. which is why Noel added "connectivity" to his
recommendation. only use openssl to see what postfix would do for a
STARTTLS. nothing more.

Re: smtpd_tls_session_cache_database

[Victor Duchovni]

On Sun, Mar 15, 2009 at 03:32:26PM -0600, LuKreme wrote:

> $ openssl s_client -connect mail.covisp.net:587
> CONNECTED(0003)
> 4001:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown 
> protocol:s23_clnt.c:601:

This is SMTP inside SSL, Postfix does STARTTLS inside SMTP, so this
is not the right command-line. Try:

openssl s_client -starttls smtp -connect mail.covisp.net:587

-- 
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: smtpd_tls_session_cache_database

[LuKreme]

On 15-Mar-2009, at 17:08, mouss wrote:

LuKreme a écrit :
I can connect now to the submission port from my MUA (mail.app) as  
long

as I authenticate against the sasldb.  I cannot connect from the
command-line with openssl s_client:


no you can't. which is why Noel added "connectivity" to his
recommendation. only use openssl to see what postfix would do for a
STARTTLS. nothing more.


Figured that out right after sending last.  Everything works in  
postfix right now as it is.  I am only able to auth against the salsdb  
with


$  cat smtpd.conf
pwcheck_method: auxprop
mech_list: PLAIN LOGIN

Any changes I've tried to make to that file so far have failed, so I  
need to read up on cyrus-sasl-2.1.22 and figure out why it doesn't  
work for...


Oh, hang on, I think cyrus-sasl was not built with mysql support.   
Recompiling now, I bet that will sort it.


--
Well I've seen the Heart of Darkness/Read the writing on the
wall/an the voice out in the desert/Was the voice out in the
hall

Re: backwards compatibility of OK in header_checks still needed?

[Roger Marquis]

mouss a ecrit : 

whatever you may think, it doesn't work the way you think


You're right, my mistake.  Apologies.  Chalk up another one for quick and
dirty QA.  At least FILTER bypasses the content_filter so won't be
DISCARDed on that basis.

Roger Marquis

Re: READMEs, where can I find them?

[KLaM Postmaster]

Wietse Venema wrote:
> KLaM Postmaster:
>   
>> where can I find the postfix readme files, I have looked all over the
>> postfix.com site, and while there is lots of documentation (man pages,
>> how to, faqs, etc) but  I cannot find the readme files except as
>> embedded links.
>> 
>
> The files are installed here:
>
> $ postconf readme_directory
> $ postconf html_directory
>
> These are the same files as on the web.
>
>   Wietse
>
>   
>> Is the a directory or something that contains just the readme files.
>> My particular interest is in configuring the master.cf, I have read the
>> master and the master.cf man pages, but I am looking for advise on how
>> to configure services like smpts, submission etc.
>>
>> TIA
>> JLA
>> 
I had seen a reference to a master.cf readme, but when took a look in
the doc directory on my system and did not find it. So i was looking to
see if there was another place that might have the readme files, my
interest was sparked by the non-alpha thread that is going on on this list.
thanks anyway
JLA

Too strict?

[Alberto Lepe]

Hello, and thank you in advance for your time!

I have been setting up a mail server since more than a week and after
reading several posts/articles and some pages of the Postfix manual,
I'm a little confused about how to setup the security.
The mail server is outside my LAN and it will be used to serve some
domains, with maybe 10 users per domain.

This is my main.cf (restrictions):

smtpd_data_restrictions = reject_unauth_pipelining
smtpd_recipient_restrictions =
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 permit_mynetworks,
 permit_sasl_authenticated,
# reject_unknown_sender_domain,
# reject_unknown_recipient_domain,
 reject_unauth_destination,
 reject_invalid_helo_hostname,
 reject_unlisted_recipient,
 reject_unlisted_sender,
 reject_invalid_hostname,
#   reject_non_fqdn_hostname,
#   reject_unknown_client_hostname,
 reject_rbl_client zen.spamhaus.org,
 reject_rbl_client bl.spamcop.net,
permit

I commented those lines after reading in this mailing list that was
not a good idea for a mail server that will receive/send mails from
internet.

I wanted to force the users to authenticate, in order to send mails, with:

#smtpd_client_restrictions = permit_sasl_authenticated,reject

But for some reason, when I use that line, and I send a mail from
gmail to one of the test accounts, it is bounced with an "Client host
rejected: Access denied" error.
I thought it was only for those wishing to use the SMTP server for
sending emails... but it is not... right?

So, what I don't understand about the restrictions is:

If I don't include the "smtpd_client_restrictions =
permit_sasl_authenticated,reject" line,
anyone can use my SMTP to send emails without authentication if it is
not rejected by other rules (e.g., reject_unlisted_sender, etc.)

Even with " smtpd_client_restrictions" rule, If I use that server as
SMTP server, I can send an email to a local account:
(t...@myhostname.com) without authentication! (and outside
mynetworks). Why is that possible?

Thank you!

Re: Too strict?

[Magnus Bäck]

On Monday, March 16, 2009 at 06:18 CET,
 Alberto Lepe  wrote:

[...]

> I wanted to force the users to authenticate, in order to send mails, with:
> 
> #smtpd_client_restrictions = permit_sasl_authenticated,reject
> 
> But for some reason, when I use that line, and I send a mail from
> gmail to one of the test accounts, it is bounced with an "Client host
> rejected: Access denied" error.
> I thought it was only for those wishing to use the SMTP server for
> sending emails... but it is not... right?

Postfix doesn't know why the client is connecting. As far as it's
concerned, Gmail is also "sending" email. Postfix is doing exactly
what you're telling it to do -- permit authenticated clients and
rejecting the rest.

> So, what I don't understand about the restrictions is:
> 
> If I don't include the "smtpd_client_restrictions =
> permit_sasl_authenticated,reject" line,
> anyone can use my SMTP to send emails without authentication if it is
> not rejected by other rules (e.g., reject_unlisted_sender, etc.)

Yes, but only to domains hosted by your Postfix. How would you otherwise
receive email from e.g. Gmail?

> Even with " smtpd_client_restrictions" rule, If I use that server as
> SMTP server, I can send an email to a local account:
> (t...@myhostname.com) without authentication! (and outside
> mynetworks). Why is that possible?

No, that's incorrect. With

   smtpd_client_restrictions = permit_sasl_authenticated,reject

in main.cf only authenticated clients will be allowed to do anything.

Put the permit_sasl_authenticated stuff in smtpd_recipient_restrictions
instead, along with permit_mynetworks. Relay access control takes place
in smtpd_recipient_restrictions.

-- 
Magnus Bäck
mag...@dsek.lth.se