Re: restricted inbound on 587

2021-01-18 Thread Gary Aitken

On 1/17/21 9:53 AM, Matus UHLAR - fantomas wrote:

On 1/16/21 4:04 PM, Jaroslaw Rafa wrote:

Dnia 16.01.2021 o godz. 15:11:58 Gary Aitken pisze:

  1. Why is it attempting to send mail on port 25 and not 587?


Because that's the usual port MTA tries to connect to when sending mail. You
didn't specify anywhere in your configuration that there should be a
connection to port 587.


On 16.01.21 21:14, Gary Aitken wrote:

I thought the changes to master.cf (commenting out smtp and uncommenting
submission) changed that?


this way, you have closed port 25 which is why yor postfix can't connect to
itself.


Thanks.


If not, how do I set outgoing to 587 only?


by using relayhost, default_transport, transport_maps or other feature.


Ah,  Thanks, default_transport is what I was looking for, will try that.

Gary


Re: restricted inbound on 587

2021-01-18 Thread Gary Aitken

On 1/17/21 12:30 AM, Viktor Dukhovni wrote:

On Sat, Jan 16, 2021 at 11:37:50PM -0700, Gary Aitken wrote:


 /etc/postfix/master.cf:
   #smtp  inet  n   -   y   -   -   smtpd
   submission inet n   -   y   -   -   smtpd


This looks like a submission service, so you would generally require
TLS.


Yes, I assume that's a hint I need
smtp_use_tls=yes


No, that's the obsolete syntax to enable opportunistic outbound (SMTP
client) TLS, but you need mandatory inbound (SMTP server) TLS.

 smtpd_tls_security_level = encrypt


The issue *is* with outbound; I need outbound to 587 and inbound on 587.


Do I need others besides smtp_tls_cert_file and smtp_tls_key_file?


Neither have anything to do with inbound TLS, and you generally don't
need client certificates.  The right parameters are:

 smtpd_tls_cert_file
 smtpd_tls_key_file


Those are already set for inbound.


and if you have both the cert and the key in the same file then
just the "cert" one will do.


Thanks.


You have nothing in your configuration that would direct outbound
traffic to port 587, and it is likely not what you want anyway.
Does "xx.com" really receive inbound email on port 587?  If so,
you'd need a transport table entry to send it there, and probably
SASL to authenticate your access to that service.


In this case the destination address does listen on 587.
Why is it not likely what I want?


Because you did not explain that this is a relayhost.  Your message said
that you sent outbound mail to just that domain, not that you were using
that domain as a relayhost.  Which is it?


That domain and its mx server serves as both a destination and a relay
host if necessary.  In this case I would like it to be only a destination,
but at the moment the only way I have been able to get postfix to contact
it on 587 is to have postfix treat it as a relayhost.

I think the issue is I need to specify default_transport as suggested by
Matus; I will try that.


The recipient domain is not listed in mydestination; but shouldn't it be
contacting the MX host of the recipient domain rather than itself?


Now you're really confusing things.  If you want delivery to port 587 of
a relayhost (submission service smarthost that figures how where to
route the mail), then the MX records of the recipient domain are
irrelevant.  If you want to deliver to the MX host of domain you'd want
to use port 25, which is where domains receive inbound mail.

It seems you're rather confused abou† what you want...


I'm certainly confused about how to accomplish it...
The postfix server is inside the google cloud, and google blocks port 25.
That's why I need it to go out to 587, not 25.

Thanks,

Gary


Re: virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)

2021-01-18 Thread Matus UHLAR - fantomas

On 18.01.21 12:45, Daniel Caillibaud wrote:
>After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems 
to be ignored
>(mail to aliases address are bounced with "user unknown"), and I don't find 
why…



Le 18/01/21 à 13:13, Matus UHLAR - fantomas  a écrit :

you turned on:
>receive_override_options = no_address_mappings

and while amavisd worked as post-queue filter, thus received mail and sent
back through port 10024 where virtual aliases were xpanded, rspamd workd as 
milter,
thus does not send back to postfix.


On 18.01.21 14:52, Daniel Caillibaud wrote:

Thanks a lot for pointing this out !

(it was necessary with amavis to avoid double mail on aliases, no mapping 
before amavis and
receive_override_options=no_unknown_recipient_checks,no_header_body_checks 
precised in master
cf for the 2nd treatment by postfix on the way back)


I use it on port 10024. That way, amavis knows real recipients.
Also, I use amavisd-milter on mail received on port 25.

--
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.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."


Re: virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)

2021-01-18 Thread Daniel Caillibaud
Le 18/01/21 à 13:13, Matus UHLAR - fantomas  a écrit :
> On 18.01.21 12:45, Daniel Caillibaud wrote:
> >After switching to rspamd (was amavis+spamassassin), virtual_alias_maps 
> >seems to be ignored
> >(mail to aliases address are bounced with "user unknown"), and I don't find 
> >why…  
> 
> you turned on:
> >receive_override_options = no_address_mappings  
> 
> and while amavisd worked as post-queue filter, thus received mail and sent
> back through port 10024 where virtual aliases were xpanded, rspamd workd as 
> milter,
> thus does not send back to postfix.

Thanks a lot for pointing this out !

(it was necessary with amavis to avoid double mail on aliases, no mapping 
before amavis and
receive_override_options=no_unknown_recipient_checks,no_header_body_checks 
precised in master
cf for the 2nd treatment by postfix on the way back)

-- 
Daniel

Le café est un breuvage qui fait dormir,
quand on n'en prend pas.
Alphonse Allais


Re: virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)

2021-01-18 Thread Matus UHLAR - fantomas

On 18.01.21 12:45, Daniel Caillibaud wrote:

After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems 
to be ignored
(mail to aliases address are bounced with "user unknown"), and I don't find why…


you turned on:

receive_override_options = no_address_mappings


and while amavisd worked as post-queue filter, thus received mail and sent
back through port 10024 where virtual aliases were xpanded, rspamd workd as 
milter,
thus does not send back to postfix.


1) Before (all is fine with virtual_alias_maps)

content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 3
smtpd_milters = 
unix:run/opendkim/opendkim.sock,unix:run/opendmarc/opendmarc.sock
non_smtpd_milters = $smtpd_milters
milter_connect_macros = j


2) after (virtual_alias_maps ignored)
# content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 6
milter_default_action = tempfail
smtpd_milters = inet:localhost:11332
non_smtpd_milters = $smtpd_milters
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}




Here is a log of a mail ok with 1)

postfix/pickup[25504]: 18D8F222ED4: uid=0 from=
postfix/cleanup[27187]: 18D8F222ED4: 
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
opendkim[5572]: 18D8F222ED4: DKIM-Signature field added (s=mail, d=sesamath.net)
postfix/qmgr[25505]: 18D8F222ED4: from=, size=654, nrcpt=1 
(queue active)
postfix/smtpd[27196]: 4822622194E: client=localhost[127.0.0.1]
postfix/cleanup[27187]: 4822622194E: 
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
postfix/qmgr[25505]: 4822622194E: from=, size=1483, 
nrcpt=1 (queue active)
amavis[20707]: (20707-14) Passed CLEAN {RelayedInbound}, [127.0.0.1]  
-> , Message-ID: 
<20210118105545.18d8f222...@mail.sesamath.net>, mail_id: kvP9WKxhumWJ, Hits: -1.791, size: 
988, queued_as: 4822622194E, 211 ms
postfix/smtp[27192]: 18D8F222ED4: to=, orig_to=, 
relay=127.0.0.1[127.0.0.1]:10024, delay=0.28, delays=0.07/0/0/0.21, dsn=2.0.0, status=sent 
(250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4822622194E)
postfix/qmgr[25505]: 18D8F222ED4: removed
postfix/pipe[27197]: 4822622194E: to=, 
orig_to=, relay=dovecot, delay=0.15, delays=0.03/0/0/0.12, 
dsn=2.0.0, status=sent (delivered via dovecot service)
postfix/qmgr[25505]: 4822622194E: removed


and the same test ko with 2)

postfix/pickup[24882]: 6DD04222ED4: uid=0 from=
postfix/cleanup[24914]: 6DD04222ED4: 
message-id=<20210118103925.6dd04222...@mail.sesamath.net>
postfix/qmgr[24883]: 6DD04222ED4: from=, size=383, nrcpt=1 
(queue active)
postfix/pipe[24920]: 6DD04222ED4: to=, orig_to=, 
relay=dovecot, delay=0.14, delays=0.09/0.01/0/0.05, dsn=5.1.1, status=bounced (user unknown)
postfix/bounce[24922]: 6DD04222ED4: sender non-delivery notification: 
87950222EDA
postfix/qmgr[24883]: 6DD04222ED4: removed



--
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.
I intend to live forever - so far so good.


virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)

2021-01-18 Thread Daniel Caillibaud
Hi,

After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems 
to be ignored
(mail to aliases address are bounced with "user unknown"), and I don't find why…


1) Before (all is fine with virtual_alias_maps)

content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 3
smtpd_milters = 
unix:run/opendkim/opendkim.sock,unix:run/opendmarc/opendmarc.sock
non_smtpd_milters = $smtpd_milters
milter_connect_macros = j


2) after (virtual_alias_maps ignored)
# content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 6
milter_default_action = tempfail
smtpd_milters = inet:localhost:11332
non_smtpd_milters = $smtpd_milters
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}


All others lines are identicals, especially
virtual_alias_maps = 
mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-sympa-virtual_alias_maps.cf

Any clue ?

Thanks




Here is a log of a mail ok with 1)

postfix/pickup[25504]: 18D8F222ED4: uid=0 from=
postfix/cleanup[27187]: 18D8F222ED4: 
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
opendkim[5572]: 18D8F222ED4: DKIM-Signature field added (s=mail, d=sesamath.net)
postfix/qmgr[25505]: 18D8F222ED4: from=, size=654, nrcpt=1 
(queue active)
postfix/smtpd[27196]: 4822622194E: client=localhost[127.0.0.1]
postfix/cleanup[27187]: 4822622194E: 
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
postfix/qmgr[25505]: 4822622194E: from=, size=1483, 
nrcpt=1 (queue active)
amavis[20707]: (20707-14) Passed CLEAN {RelayedInbound}, [127.0.0.1] 
 -> , Message-ID: 
<20210118105545.18d8f222...@mail.sesamath.net>, mail_id: kvP9WKxhumWJ, Hits: 
-1.791, size: 988, queued_as: 4822622194E, 211 ms
postfix/smtp[27192]: 18D8F222ED4: to=, orig_to=, 
relay=127.0.0.1[127.0.0.1]:10024, delay=0.28, delays=0.07/0/0/0.21, dsn=2.0.0, 
status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued 
as 4822622194E)
postfix/qmgr[25505]: 18D8F222ED4: removed
postfix/pipe[27197]: 4822622194E: to=, 
orig_to=, relay=dovecot, delay=0.15, 
delays=0.03/0/0/0.12, dsn=2.0.0, status=sent (delivered via dovecot service)
postfix/qmgr[25505]: 4822622194E: removed


and the same test ko with 2)

postfix/pickup[24882]: 6DD04222ED4: uid=0 from=
postfix/cleanup[24914]: 6DD04222ED4: 
message-id=<20210118103925.6dd04222...@mail.sesamath.net>
postfix/qmgr[24883]: 6DD04222ED4: from=, size=383, nrcpt=1 
(queue active)
postfix/pipe[24920]: 6DD04222ED4: to=, orig_to=, 
relay=dovecot, delay=0.14, delays=0.09/0.01/0/0.05, dsn=5.1.1, status=bounced 
(user unknown)
postfix/bounce[24922]: 6DD04222ED4: sender non-delivery notification: 
87950222EDA
postfix/qmgr[24883]: 6DD04222ED4: removed



Just in case, the full postconf -n

1)
alias_maps = hash:/etc/aliases
anvil_rate_time_unit = 60s
append_dot_mydomain = no
biff = no
bounce_template_file = /etc/postfix/bounce_templates.cf
broken_sasl_auth_clients = yes
compatibility_level = 2
content_filter = amavis:[127.0.0.1]:10024
default_destination_concurrency_limit = 5
default_destination_rate_delay = 1s
default_destination_recipient_limit = 30
delay_warning_time = 1h
dovecot_destination_recipient_limit = 1
header_checks = pcre:/etc/postfix/header_checks.pcre
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
laposte_destination_concurrency_limit = 1
laposte_destination_rate_delay = 1s
laposte_destination_recipient_limit = 1
milter_connect_macros = j
milter_protocol = 3
mydestination = $myhostname
mydomain = sesamath.net
myhostname = mail.sesamath.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.0.0/16
mynetworks_style = subnet
myorigin = $mydomain
non_smtpd_milters = $smtpd_milters
readme_directory = /usr/share/doc/postfix
receive_override_options = no_address_mappings
recipient_delimiter = _
relay_domains = $mydestination
relayhost =
sender_dependent_relayhost_maps = 
regexp:/etc/postfix/sender_dependent_relayhost_maps.regexp
slow_destination_concurrency_limit = 2
slow_destination_recipient_limit = 5
smtp_generic_maps = hash:/etc/postfix/smtp_generic_maps.hash
smtp_tls_fingerprint_digest = sha256
smtp_tls_loglevel = 2
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 30
smtpd_client_recipient_rate_limit = 30
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_unknown_reverse_client_hostname reject_unknown_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_milters = 
unix:run/opendkim/opendkim.sock,unix:run/opendmarc/opendmarc.sock
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_unauth_destination reject_unknown_recipient_domain 
reject_non_fqdn_recipient reject_rbl_client sbl-xbl.spamhaus.org 
reject_rbl_client psbl.surriel.com check_policy_service unix:private/spfcheck