Postfix and postman smtp plugin for wordpress

2017-08-22 Thread Alef Veld 
This is a long shot, but does anyone have any experience with setting up the 
postman smtp plugin with postfix? 

I can only send mails through without smtps or starttls (none). It seems to 
login with UNKNOWN and I get a "cannot open socket message" in the postman 
output when sending a test email.

Other clients work fine with SSL/TLS.

Sent from my iPhone

Best way to setup auto configure for mail clients

2017-08-22 Thread Alef Veld 
Does anyone know how to setup postfix in such a way so that clients can "auto 
configure" (you just fill in the email address and password and it guesses the 
settings)

I apologise if this is not a postfix thing perse.

Sent from my iPhone

Re: verifying per site TLS policy -- maps override?

2017-08-22 Thread yodeller 


On Tue, Aug 22, 2017, at 10:19 AM, Viktor Dukhovni wrote:
> > So that looks like it should work.
> 
> Yes, but what security goal does this achieve? 

Just what I said above.  To help working with specific senders if only to 
debug, etc.

I'm not looking for a policy or a philosphy, I'm just looking for a tool.  
rob0's approach does it for me for now.

Re: verifying per site TLS policy -- maps override?

2017-08-22 Thread Viktor Dukhovni 

> On Aug 22, 2017, at 12:52 PM, yodel...@yepmail.net wrote:
> 
> Based on your comment I found
> 
>  
> http://postfix.1071664.n5.nabble.com/Server-equivilent-of-smtp-tls-policy-maps-td26112.html
> 
> that provides the concrete example
> 
> smtpd_client_restrictions =
>check_client_access lmdb:/etc/postfix/require_crypt
> 
> # require_crypt.lmdb
>  example.com  reject_plaintext_session 
> 
> So that looks like it should work.

Yes, but what security goal does this achieve?  Firstly listing the
client domain name there works unreliably, because the PTR lookup
or the forward address lookup may tempfail, and then the client
will be able to send in the clear.   It is generally unwise to
use "reject_unknown_client_hostname" to insist that all clients
have working FCrDNS, so this check is fragile.

You also have no assurance that the client verified the server
certificate, so the connection might be via an MiTM attacker's
system.  The only protection this gets you is from passive
attacks, when there are no DNS hiccups.

A CIDR table (policy by client IP) is more reliable, but still
leaves room for active attacks, and tracking client IPs is often
difficult.

My advice for mandatory inbound TLS on port 25 public MX hosts
is "don't bother".

-- 
Viktor.

Re: verifying per site TLS policy -- maps override?

2017-08-22 Thread yodeller 
On Tue, Aug 22, 2017, at 09:36 AM, /dev/rob0 wrote:
> See reject_plaintext_session, and in the case as you described, 
> check_client_access:
> 
> http://www.postfix.org/postconf.5.html#reject_plaintext_session
> http://www.postfix.org/postconf.5.html#check_client_access
> http://www.postfix.org/access.5.html

Ok, didn't know about

  reject_plaintext_session

so thanks!

Based on your comment I found

  
http://postfix.1071664.n5.nabble.com/Server-equivilent-of-smtp-tls-policy-maps-td26112.html

that provides the concrete example

 smtpd_client_restrictions =
check_client_access lmdb:/etc/postfix/require_crypt

 # require_crypt.lmdb
  example.com  reject_plaintext_session 

So that looks like it should work.

Re: verifying per site TLS policy -- maps override?

2017-08-22 Thread /dev/rob0 
On Tue, Aug 22, 2017 at 09:21:33AM -0700, yodel...@yepmail.net wrote:
> The reason that I'm asking is that I'd like to set my inbound 
> policy =may by default, but for specific servers (that I may
> be working or warring with) sending email to me I want to
> force policy =encrypt.
> 
> For infrequent one offs like that, even if I could specify a
> few sending hosts, by hostname &/or even IP, to force inbound
> TLS =encrypt policy it'd be useful.

See reject_plaintext_session, and in the case as you described, 
check_client_access:

http://www.postfix.org/postconf.5.html#reject_plaintext_session
http://www.postfix.org/postconf.5.html#check_client_access
http://www.postfix.org/access.5.html
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: verifying per site TLS policy -- maps override?

2017-08-22 Thread yodeller 
On Tue, Aug 22, 2017, at 09:13 AM, Viktor Dukhovni wrote:
> > Is there an inbound  per-domain TLS policy map?
> 
> http://www.postfix.org/TLS_README.html#client_tls_limits

Thanks. Okay I get that.  But that reads like policy to me.  It doesn't sound 
like it's impossible.

The reason that I'm asking is that I'd like to set my inbound policy =may by 
default, but for specific servers (that I may be working or warring with) 
sending email to me I want to force policy =encrypt.

For infrequent one offs like that, even if I could specify a few sending hosts, 
by hostname &/or even IP, to force inbound TLS =encrypt policy it'd be useful.

But if it can't be done, ok it can't. I get that.

Re: verifying per site TLS policy -- maps override?

2017-08-22 Thread Viktor Dukhovni 

> On Aug 22, 2017, at 12:08 PM, yodel...@yepmail.net wrote:
> 
> Is there an inbound  per-domain TLS policy map?

http://www.postfix.org/TLS_README.html#client_tls_limits

One may be tempted to try enforcing TLS for mail from specific sending 
organizations, but this, too, runs into obstacles. One such obstacle is that we 
don't know who is (allegedly) sending mail until we see the "MAIL FROM:" SMTP 
command, and at that point, if TLS is not already in use, a potentially 
sensitive sender address (and with SMTP PIPELINING one or more of the 
recipients) has (have) already been leaked in the clear. Another obstacle is 
that mail from the sender to the recipient may be forwarded, and the forwarding 
organization may not have any security arrangements with the final destination. 
Bounces also need to be protected. These can only be identified by the IP 
address and HELO name of the connecting client, and it is difficult to keep 
track of all the potential IP addresses or HELO names of the outbound email 
servers of the sending organization.

Consequently, TLS security for mail delivery to public MX hosts is almost 
entirely the client's responsibility. The server is largely a passive enabler 
of TLS security, the rest is up to the client. While the server has a greater 
opportunity to mandate client security policy when it is a dedicated MSA that 
only handles outbound mail from trusted clients, below we focus on the client 
security policy.

> Are they named differently, or not available because of the way the handshake 
> happens?

See above.

-- 
Viktor.

Re: verifying per site TLS policy -- maps override?

2017-08-22 Thread yodeller 


On Tue, Aug 22, 2017, at 09:00 AM, Viktor Dukhovni wrote:
> The global security level set via "smtp_tls_security_level" is
> optionally preëmpted by the per-destination policy table (which
> can also override selected additional TLS settings).

Yeah I see the option to set the additional TLS params.  That's exactly what 
I'm looking for.

> > In other words, the DEFAULT policy will =may, and will be OVERRIDDEN by 
> > matches in tls_policy_outbound?
> 
> Yes.

Perfect. Thanks.

For *INBOUND*, either @ postscreen or @ the after-postscreen smtpd handoff I 
can set

 -o postscreen_tls_security_level=

or

 -o smtpd_tls_security_level=

respectively.

Is there an inbound  per-domain TLS policy map?

I looked for both

 smtpd_tls_policy_maps
 postscreen_tls_policy_maps

but didn't see anything in the docs.

Are they named differently, or not available because of the way the handshake 
happens?

Re: verifying per site TLS policy -- maps override?

2017-08-22 Thread Viktor Dukhovni 

> On Aug 22, 2017, at 11:52 AM, yodel...@yepmail.net wrote:
> 
> I just want to make sure I understand per-site domain policy maps' priority.
> 
> If I set up an outbound postfix instance with
> 
>  -o smtp_tls_security_level=may
>  -o smtp_tls_policy_maps=lmdb:/etc/postfix/tls_policy_outbound
> 
> the way that works is that both are used, right?

The global security level set via "smtp_tls_security_level" is
optionally preëmpted by the per-destination policy table (which
can also override selected additional TLS settings).

> In other words, the DEFAULT policy will =may, and will be OVERRIDDEN by 
> matches in tls_policy_outbound?

Yes.

-- 
Viktor.

verifying per site TLS policy -- maps override?

2017-08-22 Thread yodeller 
Hi

I just want to make sure I understand per-site domain policy maps' priority.

If I set up an outbound postfix instance with

  -o smtp_tls_security_level=may
  -o smtp_tls_policy_maps=lmdb:/etc/postfix/tls_policy_outbound

the way that works is that both are used, right?

In other words, the DEFAULT policy will =may, and will be OVERRIDDEN by matches 
in tls_policy_outbound?

Thanks

Re: no response from postfix on submission port (or 465)

2017-08-22 Thread Matus UHLAR - fantomas 

On Tue, 22 Aug 2017 10:14:11 +, Alef Veld stated:

Now which clarifies things a lot. I'll probably keep 465 with wrapper mode to
support outlook expresss or other clients which want it and put 587 without.


On 22.08.17 07:23, Postfix User wrote:

MS Outlook Express was depreciated in Windows 7, way back on Oct 2009. It has
been years since I have seen anyone actually use it. I removed wrapper mode 5
years ago and never looked back.


I've seen comments from users/admins who recommend using SSL-only ports like
465, as opposed to 587 where plaintext is technically possible.

I've also seen problem where port 587 was blocked by antivirus trying to
scan the connection, where 465 went OK.

That's why I better provide both 587 and 465 on servers I maintain...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
REALITY.SYS corrupted. Press any key to reboot Universe.

Re: no response from postfix on submission port (or 465)

2017-08-22 Thread Postfix User 
On Tue, 22 Aug 2017 10:14:11 +, Alef Veld stated:

>Now which clarifies things a lot. I'll probably keep 465 with wrapper mode to
>support outlook expresss or other clients which want it and put 587 without.

MS Outlook Express was depreciated in Windows 7, way back on Oct 2009. It has
been years since I have seen anyone actually use it. I removed wrapper mode 5
years ago and never looked back.

-- 
Jerry

Re: no response from postfix on submission port (or 465)

2017-08-22 Thread Alef Veld 
Reading http://www.postfix.org/TLS_README.html

Now which clarifies things a lot. I'll probably keep 465 with wrapper mode to 
support outlook expresss or other clients which want it and put 587 without.

Thanks for the answer, I can now telnet to the port and get a greeting. I 
didn't understand it was encrypted, but that explains the logs as well.

I have a inkling this will fix the problems with my mac clients as well.

Sent from my iPhone

On 22 Aug 2017, at 09:12, Alef Veld 
> wrote:

Hi Peter and Noel,
What is wrappermode ?

I see i have it enabled both for submission and smtps. Is it enabled by default 
?
I can still send and receive email although some clients seem to have problems 
with it.

These are my master.cf entries:
smtp  inet  n   -   n   -   -   smtpd
submission inet n   -   n   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_security_level=may
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_local_domain=$myhostname
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_sender_login_maps=hash:/etc/postfix/virtual
  -o 
smtpd_sender_restrictions=permit_sasl_authenticated,reject_sender_login_mismatch
  -o 
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
smtps inet  n   -   n   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_security_level=may
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_local_domain=$myhostname
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_sender_login_maps=hash:/etc/postfix/virtual
  -o 
smtpd_sender_restrictions=permit_sasl_authenticated,reject_sender_login_mismatch
  -o 
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

Apologies for the html logs earlier, i copied and pasted them, didn’t realize.


On 22 Aug 2017, at 04:44, Peter 
> wrote:



On 22/08/17 10:44, Alef Veld wrote:
It's open, but i just don't get any welcome message.

Do not set smtpd_tls_wrappermode for port 587.

Usually switching to non secure and then back to SSL fixes it.

You'll be switching to SSL (as opposed to STARTTLS).  The appropriate
setting for port 587 is STARTTLS.


Peter

Re: no response from postfix on submission port (or 465)

2017-08-22 Thread Alef Veld 
Hi Peter and Noel,
What is wrappermode ?

I see i have it enabled both for submission and smtps. Is it enabled by default 
?
I can still send and receive email although some clients seem to have problems 
with it.

These are my master.cf entries:
smtp  inet  n   -   n   -   -   smtpd
submission inet n   -   n   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_security_level=may
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_local_domain=$myhostname
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_sender_login_maps=hash:/etc/postfix/virtual
  -o 
smtpd_sender_restrictions=permit_sasl_authenticated,reject_sender_login_mismatch
  -o 
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
smtps inet  n   -   n   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_security_level=may
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_local_domain=$myhostname
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_sender_login_maps=hash:/etc/postfix/virtual
  -o 
smtpd_sender_restrictions=permit_sasl_authenticated,reject_sender_login_mismatch
  -o 
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

Apologies for the html logs earlier, i copied and pasted them, didn’t realize.


On 22 Aug 2017, at 04:44, Peter 
> wrote:



On 22/08/17 10:44, Alef Veld wrote:
It's open, but i just don't get any welcome message.

Do not set smtpd_tls_wrappermode for port 587.

Usually switching to non secure and then back to SSL fixes it.

You'll be switching to SSL (as opposed to STARTTLS).  The appropriate
setting for port 587 is STARTTLS.


Peter

Re: skip dkim signing for local delivery

2017-08-22 Thread Markus Rosjat 

Hi there again,

maybe this question got lost somehow or maybe it's not considered valid 
but if someone out there could at least in some direction that I could 
check to find a solution?


Regards

Markus

Am 15.08.2017 um 09:42 schrieb Markus Rosjat:

Hi there,

Im new to the whole postix, dkim and other mail related things so this 
question might be asked befor or stupid at all but I couldn't find 
something on the net (or I'm just to stupid to look for it). So here we 
go ...


I configured dkim with dkimproxy for outgoing mail and this works fine 
as long as postfix send the mail off to a other server in the world. For 
local delivery it doesnt work because postfix is rewriting the RCPT 
address from n...@domain.tld to local_u...@domain.tld and then it tells 
me he there is no local_u...@domain.tld because there isn't (no I don't 
have an alias for this).


So the real question is, can I configure postfix to ignore the 
forwarding to dkimproxy for local delivery ?


regards



--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT