Re: Feasible to encrypt the virtual_mailbox_base directory with ecryptfs?

[Philip Paeps]

On 2017-05-20 20:33:01 (-0700), pbw  wrote:

Has anyone tried to do this?  Was it feasible?


As long as the encryption is transparent to Postfix, it shouldn't 
matter.  I run all my mail systems on encrypted volumes.


Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

Re: TLS warning

[Philip Paeps]

On 2017-05-24 14:54:34 (+0200), Bastian Blank 
 wrote:

On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com wrote:

‎You shouldn't be accepting sslv3 due to the poodle attack.
https://en.m.wikipedia.org/wiki/POODLE


Please explain how exactly SMTP is exploitable using POODLE?


There are other good reasons to disable SSLv3.  But POODLE is a 
distraction in the context of SMTP.


In general though, when it comes to SMTP, any encryption is better than 
none.  And opportunistic encryption is the way to go.  Read RFC 7435:


https://tools.ietf.org/html/rfc7435

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

Re: Issue with SASL authentication

[Daniel Bareiro]

Hi again.

On 24/05/17 17:46, Daniel Bareiro wrote:

> Maybe this question is not 100% about Postfix, but it is related. I am
> configuring a Postifx server with SASL authentication.
> 
> When I do a test to authenticate, I get an error:
> 
> --
> root@server2:~# saslpasswd2 -c daniel
> --
> root@server2:~# testsaslauthd -u daniel -p password
> 0: NO "authentication failed"
> --
> 
> However it works when I provide the realm:
> 
> --
> root@server2:~# testsaslauthd -u daniel -r server2 -p password
> 0: OK "Success."
> --
> 
> It's strange because I have another mail server where it works without
> problems:
> 
> --
> root@mail:~# testsaslauthd -u daniel -p password
> 0: OK "Success."
> --
> 
> Both hosts have Debian Jessie and the SASL configuration is the same:
> 
> --
> root@mail:~# grep ^[^#] /etc/default/saslauthd
> START=yes
> DESC="SASL Authentication Daemon"
> NAME="saslauthd"
> MECHANISMS="sasldb"
> MECH_OPTIONS=""
> THREADS=5
> OPTIONS="-c -m /var/run/saslauthd"
> --
> root@server2:~# grep ^[^#] /etc/default/saslauthd
> START=yes
> DESC="SASL Authentication Daemon"
> NAME="saslauthd"
> MECHANISMS="sasldb"
> MECH_OPTIONS=""
> THREADS=5
> OPTIONS="-c -m /var/run/saslauthd"
> --
> 
> "mail" has some updates to apply, but I do not see any differences in
> the versions of the SASL packages:
> 
> --
> root@mail:~# aptitude show libsasl2-2 | grep Versión
> Versión: 2.1.26.dfsg1-13+deb8u1
> 
> root@mail:~# aptitude show libsasl2-modules | grep Versión
> Versión: 2.1.26.dfsg1-13+deb8u1
> 
> root@mail:~# aptitude show sasl2-bin | grep Versión
> Versión: 2.1.26.dfsg1-13+deb8u1
> --
> 
> --
> root@server2:~# aptitude show libsasl2-2 | grep Version
> Version: 2.1.26.dfsg1-13+deb8u1
> 
> root@server2:~# aptitude show libsasl2-modules | grep Version
> Version: 2.1.26.dfsg1-13+deb8u1
> 
> root@server2:~# aptitude show sasl2-bin | grep Version
> Version: 2.1.26.dfsg1-13+deb8u1
> --
> 
> In this case I'm not doing the authentication test against IMAP but
> directly against SASL, so I guess the problem will be directly related
> to the SASL configuration itself.
> 
> In case it is useful, when the authentication fails I get this in
> /var/log/auth.log:
> 
> --
> May 24 15:31:38 server2 saslauthd[2701]: do_auth : auth failure:
> [user=daniel] [service=imap] [realm=] [mech=sasldb] [reason=Unknown]
> --
> 
> It seems that authentication is done through IMAP and I have previously
> installed the Cyrus packages.
> 
> 
> Any thoughts about what might differ between the two environments?

Apparently, despite this difference, the SASL authentication via IMAP is
working.

/var/log/mail.log:

--
May 24 19:38:51 server2 cyrus/imaps[3711]: starttls: TLSv1.2 with cipher
ECDHE-RSA-AES128-SHA (128/128 bits new) no authentication
May 24 19:38:51 server2 cyrus/imaps[3711]: login: host.domain.tld.net
[x.y.z.t] daniel CRAM-MD5+TLS User logged in
SESSIONID=
May 24 19:38:51 server2 cyrus/imaps[3711]: created decompress buffer of
4102 bytes
May 24 19:38:51 server2 cyrus/imaps[3711]: created compress buffer of
4102 bytes
May 24 19:38:51 server2 cyrus/imaps[3711]: client id: "name"
"Thunderbird" "version" "45.8.0"
May 24 19:38:53 server2 cyrus/master[3800]: about to exec
/usr/lib/cyrus/bin/imapd
May 24 19:38:53 server2 cyrus/imaps[3800]: executed
May 24 19:38:53 server2 cyrus/imaps[3800]: accepted connection
May 24 19:38:53 server2 cyrus/imaps[3800]: imapd:Loading hard-coded DH
parameters
May 24 19:38:53 server2 cyrus/imaps[3800]: SSL_accept() incomplete -> wait
May 24 19:38:54 server2 cyrus/imaps[3800]: SSL_accept() succeeded -> done
--

But SMTP authentication for sending mail is not working.

/var/log/auth.log:

--
May 24 20:12:38 server2 saslauthd[3685]: do_auth : auth failure:
[user=daniel] [service=smtp] [realm=] [mech=sasldb

Re: Relay access denied

[Viktor Dukhovni]

> On May 24, 2017, at 5:05 PM, alexvojproc  wrote:
> 
> smtpd_tls_cert_file=/etc/letsencrypt/live/REDACTED/fullchain.pem
> smtpd_tls_key_file=/etc/letsencrypt/live/REDACTED/privkey.pem
> smtpd_use_tls=yes

The non-obsolete setting is:

smtpd_tls_security_level = may

though if this is a submission service (not an MX host for any inbound
mail) you could use "encrypt" instead of "may".  If it is also an MX
host, it is best to handle outbound submission on port 587.

> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

With Postfix >= 2.11 you should leave this empty, session tickets are
a more appropriate way to handle session resumption.

> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated, 
> defer_unauth_destination

If you handle submission separately on 587 (aka submission/inet in
master.cf), then this just becomes "reject_unauth_destination".

> myhostname = localhost

Not a good idea, configure a sensible stable FQDN.

> smtp_tls_security_level = encrypt

Fine, provided your relayhost supports TLS.

> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_sasl_security_options = noanonymous

This handles SASL from your MTA to the relayhost, BUT you've
completely neglected to configure SASL for authenticating
inbound mail submission.  Those are "smtpd_sasl_..." settings.
See SASL_README for details.

> I'm intending for users to be able to connect to my server on port 25 and
> send mail, which is relayed through smtp.mailgun.org. However, I can only
> send mail to local users, and I receive "Server error: '454 4.7.1
> : Relay access denied'" when I try to send mail to remote
> hosts like my Gmail account.

Of course, since the users have no opportunity to authenticate.

-- 
Viktor.

Multiple recipients in BCC will not relay if it contains one bad email address.

[madrida]

Hi Everyone first time posting, I am hoping you can help me. We have an issue
when an email sent to multiple emails via BCC is deleted if an invalid email
address is in the list. The email is discarded all together and I don't see
any logs other then the bounces. They need to send via BCC for privacy to
other vendors. We need to bounce the back emails and continue to send to all
the valid recipients. 

I have attached the postconf in this thread. 


Running Postfix version 2.7.0  postconf.txt
  



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Multiple-recipients-in-BCC-will-not-relay-if-it-contains-one-bad-email-address-tp90616.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Relay access denied

[alexvojproc]

I forgot to add log info (although there's nothing particularly useful):

May 24 19:39:22 server postfix/smtpd[2506]: connect from REDACTED
May 24 19:39:22 server postfix/smtpd[2506]: NOQUEUE: reject: RCPT from
REDACTED: 454 4.7.1 : Relay access denied;
from= to= proto=ESMTP
helo=



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Relay-access-denied-tp90614p90615.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Relay access denied

[alexvojproc]

I have a Google Compute VM that I would like to use as a mail server.
 However, outgoing ports 25, 465, and 587 are blocked
so I must use a third-party mail service. I followed the instructions for
Mailjet , but I changed inet_interfaces to all. I
have this main.cf config (I removed comments for brevity):


smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
readme_directory = no
smtpd_tls_cert_file=/etc/letsencrypt/live/REDACTED/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/REDACTED/privkey.pem
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
myhostname = localhost
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = REDACTED, localhost, localhost.localdomain, localhost
relayhost = [smtp.mailgun.org]:2525
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtp_tls_security_level = encrypt
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
home_mailbox = Maildir/
alias_database = hash:/etc/aliases

The contents of /etc/postfix/sasl_passwd (before it was hashed) was:
[smtp.gridhost.org]:2525 postmaster@REDACTED:REDACTED


I'm intending for users to be able to connect to my server on port 25 and
send mail, which is relayed through smtp.mailgun.org. However, I can only
send mail to local users, and I receive "Server error: '454 4.7.1
: Relay access denied'" when I try to send mail to remote
hosts like my Gmail account.

I figured this is a problem with my smtp_sasl security settings, and I'm not
authenticating properly. So, I tried specifying "My outgoing server (SMTP)
requires authentication", but this does not work, since it seems this is not
supported. Then, I (think) I realised that the smtp_sasl_auth is for my
server connecting to the relay. I think what I need to do is disable this
authentication for the clients, but not for connecting to the relay. That
would make my server a relay to a relay, I think.

Can anybody make sense of this? If it's relevant, I'm also using Dovecot for
IMAP.



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Relay-access-denied-tp90614.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Issue with SASL authentication

[Daniel Bareiro]

Hi all!

Maybe this question is not 100% about Postfix, but it is related. I am
configuring a Postifx server with SASL authentication.

When I do a test to authenticate, I get an error:

--
root@server2:~# saslpasswd2 -c daniel
--
root@server2:~# testsaslauthd -u daniel -p password
0: NO "authentication failed"
--

However it works when I provide the realm:

--
root@server2:~# testsaslauthd -u daniel -r server2 -p password
0: OK "Success."
--

It's strange because I have another mail server where it works without
problems:

--
root@mail:~# testsaslauthd -u daniel -p password
0: OK "Success."
--

Both hosts have Debian Jessie and the SASL configuration is the same:

--
root@mail:~# grep ^[^#] /etc/default/saslauthd
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="sasldb"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/run/saslauthd"
--
root@server2:~# grep ^[^#] /etc/default/saslauthd
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="sasldb"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/run/saslauthd"
--

"mail" has some updates to apply, but I do not see any differences in
the versions of the SASL packages:

--
root@mail:~# aptitude show libsasl2-2 | grep Versión
Versión: 2.1.26.dfsg1-13+deb8u1

root@mail:~# aptitude show libsasl2-modules | grep Versión
Versión: 2.1.26.dfsg1-13+deb8u1

root@mail:~# aptitude show sasl2-bin | grep Versión
Versión: 2.1.26.dfsg1-13+deb8u1
--

--
root@server2:~# aptitude show libsasl2-2 | grep Version
Version: 2.1.26.dfsg1-13+deb8u1

root@server2:~# aptitude show libsasl2-modules | grep Version
Version: 2.1.26.dfsg1-13+deb8u1

root@server2:~# aptitude show sasl2-bin | grep Version
Version: 2.1.26.dfsg1-13+deb8u1
--

In this case I'm not doing the authentication test against IMAP but
directly against SASL, so I guess the problem will be directly related
to the SASL configuration itself.

In case it is useful, when the authentication fails I get this in
/var/log/auth.log:

--
May 24 15:31:38 server2 saslauthd[2701]: do_auth : auth failure:
[user=daniel] [service=imap] [realm=] [mech=sasldb] [reason=Unknown]
--

It seems that authentication is done through IMAP and I have previously
installed the Cyrus packages.


Any thoughts about what might differ between the two environments?


Thanks in advance.

Kind regards,
Daniel



signature.asc
Description: OpenPGP digital signature

Re: TLS warning

[Rick Leir]

Viktor, LazyG
This is not nonsense, as I learned something from it. Now I will go and check 
whether it is enabled.

And thanks for mentioning foundations and family etc. That is also useful.

Maybe we should be a bit more polite to other folks in the list, we are mostly 
'in the same boat'.
Cheers --- Rick

On May 24, 2017 12:26:32 PM EDT, Viktor Dukhovni  
wrote:
>
>> On May 24, 2017, at 5:41 AM, li...@lazygranch.com wrote:
>> 
>> ‎You shouldn't be accepting sslv3 due to the poodle attack.
>> 
>> https://en.m.wikipedia.org/wiki/POODLE
>> 
>> A search should indicate what to change to reject sslv3.
>> 
>> Of course there still could be other things that need fixing. ;-)
>
>Please don't distract people asking questions with nonsense.
>
>There is no evidence the OP has SSLv3 enabled.  The SSLv3
>protocol is the foundation on which TLS 1.0, 1.1 and 1.2
>(and to a much lesser extent TLS 1.3) are built.  All
>these protocols share the underlying record layer and
>alert processing code.  When OpenSSL logging reports
>an error from an "ssl3" function, the actual protocol
>in use could be any of the family of protocols that
>are based on SSL 3.0.
>
>-- 
>   Viktor.

-- 
Sorry for being brief. Alternate email is rickleir at yahoo dot com 

Re: Why am I accepting this email?

[Wietse Venema]

D'Arcy Cain:
> On 2017-05-24 11:11 AM, Wietse Venema wrote:
> >> I still don't understand why I accepted the email anyway.  The user
> >> didn't exist.
> > 
> > Because relay recipients are blocked only when relay_recipient_maps
> > lists the 'valid' recipients; this is not a required setting.
> 
> So would this setting make sense?
> 
> relay_recipient_maps = $virtual_maps, $alias_maps

As the name implies, relay_recipient_maps is for recipients that
are relayed.

Recipients in virtual mailbox domains are not relayed.

Recipients in alias maps are not relayed.

Therefore the answer is NO.

Wietse

> -- 
> D'Arcy J.M. Cain
> System Administrator, Vex.Net
> http://www.Vex.Net/ IM:da...@vex.net
> VoIP: sip:da...@vex.net
> 

Re: Why am I accepting this email?

[Viktor Dukhovni]

> On May 24, 2017, at 11:17 AM, D'Arcy Cain  wrote:
> 
>> Because relay recipients are blocked only when relay_recipient_maps
>> lists the 'valid' recipients; this is not a required setting.
> 
> So would this setting make sense?
> 
> relay_recipient_maps = $virtual_maps, $alias_maps

Mailboxes listed in virtual_alias_maps ($virtual_maps is obsolete)
are automatically valid for every address class and need not be
listed in relay_recipient_maps and the like.

The lookup keys in $alias_maps are presumably just "bare" localpart
addresses ("user" not "u...@example.com"), so not useful here either.

If there are no valid relay recipients, set "relay_domains =" and
then you don't need relay_recipient_maps.  If there are valid
relay domains, create a table that lists them (by full address).

-- 
Viktor.

Re: TLS warning

[Viktor Dukhovni]

> On May 24, 2017, at 5:30 AM, Rick Leir  wrote:
> 
> Should this TLS warning worry me?

No.

> May 23 11:35:43 myHostName postfix/smtpd[6619]: SSL_accept error from 
> sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]: 0
> May 23 11:35:43 myHostName postfix/smtpd[6619]: warning: TLS library problem: 
> error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate 
> unknown:s3_pkt.c:1262:SSL alert number 46:
> May 23 11:35:43 myHostName postfix/smtpd[6619]: lost connection after 
> STARTTLS from sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]
> 
> May 23 11:35:43 myHostName postfix/smtpd[6619]: connect from 
> sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]
> May 23 11:35:43 myHostName postfix/smtpd[6619]: 6C9CF41E45: 
> client=sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

Some misconfigured Yahoo systems don't understand how to do
opportunistic TLS.  They do however know how to needlessly
downgrade themselves to cleartext.  See:

http://postfix.1071664.n5.nabble.com/Another-yahoo-problem-td89756.html
 
-- 
Viktor.

Re: TLS warning

[Viktor Dukhovni]

> On May 24, 2017, at 5:41 AM, li...@lazygranch.com wrote:
> 
> ‎You shouldn't be accepting sslv3 due to the poodle attack.
> 
> https://en.m.wikipedia.org/wiki/POODLE
> 
> A search should indicate what to change to reject sslv3.
> 
> Of course there still could be other things that need fixing. ;-)

Please don't distract people asking questions with nonsense.

There is no evidence the OP has SSLv3 enabled.  The SSLv3
protocol is the foundation on which TLS 1.0, 1.1 and 1.2
(and to a much lesser extent TLS 1.3) are built.  All
these protocols share the underlying record layer and
alert processing code.  When OpenSSL logging reports
an error from an "ssl3" function, the actual protocol
in use could be any of the family of protocols that
are based on SSL 3.0.

-- 
Viktor.

Re: Why am I accepting this email?

[Paul Schmehl]

--On May 24, 2017 at 9:25:30 AM -0400 D'Arcy Cain  wrote:


The following is in my logs.  I have no server called nan.vex.net and no
user called aida.wanda.  I don't see anything in main.cf that looks like
a wild card entry.  Can anyone suggest why I would be accepting this
message in the first place?  I really don't want to back-scatter.

May 22 20:11:59 smaug postfix/smtpd[5457]: BBA8F3F9F1CA:
client=mx-n07.wc1.phx1.stabletransit.com[207.246.241.253] May 22 20:11:59
smaug postfix/cleanup[8796]: BBA8F3F9F1CA:
message-id=<20170523001149.8c76f642...@mx-n07.wc1.phx1.stabletransit.com>
May 22 20:12:00 smaug postfix/qmgr[347]: BBA8F3F9F1CA:
from=, size=22692, nrcpt=1 (queue active) May 22


This message was accepted.  ^


20:12:00 smaug postfix/smtp[9232]: BBA8F3F9F1CA:
to=, relay=none, delay=0.34,
delays=0.33/0.01/0/0, dsn=5.4.6, status=bounced (mail for nan.vex.net

  

loops back to myself) May 22 20:12:00 smaug postfix/bounce[3630]:

^^^

BBA8F3F9F1CA: sender non-delivery notification: 1D2793F9F1D8 May 22
20:12:00 smaug postfix/qmgr[347]: BBA8F3F9F1CA: removed


This message was rejected.


"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher

Re: Why am I accepting this email?

[Benny Pedersen]

D'Arcy Cain skrev den 2017-05-24 17:17:

On 2017-05-24 11:11 AM, Wietse Venema wrote:

I still don't understand why I accepted the email anyway.  The user
didn't exist.


Because relay recipients are blocked only when relay_recipient_maps
lists the 'valid' recipients; this is not a required setting.


So would this setting make sense?

relay_recipient_maps = $virtual_maps, $alias_maps


no no no

relay domains is remote mta, and virtual is localy, virtualy can be 
forwarded, but its not same master services


use this relay as a backup mx if needed, not for anything localy

if not using backup mx, make that map empty but defined solves it

Re: Why am I accepting this email?

[D'Arcy Cain]

On 2017-05-24 11:11 AM, Wietse Venema wrote:

I still don't understand why I accepted the email anyway.  The user
didn't exist.


Because relay recipients are blocked only when relay_recipient_maps
lists the 'valid' recipients; this is not a required setting.


So would this setting make sense?

relay_recipient_maps = $virtual_maps, $alias_maps

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net

Re: Why am I accepting this email?

[Wietse Venema]

D'Arcy Cain:
> On 2017-05-24 09:53 AM, Wietse Venema wrote:
> > D'Arcy Cain:
> >> On 2017-05-24 09:30 AM, Benny Pedersen wrote:
> >>> D'Arcy Cain skrev den 2017-05-24 15:25:
>  The following is in my logs.
> >>>
> >>> provide postconf -n to get more help
> >>
> >> I knew I forgot something.
> > 
> > Postfix before 3.0 by default accepts for relay all domains listed in
> > mydestination (including vex.net) and subdomains (nan.vex.net).
> > 
> > Suggestion: set relay_domains in main.cf, empty or with domains that you 
> > want to relay.
> 
> I use mynetworks to specify who can send email through us so I set 
> relay_domains to empty.  Thanks.
> 
> I still don't understand why I accepted the email anyway.  The user 
> didn't exist.

Because relay recipients are blocked only when relay_recipient_maps
lists the 'valid' recipients; this is not a required setting.

We could make such a table required, along with local_recipient_maps
and a number of other changes, and make the new defaults conditional
on compatibility_level>=3.

Wietse

Re: Recipient Restrictions

[Noel Jones]

On 5/24/2017 8:11 AM, GP wrote:
> Hi all,
> 
> is it possible to have restrictions that apply to certain users only
> with postfix ?

Yes, using either smtpd_restriction_classes or an external policy
service.
http://www.postfix.org/RESTRICTION_CLASS_README.html
http://www.postfix.org/SMTPD_POLICY_README.html


> For example I want some users not to be able to send or receive
> messages
> more than 2MB in size  . Can it be done ?

Size is a little tricky if you have to deal with multi-recipient
mail, but your best choice here is an external policy service such
as postfwd.
http://postfwd.org/



  -- Noel Jones

Re: Why am I accepting this email?

[D'Arcy Cain]

On 2017-05-24 09:53 AM, Wietse Venema wrote:

D'Arcy Cain:

On 2017-05-24 09:30 AM, Benny Pedersen wrote:

D'Arcy Cain skrev den 2017-05-24 15:25:

The following is in my logs.


provide postconf -n to get more help


I knew I forgot something.


Postfix before 3.0 by default accepts for relay all domains listed in
mydestination (including vex.net) and subdomains (nan.vex.net).

Suggestion: set relay_domains in main.cf, empty or with domains that you want 
to relay.


I use mynetworks to specify who can send email through us so I set 
relay_domains to empty.  Thanks.


I still don't understand why I accepted the email anyway.  The user 
didn't exist.


--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net

Re: Why am I accepting this email?

[Wietse Venema]

D'Arcy Cain:
> On 2017-05-24 09:30 AM, Benny Pedersen wrote:
> > D'Arcy Cain skrev den 2017-05-24 15:25:
> >> The following is in my logs.
> > 
> > provide postconf -n to get more help
> 
> I knew I forgot something.

Postfix before 3.0 by default accepts for relay all domains listed in
mydestination (including vex.net) and subdomains (nan.vex.net).

Suggestion: set relay_domains in main.cf, empty or with domains that you want 
to relay.

Wietse

Re: Why am I accepting this email?

[D'Arcy Cain]

On 2017-05-24 09:30 AM, Benny Pedersen wrote:

D'Arcy Cain skrev den 2017-05-24 15:25:

The following is in my logs.


provide postconf -n to get more help


I knew I forgot something.

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
alias_database = hash:/etc/postfix/aliases hash:/var/db/mailman/data/aliases
alias_maps = hash:/etc/postfix/aliases, hash:/var/db/mailman/data/aliases
always_add_missing_headers = yes
body_checks = regexp:/var/postfix/body_checks
bounce_queue_lifetime = 3d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
command_time_limit = 5000
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
debugger_command = PATH=/usr/bin:/usr/X11R6/bin xxgdb 
$daemon_directory/$process_name $process_id & sleep 5
default_destination_concurrency_limit = 10
disable_vrfy_command = yes
header_checks = regexp:/var/postfix/virus_header_checks 
regexp:/var/postfix/header_checks regexp:/var/postfix/auth_checks
home_mailbox = mail/INBOX/
html_directory = no
local_destination_concurrency_limit = 2
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_command = /usr/pkg/bin/procmail
mailbox_size_limit = 102400
mailq_path = /usr/bin/mailq
manpage_directory = /usr/man
masquerade_domains = shell.vex.net, smaug.vex.net
masquerade_exceptions = root, db, pgsql
maximal_queue_lifetime = 3d
message_size_limit = 104857600
mydestination = $mydomain, aragorn.$mydomain, db.$mydomain, druid.$mydomain, 
gollum.$mydomain, mail.$mydomain, mailman.$mydomain, pop.$mydomain, 
sauron.$mydomain, shell.$mydomain, smaug.$mydomain, vex.$mydomain, 
localdomain.vex.net
mydomain = vex.net
myhostname = mail.vex.net
mynetworks = 127.0.0.0/8, 98.158.139.64/27, 192.168.151.0/24, 64.99.180.16/29, 
dilbert.druid.net, queen.vex.net
mynetworks_style = subnet
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
owner_request_special = no
postscreen_access_list = permit_mynetworks, 
cidr:/var/postfix/postscreen_access.cidr
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*2, bl.spamcop.net*2, 
b.barracudacentral.org*1, psbl.surriel.com*1
postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
recipient_delimiter = +
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtpd_client_connection_count_limit = 5
smtpd_client_connection_rate_limit = 20
smtpd_client_new_tls_session_rate_limit = 20
smtpd_client_recipient_rate_limit = 50
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, permit
smtpd_delay_reject = yes
smtpd_error_sleep_time = 10s
smtpd_hard_error_limit = 6
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_invalid_hostname, permit
smtpd_recipient_limit = 100
smtpd_recipient_restrictions = permit_mynetworks, reject_unlisted_recipient, 
permit_sasl_authenticated, check_recipient_access 
hash:/var/postfix/blocked_addresses, reject_unauth_pipelining, 
reject_unauth_destination, check_policy_service unix:private/policyd-spf, 
warn_if_reject reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, 
reject_unknown_recipient_domain, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_auth_destination, check_sender_access 
hash:/var/postfix/invalid_addresses, permit_mynetworks, 
permit_sasl_authenticated, reject_sender_login_mismatch, 
reject_non_fqdn_sender, reject_unknown_sender_domain, check_client_access 
hash:/var/postfix/client_access, check_sender_access 
hash:/var/postfix/sender_access, permit
smtpd_soft_error_limit = 3
smtpd_tls_CAfile = /VEX/certs/comodo.cert
smtpd_tls_cert_file = /VEX/certs/vex.net.cert
smtpd_tls_key_file = /etc/certs/vex.net.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_mailbox_limit = 0
virtual_maps = hash:/etc/postfix/virtual

Re: Why am I accepting this email?

[Benny Pedersen]

D'Arcy Cain skrev den 2017-05-24 15:25:

The following is in my logs.


provide postconf -n to get more help

Why am I accepting this email?

[D'Arcy Cain]

The following is in my logs.  I have no server called nan.vex.net and no
user called aida.wanda.  I don't see anything in main.cf that looks like
a wild card entry.  Can anyone suggest why I would be accepting this
message in the first place?  I really don't want to back-scatter.

May 22 20:11:59 smaug postfix/smtpd[5457]: BBA8F3F9F1CA: 
client=mx-n07.wc1.phx1.stabletransit.com[207.246.241.253]
May 22 20:11:59 smaug postfix/cleanup[8796]: BBA8F3F9F1CA: 
message-id=<20170523001149.8c76f642...@mx-n07.wc1.phx1.stabletransit.com>
May 22 20:12:00 smaug postfix/qmgr[347]: BBA8F3F9F1CA: 
from=, size=22692, nrcpt=1 (queue active)
May 22 20:12:00 smaug postfix/smtp[9232]: BBA8F3F9F1CA: 
to=, relay=none, delay=0.34, delays=0.33/0.01/0/0, 
dsn=5.4.6, status=bounced (mail for nan.vex.net loops back to myself)
May 22 20:12:00 smaug postfix/bounce[3630]: BBA8F3F9F1CA: sender non-delivery 
notification: 1D2793F9F1D8
May 22 20:12:00 smaug postfix/qmgr[347]: BBA8F3F9F1CA: removed

-- 
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net

Recipient Restrictions

[GP]

Hi all,

is it possible to have restrictions that apply to certain users only
with postfix ?
For example I want some users not to be able to send or receive messages
more than 2MB in size  . Can it be done ?

George

Re: TLS warning

[lists]

The industry/market/whatever decided the best practice was to stop using ssl3.  
This wasn't my call. 

Postfix conf file instructions here as well as more information why to stop 
using it.
http://disablessl3.com/





  Original Message  
From: Bastian Blank
Sent: Wednesday, May 24, 2017 5:55 AM
To: postfix-users@postfix.org
Subject: Re: TLS warning

Hi Lists

On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com wrote:
> ‎You shouldn't be accepting sslv3 due to the poodle attack.
> https://en.m.wikipedia.org/wiki/POODLE

Please explain how exactly SMTP is exploitable using POODLE?

Bastian

-- 
Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
-- Kirk, "The Conscience of the King", stardate 2818.9

Re: TLS warning

[Bastian Blank]

Hi Lists

On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com wrote:
> ‎You shouldn't be accepting sslv3 due to the poodle attack.
> https://en.m.wikipedia.org/wiki/POODLE

Please explain how exactly SMTP is exploitable using POODLE?

Bastian

-- 
Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
-- Kirk, "The Conscience of the King", stardate 2818.9

Re: TLS warning

[lists]

‎You shouldn't be accepting sslv3 due to the poodle attack.

https://en.m.wikipedia.org/wiki/POODLE

A search should indicate what to change to reject sslv3.

Of course there still could be other things that need fixing. ;-)

  Original Message  
From: Rick Leir
Sent: Wednesday, May 24, 2017 2:31 AM
To: postfix-users@postfix.org
Subject: TLS warning

Hi All

Should this TLS warning worry me?

cheers -- Rick


Warnings



smtpd (total: 1)

1 TLS library problem: error:14094416:SSL routines:SSL3_READ_BYTE...

mail.log:

May 23 11:35:42 myHostName postfix/smtpd[6619]: connect from 
sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

May 23 11:35:43 myHostName postfix/smtpd[6619]: SSL_accept error from 
sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]: 0

May 23 11:35:43 myHostName postfix/smtpd[6619]: warning: TLS library problem: 
error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate 
unknown:s3_pkt.c:1262:SSL alert number 46:

May 23 11:35:43 myHostName postfix/smtpd[6619]: lost connection after STARTTLS 
from sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

May 23 11:35:43 myHostName postfix/smtpd[6619]: disconnect from 
sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

May 23 11:35:43 myHostName postfix/postscreen[6613]: CONNECT from 
[66.163.186.208]:33240 to [myIPv4]:25

May 23 11:35:43 myHostName postfix/postscreen[6613]: PASS OLD 
[66.163.186.208]:33240

May 23 11:35:43 myHostName postfix/smtpd[6619]: connect from 
sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

May 23 11:35:43 myHostName postfix/smtpd[6619]: 6C9CF41E45: 
client=sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

# apt-cache depends postfix

Depends: libsasl2-2

Depends: libssl1.0.0

Depends: ssl-cert

Suggests: sasl2-bin

Suggests: libsasl2-modules

# apt-cache madison libsasl2-2

libsasl2-2 | 2.1.25.dfsg1-17build1 | 
http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

cyrus-sasl2 | 2.1.25.dfsg1-17build1 | 
http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty/main Sources

# apt-cache madison libssl1.0.0

libssl1.0.0 | 1.0.1f-1ubuntu2.22 | 
http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 
Packages

libssl1.0.0 | 1.0.1f-1ubuntu2.22 | http://security.ubuntu.com/ubuntu/ 
trusty-security/main amd64 Packages

libssl1.0.0 | 1.0.1f-1ubuntu2 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ 
trusty/main amd64 Packages

openssl | 1.0.1f-1ubuntu2 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ 
trusty/main Sources

openssl | 1.0.1f-1ubuntu2.22 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ 
trusty-updates/main Sources

openssl | 1.0.1f-1ubuntu2.22 | http://security.ubuntu.com/ubuntu/ 
trusty-security/main Sources

TLS warning

[Rick Leir]

Hi All

Should this TLS warning worry me?

cheers -- Rick


Warnings



  smtpd (total: 1)

 1   TLS library problem: error:14094416:SSL routines:SSL3_READ_BYTE...

mail.log:

May 23 11:35:42 myHostName postfix/smtpd[6619]: connect from 
sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

May 23 11:35:43 myHostName postfix/smtpd[6619]: SSL_accept error from 
sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]: 0

May 23 11:35:43 myHostName postfix/smtpd[6619]: warning: TLS library problem: 
error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate 
unknown:s3_pkt.c:1262:SSL alert number 46:

May 23 11:35:43 myHostName postfix/smtpd[6619]: lost connection after STARTTLS 
from sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

May 23 11:35:43 myHostName postfix/smtpd[6619]: disconnect from 
sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

May 23 11:35:43 myHostName postfix/postscreen[6613]: CONNECT from 
[66.163.186.208]:33240 to [myIPv4]:25

May 23 11:35:43 myHostName postfix/postscreen[6613]: PASS OLD 
[66.163.186.208]:33240

May 23 11:35:43 myHostName postfix/smtpd[6619]: connect from 
sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

May 23 11:35:43 myHostName postfix/smtpd[6619]: 6C9CF41E45: 
client=sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]

# apt-cache depends postfix

  Depends: libsasl2-2

  Depends: libssl1.0.0

  Depends: ssl-cert

  Suggests: sasl2-bin

  Suggests: libsasl2-modules

# apt-cache madison libsasl2-2

libsasl2-2 | 2.1.25.dfsg1-17build1 | 
http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

cyrus-sasl2 | 2.1.25.dfsg1-17build1 | 
http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty/main Sources

# apt-cache madison libssl1.0.0

libssl1.0.0 | 1.0.1f-1ubuntu2.22 | 
http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 
Packages

libssl1.0.0 | 1.0.1f-1ubuntu2.22 | http://security.ubuntu.com/ubuntu/ 
trusty-security/main amd64 Packages

libssl1.0.0 | 1.0.1f-1ubuntu2 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ 
trusty/main amd64 Packages

   openssl | 1.0.1f-1ubuntu2 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ 
trusty/main Sources

   openssl | 1.0.1f-1ubuntu2.22 | 
http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main Sources

   openssl | 1.0.1f-1ubuntu2.22 | http://security.ubuntu.com/ubuntu/ 
trusty-security/main Sources