Re: Client Certificate Authentication for Auth Only

[Bill Cole]

On 1 Feb 2016, at 13:39, Haravikk wrote:


Hi there,

I’m trying to configure client certificate authentication such that 
it is only required for users (with valid username/password) when 
sending e-mail *from* my mail server.


However, setting smtpd_tls_req_ccert = yes causes postfix to request a 
certificate from all incoming connections, including mail servers that 
are attempting to deliver mail.


Is there a way to enable client certificates only for auth 
connections? I’ve already set smtpd_tls_auth_only = yes, but I’m 
not sure how to enable client certificates only for senders, without 
causing incoming messages to also be blocked.


Modern best practice for Internet email is to split mail transport and 
initial message submission into distinct services: SMTP (RFC5321 and its 
ancestors) on TCP port 25 and Message Submission (RFC6409 and its 
ancestors) on port 587. If you do this, you can require certificates for 
the port 587 submission service and not for the port 25 SMTP service. In 
many cases (i.e. if not providing authenticated relay for mail submitted 
elsewhere) a system with independent transport and submission services 
need not allow authentication at all on the port 25 service.

Re: Client Certificate Authentication for Auth Only

[Christian Kivalo]

On 2016-02-01 19:39, Haravikk wrote:

Hi there,

Hi,

I’m trying to configure client certificate authentication such that it
is only required for users (with valid username/password) when sending
e-mail *from* my mail server.

Where do you set it?

However, setting smtpd_tls_req_ccert = yes causes postfix to request a
certificate from all incoming connections, including mail servers that
are attempting to deliver mail.

Is there a way to enable client certificates only for auth
connections? I’ve already set smtpd_tls_auth_only = yes, but I’m not
sure how to enable client certificates only for senders, without
causing incoming messages to also be blocked.
When you set it in master.cf only for the submission service it's only 
required for clients connecting to port 587.

Connections to port 25 are not required to present a client cert.


Thanks,
Haravikk


--
Christian

Re: Client Certificate Authentication for Auth Only

[Noel Jones]

On 2/1/2016 12:39 PM, Haravikk wrote:
> Hi there,
> 
> I’m trying to configure client certificate authentication such that it is 
> only required for users (with valid username/password) when sending e-mail 
> *from* my mail server.
> 
> However, setting smtpd_tls_req_ccert = yes causes postfix to request a 
> certificate from all incoming connections, including mail servers that are 
> attempting to deliver mail.
> 
> Is there a way to enable client certificates only for auth connections? I’ve 
> already set smtpd_tls_auth_only = yes, but I’m not sure how to enable client 
> certificates only for senders, without causing incoming messages to also be 
> blocked.
> 
> Thanks,
> Haravikk
> 

The TLS connection happens well before postfix knows if the client
intends to send AUTH, so what you ask is not possible.

This is why it's recommended to enable AUTH only on port 587
submission, and not on the general-use port 25 smtpd.

If you restrict AUTH to only port 587, it's easy to add "-o
smtpd_tls_req_ccert=yes" to the master.cf submission entry.



  -- Noel Jones

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

[Curtis Villamizar]

In message <211281bd-f686-4a8a-9e37-7d4368568...@kreme.com>
LuKreme writes:
 
> On Jan 30, 2016, at 22:42, Curtis Villamizar  wrote:
> > It would be:
> > 
> >  cd /usr/local/etc
> >  mv postfix postfix.old
> >  ln -s ../../../etc/postfix postfix
>  
> No, it most certainly would not. Your configuration files ARE in
> local, if you want to pretend they are in /etc, then create a link in
> etc.  I've done this for years. Works just fine.
>  
> > And yes I did try that.
>  
> And what you tried will not work.


Not to further beat a dead horse but ...

We're not talking about configuring one host, though I try things out
on a single host by hand edits first.

I generate configs and have have tools to rebuild any host from
scratch in a single command line, compare all configs on a running
host to updated config templates, etc.  So I have to change some path
names in config templates and roll out changes.  No big deal but a
"ln -s" command isn't going to do the trick.

As I said to Viktor, I mistakenly thought, based on reading (maybe
misreading) numerous web pages of documentation with no mention of a
limitation, that the -c argument was supposed to work like -c or -cf
in any other package.  Now I know that it doesn't.

Peace,

Curtis

Re: local delivery, alias expansion, and subdomain matches

[Curtis Villamizar]

In message <2a0d3251-10a1-4903-8689-2d190e144...@dukhovni.org>
Viktor Dukhovni writes:
 
> > On Jan 30, 2016, at 8:03 PM, Curtis Villamizar  
> > wrote:
> > 
> > I'm asking a little advice.
> > 
> > On most of my hosts mail is generated for root and then canonicaled to
> > root@fqdn and is relayed to the MSA on another host.  This is by
> > design.
> > 
> >  relayhost = msa-fqdn
> > 
> > There is an alias on the originating host for root but it doesn't seem
> > to expand there.  If that could be fixed, then the rest doesn't matter.
>  
> Aliasing root on null-clients is explained in:
>  
>http://www.postfix.org/MULTI_INSTANCE_README.html#split

OK.  This

> Perhaps STANDARD_CONFIGURATION_README.html should also cover this.
>  
>http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client

Null client seems good for web servers and other servers not involved
in forwarding or delivering email.  Thanks.  I'll need more config
since the MSA will want a client cert and sasl-auth.

btw- BSD jails don't have a loopback, only numbered interfaces.
Would than mean using "inet_interfaces = " (empty).

> That example is at present more minimal, but global recipient aliasing
> via virtual(5) is covered in ADDRESS_REWRITING_README.html:
>  
>http://www.postfix.org/ADDRESS_REWRITING_README.html#receiving
>http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual

I saw this but I'm not sure I got the config quite right.

I think what I need is:

  #  destination domains and virtual alias domains
  mydestination = hash:$config_directory/my-domains
  remote_destination = pcre:$config_directory/pcre-domains
  virtual_alias_domains = $mydestination $remote_destination
  #  local users (comment out if empty) and virtual alias users
  #local_alias_maps = hash:$config_directory/local-aliases
  remote_alias_maps = hash:$config_directory/remote-aliases
  alias_database = $local_alias_maps $remote_alias_maps
  alias_maps = $local_alias_maps
  virtual_alias_maps = $remote_alias_maps
  local_recipient_maps = hash:$config_directory/local-users

  local-aliases:
(remove root, spam, ..., anything mapping to root, spam, ...)
(strictly local aliases - none in my case)
  remote-aliases:
root: ad...@some.where.tld
spam: spam.catc...@some.where.tld
...
(anything mapping to root, spam, ...)

Note: local-users matches the recipients known to cyrus imapd.

(and of course config_directory = /usr/local/etc/postfix).

Since the goal is to catch root@*.domain.tld by using the bare word
root on the lhs in remote-aliases and a pcre to put *.domain.tld in
virtual_alias_domains this should work.  Me thinks.

I think this will work and will try it when I get a chance (on a test
domain first).  Unless someone tells me it won't work.

> -- 
>   Viktor.

Curtis


btw- I think this would also be doable in sendmail address rewriting
rules (just about any rewrite is doable) but like writing assembly
language code, I'd rather not be pursuing such a solution.

Re: postfix to mailman: User doesn't exist/relay access denied

[wilfried.es...@essignetz.de]

Hi Walter,


would suggest to expand "mydestination" by "lists.ifkuk.org".



Willi


Am 01.02.2016 um 00:21 schrieb wal...@ifkuk.org:
> Hey guys
> 
> since three days I am stuck with a problem and it seems to me I am blind
> for the solution by digging
> into it so much, so I need your help to have a look at it please!
> 
> our server is up and running dovecot/postfix on debian 8 for three years
> by now, without any problems.
> 
> I urgently needed to set up some mailinglists and choose mailman for it
> (what else?).
> 
> I thought everything went fine till I tried to test my installation and
> discovered that,
> when I try to send from an internal emailaddress (managed by the server
> itself) I get an
> "User doesn't exist" error and if I send an email from an external
> service like gmail,
> I get "relay access denied".
> 
> Like I've said, I tried to fix this problem for over three days now and
> can't see my mistake.
> 
> I uploaded my config files at HowtoForge, where you can have a look at it:
> https://www.howtoforge.com/community/threads/postfix-mailman-debian8.72052/
> 
> 
> Greetings and thank you in advance for your help
> Walter
> 

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

[Curtis Villamizar]

In message <5a7fbd95-2256-4177-a30d-32e36ea73...@dukhovni.org>
Viktor Dukhovni writes:
 
> > On Feb 1, 2016, at 3:54 AM, Curtis Villamizar  
> > wrote:
> > 
> > As I said to Viktor, I mistakenly thought, based on reading (maybe
> > misreading) numerous web pages of documentation with no mention of a
> > limitation, that the -c argument was supposed to work like -c or -cf
> > in any other package.  Now I know that it doesn't.
>  
> The "-c" argument absolutely works, but makes no promise that having
> problematic settings in the default configuration directory will not
> log any warnings.

It doesn't give any warnings in the manual pages or in
http://www.postfix.org/postconf.5.html#config_directory
Maybe it should.

The entire content is:

  config_directory (default: see "postconf -d" output)

The default location of the Postfix main.cf and master.cf
configuration files. This can be overruled via the following
mechanisms:

The MAIL_CONFIG environment variable (daemon processes and
commands).

The "-c" command-line option (commands only).

With Postfix command that run with set-gid privileges, a
config_directory override requires either root privileges, or it
requires that the directory is listed with the
alternate_config_directories parameter in the default main.cf
file.

As you can see - no warning.

> The default configuration directory is used to determine whether the
> target of the "-c" option is a secondary instance in a single command
> in the start-up shell script.  The lookup of just that single parameter
> happens to trigger a warning on your partly configured system.

Perhaps put something like this in
http://www.postfix.org/postconf.5.html#config_directory
except use the phrase "compiled in default configuration directory".
And the put in each manual page -c description "See limitation
described in config_directory main.cf option".

> For some reason you seem to have gotten rather worked up about a nit
> that really does not warrant the bother.  Most people find it easier
> to either compile with the preferred default, or use the default that's
> compiled-in, and not have to use explicit "-c" options all the time.

I started by asking a question which was phrased (sic) "is this a
bug".  Sorry.  My errant assumption was not clear to me at that time.

> The warning can be ignored, however it is expected that the default
> configuration is at least minimally maintained.  Postfix supports
> multiple instances, so secondary instances are part of a larger
> configuration via the primary instance.

This is not clear in any of the documentation and is only hinted at in
the build instructions you forwarded (as URL).  Maybe that could be
fixed.

> Regaining some perspective would be appropriate at this point.
> Good luck.
>  
> -- 
>   Viktor.

I'm moving my files to /usr/local/etc/postfix.  This means editing a
few configuation file templates.

  % find local-config public -type f \
  | egrep -v 'public/fbsd/build/trace/' \
  | xargs grep -l etc/postfix
  local-config/system-files/etc/mda+/rc.conf
  local-config/system-files/etc/mta+/rc.conf
  local-config/system-files/pkg/pkg-files/cyrus-imapd/init.imapd.sh
  local-config/system-files/pkg/pkg-files/postfix-mda/main.cf
  local-config/system-files/pkg/pkg-files/postfix-mta/main.cf
  local-config/system-files/pkg/pkg-files/postfix-http/main.cf
  local-config/system-files/pkg/pkg-files/dkim-sign/keytable
  local-config/system-files/pkg/pkg-files/dkim-sign/dkim-sign.conf
  local-config/system-files/pkg/pkg-files/postfix-any/init.postfix.sh
  local-config/system-files/pkg/pkg-files/postfix-host/main.cf
  local-config/system-files/pkg/def/postfix-host
  local-config/system-files/pkg/def/postfix-any
  local-config/system-files/pkg/def/dkim-verify
  local-config/system-files/pkg/def/postfix-http
  local-config/system-files/pkg/def/dkim-sign
  local-config/system-files/pkg/def/postfix-mta
  local-config/system-files/pkg/def/postfix-mda
  local-config/system-files/pkg/host-files/mda+/sasl2/add/init.sasl2.sh
  local-config/system-files/default/harbor.rc.conf
  local-config/system-files/default/postfix.rc.conf
  public/fbsd/install-certs/GNUmakefile

This is because I generate configs.  I also changed /etc/postfix/dkim
to /etc/dkim - a more appropriate place and saves permission warnings.

No big deal.  Already completed this morning.

Thanks for the help.

Curtis

Re: local delivery, alias expansion, and subdomain matches

[Curtis Villamizar]

In message <20160201080958.9bede332...@english-breakfast.cloud9.net>
Curtis Villamizar writes:
> > Aliasing root on null-clients is explained in:
> >  
> >http://www.postfix.org/MULTI_INSTANCE_README.html#split
>  
> OK.  This

Oops.

Was going to write "This doesn't help".

The reason is that mail to something that aliases to root arrives at
an MDA and then is aliased to root and reforwarded to the admin
account.  Since it comes (by way of an MTA) from outside, it arrives
at the smptd instance.

The discussion of what I think would work was after the suggestion to
go reread
>http://www.postfix.org/ADDRESS_REWRITING_README.html#receiving
>http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual

The MDA is the tough case.

Curtis

Mail sender shown as 'spamfilter' (UID=502) when using smtplib

[Craig Allison]

Hello! 

I have a nice working postfix/dovecot server that I've been using with no 
problems for a couple of years, Centos 6.2, mail version 2.6.6.  I'm now using 
smtplib inside a Python script to send emails directly to my local network and 
in all messages the sender is being switched to user uid 502 (spamfilter). 

These lines appear when trying to send from 'craigallison' for instance. 

Feb  1 13:54:53 mercury postfix/pickup[21186]: 41D41C090F: uid=502 
from= 

I can provide further info if required, I've search everywhere for possible 
reasons and am stumped. 

Have tried using authentication for the user but makes no difference. 

Thanks 

Craig 


Craig Allison

Re: Rewrites message headers from remote SMTP clients

[Viktor Dukhovni]

> On Feb 2, 2016, at 1:10 AM, Roman Doe  wrote:
> 
> Using this can I do the following process?
> 
> If 1...@gmail.com = 1...@mydomain.com
> and 2...@gmail.com = 2...@mydomain.com
> 
> When 1...@gmail.com sends to 2...@mydomain.com (gmail webmail)
> Rewrite: 1...@gmail.com in 1...@mydomain.com 
> 2...@gmail.com receives from 1...@mydomain.com (gmail webmail)

No.  You can only rewrite either the sender address, the
recipient address or both.  In your case it seems you'd want:

http://www.postfix.org/postconf.5.html#sender_canonical_maps

main.cf:
indexed = ${default_database_type}:${config_directory}/
sender_canonical_maps = ${indexed}sender-canonical

sender-canonical:
us...@gmail.com us...@example.com

This will apply to all mail sent by us...@gmail.com, regardless
of the recipient address.

-- 
-- 
Viktor.

Re: Rewrites message headers from remote SMTP clients

[Roman Doe]

Exactly!
Everytime a @gmail.com sends to a @mydomaine.com I need to rewritte @
gmail.com to the associated @mydomaine.com
And everytime a @mydomain.com receives a mail it has to be sent to the
associated @gmail.com

I will try to implement this logic.
Thank you so much for your help, expertise and time!!

On Tue, Feb 2, 2016 at 8:04 AM, Viktor Dukhovni 
wrote:

>
> > On Feb 2, 2016, at 1:10 AM, Roman Doe  wrote:
> >
> > Using this can I do the following process?
> >
> > If 1...@gmail.com = 1...@mydomain.com
> > and 2...@gmail.com = 2...@mydomain.com
> >
> > When 1...@gmail.com sends to 2...@mydomain.com (gmail webmail)
> > Rewrite: 1...@gmail.com in 1...@mydomain.com
> > 2...@gmail.com receives from 1...@mydomain.com (gmail webmail)
>
> No.  You can only rewrite either the sender address, the
> recipient address or both.  In your case it seems you'd want:
>
> http://www.postfix.org/postconf.5.html#sender_canonical_maps
>
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> sender_canonical_maps = ${indexed}sender-canonical
>
> sender-canonical:
> us...@gmail.com us...@example.com
>
> This will apply to all mail sent by us...@gmail.com, regardless
> of the recipient address.
>
> --
> --
> Viktor.
>

Re: Rewrites message headers from remote SMTP clients

[Roman Doe]

Knowing that they can only have their header rewritten if they message
another @mydomain.com address.

On Tue, Feb 2, 2016 at 6:10 AM, Roman Doe  wrote:

> In the manner of a remailer, I want that 2 users registered on my website
> can speak with each other using their personal gmail address without
> displaying their @gmail.com , but instead displaying their @mydomain.com
> address.
>
> On Tue, Feb 2, 2016 at 6:02 AM, Benny Pedersen  wrote:
>
>> On 2016-02-02 04:34, Roman Doe wrote:
>>
>>> Is it possible to rewrite message headers from remote SMTP clients?
>>>
>>
>> why ?
>>
>
>

Re: Rewrites message headers from remote SMTP clients

[Roman Doe]

Using this can I do the following process?

If 1...@gmail.com = 1...@mydomain.com
and 2...@gmail.com = 2...@mydomain.com

When 1...@gmail.com sends to 2...@mydomain.com (gmail webmail)
Rewrite: 1...@gmail.com in 1...@mydomain.com
2...@gmail.com receives from 1...@mydomain.com (gmail webmail)

Thank you very much !

On Tue, Feb 2, 2016 at 6:52 AM, Viktor Dukhovni 
wrote:

>
> > On Feb 2, 2016, at 12:11 AM, Roman Doe  wrote:
> >
> > Knowing that they can only have their header rewritten if they message
> another @mydomain.com address.
> >
> > On Tue, Feb 2, 2016 at 6:10 AM, Roman Doe 
> wrote:
> > In the manner of a remailer, I want that 2 users registered on my
> website can speak with each other using their personal gmail address
> without displaying their @gmail.com , but instead displaying their @
> mydomain.com address.
>
> http://www.postfix.org/postconf.5.html#local_header_rewrite_clients
>
> --
> Viktor.
>
>

Re: Rewrites message headers from remote SMTP clients

[Viktor Dukhovni]

> On Feb 2, 2016, at 12:11 AM, Roman Doe  wrote:
> 
> Knowing that they can only have their header rewritten if they message 
> another @mydomain.com address.
> 
> On Tue, Feb 2, 2016 at 6:10 AM, Roman Doe  wrote:
> In the manner of a remailer, I want that 2 users registered on my website can 
> speak with each other using their personal gmail address without displaying 
> their @gmail.com , but instead displaying their @mydomain.com address.

http://www.postfix.org/postconf.5.html#local_header_rewrite_clients

-- 
Viktor.

Re: Rewrites message headers from remote SMTP clients

[Benny Pedersen]

On 2016-02-02 04:34, Roman Doe wrote:

Is it possible to rewrite message headers from remote SMTP clients?


why ?

Rewrites message headers from remote SMTP clients

[Roman Doe]

Is it possible to rewrite message headers from remote SMTP clients?

Re: Rewrites message headers from remote SMTP clients

[Roman Doe]

In the manner of a remailer, I want that 2 users registered on my website
can speak with each other using their personal gmail address without
displaying their @gmail.com , but instead displaying their @mydomain.com
address.

On Tue, Feb 2, 2016 at 6:02 AM, Benny Pedersen  wrote:

> On 2016-02-02 04:34, Roman Doe wrote:
>
>> Is it possible to rewrite message headers from remote SMTP clients?
>>
>
> why ?
>

Client Certificate Authentication for Auth Only

[Haravikk]

Hi there,

I’m trying to configure client certificate authentication such that it is only 
required for users (with valid username/password) when sending e-mail *from* my 
mail server.

However, setting smtpd_tls_req_ccert = yes causes postfix to request a 
certificate from all incoming connections, including mail servers that are 
attempting to deliver mail.

Is there a way to enable client certificates only for auth connections? I’ve 
already set smtpd_tls_auth_only = yes, but I’m not sure how to enable client 
certificates only for senders, without causing incoming messages to also be 
blocked.

Thanks,
Haravikk

Re: DKIM Signing (postfix + amavis-new)

[Noel Jones]

On 2/1/2016 12:30 AM, John A @ KLaM wrote:
> 
> My question is what is the /best/ way of getting postfix to forward
> mail to the signing policy bank.
> In one example the submission section of master.cf had the following
> lines added
> smtpd_proxy_filter=[127.0.0.1]:10026
> milter_macro_deamon_name=ORIGINATING
> Added, I think l understand the first line but why the second, it
> does seem to appear anywhere else.

The first line assumes a before-queue proxy filter (amavisd-new)
configured to do DKIM etc. on port 10026.  Your main.cf or regular
smtpd service would use a proxy filter on a different port.

The milter_macro_name parameter is used by some milters -- such as
opendkim -- to trigger DKIM signing.  It's not used by amavisd-new,
but won't cause any problem to be there.

A brief discussion of before-queue filtering vs. after-queue
filtering can be found here:
http://www.postfix.org/SMTPD_PROXY_README.html#pros_cons

> 
> In another a single line was added to the submission section
> Smtpd_content_filter=[127.0.0.1]:10026

This example uses an after-queue content filter.
Note: smtpd_content_filter is not a built-in postfix parameter, so
either this is a macro that must also be defined in main.cf or a typo.

This example omits the milter_macro_name, presumably because the
site does not use a milter, and has no plans to use a milter in the
future.

> 
> John A
> KlaM
> 

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

[Viktor Dukhovni]

> On Feb 1, 2016, at 3:54 AM, Curtis Villamizar  
> wrote:
> 
> As I said to Viktor, I mistakenly thought, based on reading (maybe
> misreading) numerous web pages of documentation with no mention of a
> limitation, that the -c argument was supposed to work like -c or -cf
> in any other package.  Now I know that it doesn't.

The "-c" argument absolutely works, but makes no promise that having
problematic settings in the default configuration directory will not
log any warnings.

The default configuration directory is used to determine whether the
target of the "-c" option is a secondary instance in a single command
in the start-up shell script.  The lookup of just that single parameter
happens to trigger a warning on your partly configured system.

For some reason you seem to have gotten rather worked up about a nit
that really does not warrant the bother.  Most people find it easier
to either compile with the preferred default, or use the default that's
compiled-in, and not have to use explicit "-c" options all the time.

The warning can be ignored, however it is expected that the default
configuration is at least minimally maintained.  Postfix supports
multiple instances, so secondary instances are part of a larger
configuration via the primary instance.

Regaining some perspective would be appropriate at this point.
Good luck.

-- 
Viktor.