Re: How to tell my ISP there's a problem
On Monday, 17 June 2019 7:48:05 PM AEST Chris Pollock wrote: > Apologies if the subject is vague however I'll attempt to explain > further. I run a cron job once a day that updates my Spamassassin > rules. Up until a couple of weeks ago I would get the output of that > cron job mailed to me. For some reason this is the only cron job output > that's not coming back. I've determined that size it not a factor since > some of my hourly logcheck messages are up to 400k if a restart has > taken place. Below is the output when it was working and the output > since them. I can't see a difference so it has to be something at my > ISP with just this one cron job but I can't see it. > > https://pastebin.com/v0rMErQh > > Thanks for any suggestions Maybe it's going to a spam folder. I notice that the reply from your isp says 250 SPF validation soft failure in both cases, but if they stopped forwarding "potentially forged" emails that might be a possible cause. It is definitely the behaviour on smtp.embarqmail.com that has changed though, so you need to ask the administrators of that server. Is this direct to MX or is it a fixed relay intended to be a smarthost?
Re: How to tell my ISP there's a problem
On Mon, 17 Jun 2019 19:48:05 -0500 Chris Pollock wrote: > Apologies if the subject is vague however I'll attempt to explain > further. I run a cron job once a day that updates my Spamassassin > rules. Up until a couple of weeks ago I would get the output of that > cron job mailed to me. For some reason this is the only cron job > output that's not coming back. I've determined that size it not a > factor since some of my hourly logcheck messages are up to 400k if a > restart has taken place. Below is the output when it was working and > the output since them. I can't see a difference so it has to be > something at my ISP with just this one cron job but I can't see it. > > https://pastebin.com/v0rMErQh > > Thanks for any suggestions > This doesn't sound like an issue coming from your ISP since the rest of your smtp traffic is passing through - ISPs would block all traffic on port 25 for example. The information you provided is limited but I would start with what might have changed in your system the last couple of weeks and then try to run the job manually and see if there is any traffic generated going to the smtp daemon. Nektarios Katakis. pgpXHiyuRd_xn.pgp Description: OpenPGP digital signature
How to tell my ISP there's a problem
Apologies if the subject is vague however I'll attempt to explain further. I run a cron job once a day that updates my Spamassassin rules. Up until a couple of weeks ago I would get the output of that cron job mailed to me. For some reason this is the only cron job output that's not coming back. I've determined that size it not a factor since some of my hourly logcheck messages are up to 400k if a restart has taken place. Below is the output when it was working and the output since them. I can't see a difference so it has to be something at my ISP with just this one cron job but I can't see it. https://pastebin.com/v0rMErQh Thanks for any suggestions -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 17:58:24 up 1:02, 1 user, load average: 0.95, 0.82, 0.71 Description:Ubuntu 18.04.2 LTS, kernel 4.18.0-22-generic signature.asc Description: This is a digitally signed message part
Re: Stats recommendations?
we're pulling all kind of logs and graph them in fancy ways with zabbix. zabbix has a small client with tiny footprint and can do encrypted transfer of logs/data to server. Am Mo., 17. Juni 2019 um 22:20 Uhr schrieb PGNet Dev : > I'm aware of the list of stats tools > >http://www.postfix.org/addon.html > > Looking for experience/recommendations from users here. > > grep's served me well enough for just a few servers. > > As I switch to all/only Postfix at multiple locations, something easily > automated/deployed is of interest. > DIY is doable; I'd prefer a product/project that's still actively > maintained. > > I'm looking for as lightweight as possible. > > I'm OK with just scheduled text/emailed reports; usual prefer them to > visual displays, whether static or dynamic/realtime, anyway. > > > What are folks here using & happy with? >
Stats recommendations?
I'm aware of the list of stats tools http://www.postfix.org/addon.html Looking for experience/recommendations from users here. grep's served me well enough for just a few servers. As I switch to all/only Postfix at multiple locations, something easily automated/deployed is of interest. DIY is doable; I'd prefer a product/project that's still actively maintained. I'm looking for as lightweight as possible. I'm OK with just scheduled text/emailed reports; usual prefer them to visual displays, whether static or dynamic/realtime, anyway. What are folks here using & happy with?
Re: authenticate o365 users with postfix without smtp auth
As microsoft ofers DKIM-singing for outgoing mails at no extra cost, i will validate this information as 3rd authentication token. Looks much clearer and several addons for postfix exist to do so. Am Mo., 17. Juni 2019 um 21:31 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > > The latter is simply conservative design. There is no need to forward > this information, and a receiving system might object to receiving > XOORG from a Postfix machine that isn't authorized to send it. > > Wietse >
Re: Header change
On Jun 17, 2019, at 12:07 PM, Wietse Venema wrote:
> @lbutlr:
>> Received: from darth.lan (c-73-14.161.160.hsd1.co.comcast.net =
>> [73.14.161.160])
>> by mail.covisp.net(Postfix 3.4.5/8.13.0) with SMTP id unknown;
>> Sun, 16 Jun 2019 15:26:32 -0600
>> (envelope-from )
>
> As far as I know, Postfix does not have "with ... id unknown", and
> the "(envelope-from ...)" text is disabled by default.
From what I am hearing not he SA list, this header is added by spamass-milter
which is not seeing the message as having been submitted with authentication.
I have not changed milter_mail_macros from the default value of
i {auth_type} {auth_authen} {auth_author} {mail_addr} {mail_host} {mail_mailer}
So I am not sure why the milter is not seeing that the message was
authenticated.
Logs:
Jun 16 15:26:32 mail postfix/submit/smtpd[52711]: 45RnTh0J8KzdrvJ:
client=c-73-14-161-160.hsd1.co.comcast.net[73.14.161.160], sasl_method=PLAIN,
sasl_username=kr...@kreme.com
Jun 16 15:26:32 mail postfix/cleanup[52845]: 45RnTh0J8KzdrvJ:
message-id=<0c3be5f6-c5b4-4b07-853d-fad6dcbb6...@kreme.com>
Jun 16 15:26:33 mail postfix/qmgr[27634]: 45RnTh0J8KzdrvJ:
from=, size=3259, nrcpt=2 (queue active)
Jun 16 15:26:33 mail postfix/lmtp[53026]: 45RnTh0J8KzdrvJ: to=,
orig_to=, relay=mail.covisp.net[private/dovecot-lmtp], delay=1.9,
delays=1.7/0.01/0.19/0.01, dsn=2.0.0, status=sent (250 2.0.0
1QOYNQm0Bl1fzwAAIdGjjQ:2 Saved)
Jun 16 15:26:33 mail postfix/qmgr[27634]: 45RnTh0J8KzdrvJ: removed
Header:
Received: from darth.lan (c-73-14.161.160.hsd1.co.comcast.net [73.14.161.160])
by mail.covisp.net(Postfix 3.4.5/8.13.0) with SMTP id unknown;
Sun, 16 Jun 2019 15:26:32 -0600
(envelope-from )
--
Han : You said you wanted to be around when I made a mistake, well, this
could be it, sweetheart. Leia: I take it back.
Re: authenticate o365 users with postfix without smtp auth
Viktor Dukhovni: > On Mon, Jun 17, 2019 at 02:29:05PM -0400, Wietse Venema wrote: > > > I suppose that Postfix will need to forward the OORG information > > that it received from the Microsoft server, not a name that is > > hard-coded in main.cf, and that Postfix will need to send that > > information only to systems that should receive it, not to random > > systems on the Internet. > > XOORG would need to be accepted only from suitably authenticated > and authorized clients (those trusted to deliver authentic information). > > XOORG feels clumsy, a cleaner choice would be DKIM, which supports > passage through untrusted relays, ... but at the cost of breaking > when the content is modified. XOORG on the other admits content > modification, ... but at the cost of requiring trusted relays. > > If we're willing to generally forward DKIM signatures, I am not > sure that XOORG needs censoring on the outbound leg, when trusted > on the inbound leg. The latter is simply conservative design. There is no need to forward this information, and a receiving system might object to receiving XOORG from a Postfix machine that isn't authorized to send it. Wietse
Re: 5.7.1 issue relaying telnet, on same host
On Mon, Jun 17, 2019 at 02:36:49PM -0400, David Mehler wrote: > Jun 17 13:47:49 mail postfix/smtpd[29888]: NOQUEUE: reject: RCPT from > mail.example.local[172.16.21.3]: 554 5.7.1 : Relay > access denied; from= to= proto=ESMTP > helo= > > mydestination = 172.16.21.3 That's a weird setting, it is not a valid email domain. > mynetworks = $config_directory/mynetworks Care to share the contents of that file? > smtpd_relay_restrictions = > permit_sasl_authenticated > reject_unauth_destination I don't see a "permit_mynetworks" here, so relay access requires SASL... -- Viktor.
Re: Header change
On Mon, Jun 17, 2019 at 10:36:38AM -0600, @lbutlr wrote: > Switching to dovecot LMTP appears to have changed the information in the > received header: The reported symptoms are unrelated to Dovecot LMTP. > Here’s what the received header used to look like: > > Received: from [10.0.5.3] (c-71-229-144-93.hsd1.co.comcast.net > [71.229.144.93]) > by mail.covisp.net (Postfix) with ESMTPS id B67B8118AD59 > for ; Sun, 16 Aug 2009 22:19:02 -0600 (MDT) > > As opposed to now: > > Received: from darth.lan (c-73-14.161.160.hsd1.co.comcast.net [73.14.161.160]) > by mail.covisp.net(Postfix 3.4.5/8.13.0) with SMTP id unknown; > Sun, 16 Jun 2019 15:26:32 -0600 > (envelope-from ) This may be produced by a milter, especially the "8.13.0" suggests a Sendmail milter library. The "Postfix 3.4.5" may be due to a non-default setting of "mail_name". As for "unknown" the milter (if that's what it is) may have memoized absence of a queue-id before Postfix assigned one (at RCPT TO). -- Viktor.
Re: authenticate o365 users with postfix without smtp auth
On Mon, Jun 17, 2019 at 02:29:05PM -0400, Wietse Venema wrote: > I suppose that Postfix will need to forward the OORG information > that it received from the Microsoft server, not a name that is > hard-coded in main.cf, and that Postfix will need to send that > information only to systems that should receive it, not to random > systems on the Internet. XOORG would need to be accepted only from suitably authenticated and authorized clients (those trusted to deliver authentic information). XOORG feels clumsy, a cleaner choice would be DKIM, which supports passage through untrusted relays, ... but at the cost of breaking when the content is modified. XOORG on the other admits content modification, ... but at the cost of requiring trusted relays. If we're willing to generally forward DKIM signatures, I am not sure that XOORG needs censoring on the outbound leg, when trusted on the inbound leg. -- Viktor.
5.7.1 issue relaying telnet, on same host
Hello,
I'm trying to get a new mail server going. It's running in a FreeBSD
12.0 jail and it's postfix 3.4.5, and dovecot 2.3.6. The machine's ip
is 172.16.21.3 i'm telnetting I'm on the host and telnetting to the
server on port 25 after rcpt I'm getting:
Jun 17 13:47:49 mail postfix/smtpd[29888]: NOQUEUE: reject: RCPT from
mail.example.local[172.16.21.3]: 554 5.7.1 : Relay
access denied; from= to= proto=ESMTP
helo=
I believe I've got a configuration issue with my *restrictions, i'd
appreciate any suggestions. I've got a full postconf -n later. All of
my users are virtual in a mysql database, the db communication is
working fine and returning the appropriate results.
Thanks.
Dave.
main.cf (snipet):
inet_interfaces = 172.16.21.3
mydestination = 172.16.21.3
mynetworks = $config_directory/mynetworks
# Dovecot sasl authentication
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_local_domain = $mydomain
broken_sasl_auth_clients = no
smtpd_sasl_security_options = noanonymous
# but plaintext auth is fine when using TLS
smtpd_sasl_tls_security_options = noanonymous
# Restrictions for all sending foreign servers ("SMTP clients")
smtpd_client_restrictions =
permit_sasl_authenticated
reject_unknown_reverse_client_hostname
check_client_access cidr:/usr/local/etc/postfix/spamfarms
check_client_access cidr:/usr/local/etc/postfix/sinokorea.cidr
check_reverse_client_hostname_access
pcre:/usr/local/etc/postfix/fqrdns.pcre
# helo restrictions
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
check_helo_access hash:/usr/local/etc/postfix/helo_access,
# sender restrictions
smtpd_sender_restrictions =
reject_non_fqdn_sender
reject_unknown_sender_domain
,check_sender_mx_access cidr:/usr/local/etc/postfix/bogus_mx
check_sender_access hash:/usr/local/etc/postfix/safe_addresses
check_sender_access hash:/usr/local/etc/postfix/auto-whtlst
smtpd_relay_restrictions =
permit_sasl_authenticated
reject_unauth_destination
smtpd_recipient_restrictions =
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unauth_pipelining
permit_dnswl_client list.dnswl.org=127.0.[2..14].[1..3]
reject_unlisted_recipient
# TLS parameters
smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_auth_only = no
smtpd_tls_eccert_file = /usr/local/etc/ssl/acme.sh/example.com/fullchain.crt
smtpd_tls_eckey_file =
/usr/local/etc/ssl/acme.sh/example.com/private/server-ec256.key
smtpd_tls_CAfile = /usr/local/etc/ssl/acme.sh/example.com/cacert.crt
smtpd_tls_eecdh_grade = ultra
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1 !TLSv1.1 TLSv1.2
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1 !TLSv1.1 TLSv1.2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4,
MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES,
CBC3-SHA
smtpd_tls_exclude_ciphers = $smtpd_tls_mandatory_exclude_ciphers
smtpd_tls_security_level = may
smtpd_tls_dh1024_param_file = /usr/local/etc/postfix/dh.pem
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_received_header = yes
tls_preempt_cipherlist = yes
tls_high_cipherlist =
ECDH+AESGCM:ECDH+CHACHA20:ECDH+AES256:ECDH+AES128:!aNULL:!SHA1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_ciphers = high
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_protocols=!SSLv2,!SSLv3, !TLSv1
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3, !TLSv1
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4,
MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5,
CBC3-SHA
smtp_tls_ciphers = high
smtp_tls_cert_file = $smtpd_tls_cert_file
smtp_tls_key_file = $smtpd_tls_key_file
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
mua_relay_restrictions =
reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
mua_sender_restrictions =
permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
mua_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject
Re: authenticate o365 users with postfix without smtp auth
Emmanuel Fust?: > Le 17/06/2019 ? 12:05, Emmanuel Fust? a ?crit?: > > Le 16/06/2019 ? 22:37, Viktor Dukhovni a ?crit?: > >> On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote: > >> > >>> Some of our users use o365 but would like to use our service for > >>> outgoing > >>> mails.? We are offering smtp sending services.? Integrating our > >>> service in > >>> o365 is tricky, as one can only specify a smarthost but microsoft > >>> does not > >>> offer any kind of authentication for smarthosts. > >> Are these individual users or cloud-hosted domains?? Who's authorized > >> to ask Microsoft to route their outbound traffic through your relay? > >> Can you distinguish one such Office365 sender from another? ... > >> > >> What's the point (if I may ask) of having their mail sent through > >> your relay?? I assume that Microsoft could quite easily send their > >> outbound traffic directly to its destination. > >> > > Cloud-hosted domains is "hosting" service. You have the control on the > > outbound routing. > > There is many reason why you want your outbound traffic not directly > > delivered to its destination. > > Some want to provide "value added services". In my case is is because > > the o365 users are only a fraction of my users (hybrid cloud mode) and > > that inboud/ouboud internet mails policy/routing/delivery is under the > > control of another infrastructure. > > > > Microsoft is always? presenting a client certificate. That the only > > way to authenticate O365. (the experimental certificate matching will > > help you) I suppose that Postfix should not accept arbitrary client certificates, so this certificate check will need to be configurable. > > The "proper" Microsoft way is to use their proprietary XOORG SMTP > > extension used in their hybrid cloud scenario. > > => after having authenticated o365 with the presented client > > certificate, if you announce the XOORG extension in the EHLO, o365 > > will provide you the remote o365 organization (in the "MS Exchange" > > sense) as part of the MAIL FROM verb. > > MAIL FROM: OORG=my-organization.com ... > Replying to myself, attached is the client patch for Postfix. I suppose that Postfix will need to forward the OORG information that it received from the Microsoft server, not a name that is hard-coded in main.cf, and that Postfix will need to send that information only to systems that should receive it, not to random systems on the Internet. Wietse
Re: Header change
@lbutlr: > Received: from darth.lan (c-73-14.161.160.hsd1.co.comcast.net = > [73.14.161.160]) > by mail.covisp.net(Postfix 3.4.5/8.13.0) with SMTP id unknown; > Sun, 16 Jun 2019 15:26:32 -0600 > (envelope-from ) As far as I know, Postfix does not have "with ... id unknown", and the "(envelope-from ...)" text is disabled by default. Wietse
Header change
Switching to dovecot LMTP appears to have changed the information in the received header: Here’s what the received header used to look like: Received: from [10.0.5.3] (c-71-229-144-93.hsd1.co.comcast.net [71.229.144.93]) by mail.covisp.net (Postfix) with ESMTPS id B67B8118AD59 for ; Sun, 16 Aug 2009 22:19:02 -0600 (MDT) As opposed to now: Received: from darth.lan (c-73-14.161.160.hsd1.co.comcast.net [73.14.161.160]) by mail.covisp.net(Postfix 3.4.5/8.13.0) with SMTP id unknown; Sun, 16 Jun 2019 15:26:32 -0600 (envelope-from ) The first has an ESMTPS id and the other has SMTP id unknown. Any ideas why this might have changed? (In both cases the email is sent via an authentication submission on port 587 (or possibly 465 in the latter case). submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_path=private/auth -o syslog_name=postfix/submit -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_data_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_path=private/auth -o smtpd_data_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes
Re: Using always_bcc with FILTER action
plado: > Hello, > > We have a postfix instance that does internal routing based on headers. This > is implemented using header_checks like this: > > /^header-A/ FILTER smtp:[192.168.0.1] > /^header-B/ FILTER smtp:[192.168.0.2] > > Is it possible to send a copy of every email to a third server, say > 192.168.0.3? I tried to use always_bcc but this will just add another > recipient while still sending the email to only one of the two servers 1/2. > Getting rid of the header based routing is currently not possible. FILTER takes precedence over recipient-based routing. That is the only way that it can work. Maybe you can add the BCC address in or after the filter. Wietse > As the FILTER action overwrites the destination, I cannot use the transport > table or similar. > > Looking forward to any suggestions. > > Regards, > DP > > > > > -- > Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html >
Re: authenticate o365 users with postfix without smtp auth
Le 17/06/2019 à 13:08, Stefan Bauer a écrit : Emmanuel, thank you. That was of great help to see, that others have same isses with o365. Do you have any more infos how you do the experimental certificate matching part with postifx? In the official experimental release from Wietse. Emmanuel.
Re: authenticate o365 users with postfix without smtp auth
Le 17/06/2019 à 12:05, Emmanuel Fusté a écrit : Le 16/06/2019 à 22:37, Viktor Dukhovni a écrit : On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote: Some of our users use o365 but would like to use our service for outgoing mails. We are offering smtp sending services. Integrating our service in o365 is tricky, as one can only specify a smarthost but microsoft does not offer any kind of authentication for smarthosts. Are these individual users or cloud-hosted domains? Who's authorized to ask Microsoft to route their outbound traffic through your relay? Can you distinguish one such Office365 sender from another? ... What's the point (if I may ask) of having their mail sent through your relay? I assume that Microsoft could quite easily send their outbound traffic directly to its destination. Cloud-hosted domains is "hosting" service. You have the control on the outbound routing. There is many reason why you want your outbound traffic not directly delivered to its destination. Some want to provide "value added services". In my case is is because the o365 users are only a fraction of my users (hybrid cloud mode) and that inboud/ouboud internet mails policy/routing/delivery is under the control of another infrastructure. Microsoft is always presenting a client certificate. That the only way to authenticate O365. (the experimental certificate matching will help you) For the next part, the complete missing of outbound SMTP AUTH (under the control of Microsoft or the client organization) is the difficult/crazy part. The easy/lame way is to match the "under Microsoft control" X-MS-Exchange-CrossTenant-id header and the SMTP From domains to filter/differentiate o365 customers. The "proper" Microsoft way is to use their proprietary XOORG SMTP extension used in their hybrid cloud scenario. => after having authenticated o365 with the presented client certificate, if you announce the XOORG extension in the EHLO, o365 will provide you the remote o365 organization (in the "MS Exchange" sense) as part of the MAIL FROM verb. MAIL FROM: OORG=my-organization.com I have implemented the client part in postfix to not have to deploy 40 Microsoft Exchange Edge servers in a multi-tenant hybrid cloud scenario and use only my existing postfix infrastructure between o365 and all my Exchange platforms. It is the easy part. A few simple lines of code. I don't know what Wietse and Viktor will think about it, so I did not submit it yet... Will do. Would be great if it could be integrated in one form or another. Replying to myself, attached is the client patch for Postfix. Configure your Exchange with the proper TlsCapability and X509 authority Present the configured client certificate on the postfix smtp side. Exchange will announce the XOORG in the post TLS handshake EHLO. Postfix will pass the configured XOORG to Exchange during the "MAIL FROM:" Use debug_peer_list to observe the complete smtp transaction. Emmanuel. diff -u -r postfix-3.4.5-cert-auto/src/global/ehlo_mask.c postfix-3.4.5-xoorg/src/global/ehlo_mask.c --- postfix-3.4.5-cert-auto/src/global/ehlo_mask.c 2018-11-07 01:34:26.0 +0100 +++ postfix-3.4.5-xoorg/src/global/ehlo_mask.c 2019-06-05 15:12:38.386204490 +0200 @@ -21,6 +21,7 @@ /* #define EHLO_MASK_SMTPUTF8 (1<<12) /* #define EHLO_MASK_CHUNKING (1<<13) /* #define EHLO_MASK_SILENT(1<<15) +/* #define EHLO_MASK_XOORG (1<<16) /* /* int ehlo_mask(keyword_list) /* const char *keyword_list; @@ -86,6 +87,7 @@ "SMTPUTF8", EHLO_MASK_SMTPUTF8, "CHUNKING", EHLO_MASK_CHUNKING, "SILENT-DISCARD", EHLO_MASK_SILENT,/* XXX In-band signaling */ +"XOORG", EHLO_MASK_XOORG, 0, }; diff -u -r postfix-3.4.5-cert-auto/src/global/ehlo_mask.h postfix-3.4.5-xoorg/src/global/ehlo_mask.h --- postfix-3.4.5-cert-auto/src/global/ehlo_mask.h 2018-08-27 23:54:59.0 +0200 +++ postfix-3.4.5-xoorg/src/global/ehlo_mask.h 2019-06-05 15:11:10.176862868 +0200 @@ -30,6 +30,7 @@ #define EHLO_MASK_SMTPUTF8 (1<<12) #define EHLO_MASK_CHUNKING (1<<13) #define EHLO_MASK_SILENT (1<<15) +#define EHLO_MASK_XOORG(1<<16) extern int ehlo_mask(const char *); extern const char *str_ehlo_mask(int); diff -u -r postfix-3.4.5-cert-auto/src/global/mail_params.h postfix-3.4.5-xoorg/src/global/mail_params.h --- postfix-3.4.5-cert-auto/src/global/mail_params.h2019-04-09 16:17:03.47123 +0200 +++ postfix-3.4.5-xoorg/src/global/mail_params.h2019-06-05 15:05:32.571358595 +0200 @@ -1620,6 +1620,12 @@ #define DEF_SMTP_TLS_INSECURE_MX_POLICY "dane" extern char *var_smtp_tls_insecure_mx_policy; +#define VAR_SMTP_XOORG "smtp_xoorg" +#define DEF_SMTP_XOORG "" +#define VAR_LMTP_XOORG "smtp_xoorg" +#define DEF_LMTP_XOORG "" +extern char *var_smtp_xoorg; + /* * SASL authentication support, SMTP server side. */ diff -u -r
Using always_bcc with FILTER action
Hello, We have a postfix instance that does internal routing based on headers. This is implemented using header_checks like this: /^header-A/ FILTER smtp:[192.168.0.1] /^header-B/ FILTER smtp:[192.168.0.2] Is it possible to send a copy of every email to a third server, say 192.168.0.3? I tried to use always_bcc but this will just add another recipient while still sending the email to only one of the two servers 1/2. Getting rid of the header based routing is currently not possible. As the FILTER action overwrites the destination, I cannot use the transport table or similar. Looking forward to any suggestions. Regards, DP -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: authenticate o365 users with postfix without smtp auth
Le 17/06/2019 à 13:14, Wietse Venema a écrit : Emmanuel Fust?: The "proper" Microsoft way is to use their proprietary XOORG SMTP extension used in their hybrid cloud scenario. - Is there a protocol definition for this, or is there only implementation by trial and error? The only official statements by Microsoft about these are in this recent blog post: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Advanced-Office-365-Routing-Locking-Down-Exchange-On-Premises/ba-p/609238 Otherwise you will find some random informations on random blogs from anonymous or "value added" vendors. We verified these by reversing the exchange 2016 code, do tests with openssl s_client after proper configuration of our Exchange testing platform and add the client support in postfix. No fancy config, just define a smtp_xoorg parameter on a specific transport using a specific client certificate. - How is the XOORG information verified against other information (certificate, header) that is passed in a mail transaction? XOORG capability is announced and accepted by the (Exchange) server only for a valid (authority wise) client certificate matching a specific CN. (could be customized with the TlsCapability on the Exchange side). In the standard O365 cloud scenario, you authenticate the SMTP session with the classic validation of the certificate : You know that it is Microsoft and that it is O365 (cn= sorry bad memory, enable smtpd_tls_ask_ccert and you will get it, it is what the "hybridation wizard" will configure in the TlsCapability of your Exchange edge server). At this point, the XOORG value is know to be genuine, it is under Microsoft control, not tenant owner. All the other 'could/o365" informations passed as headers to Microsoft Exchange (cross-tenant-ID, X-OriginatorOrg etc...) are now trusted. Your Exchange server will now flag the email as "internal" (hybrid cloud") if the XOORG value passed during the SMTP transaction is a recognised/configured one. On the other side, when our are on O365, the headers are generated/sanitized by Microsoft and you base your policy on it. For on-premise -> o365, they don't use the XOORG extension (it is never announced). On your tenant, you configure an specific "inboud connector" which should match a specific client certificate CN (which should publicly validate) or a list of IPs No SMTP-AUTH It would be unsafe to accept XOORG from anyone without further verification. Exactly. XOORG is totally moot without client certificate validation and matching. Emmanuel.
Re: authenticate o365 users with postfix without smtp auth
On 16-06-19 21:50, Peter wrote: > On 17/06/19 2:00 AM, Stefan Bauer wrote: >> we are running a small smtp relay service with postfix for >> authenticated users. Unfortunately office 365 does not offer any smtp >> authentication mechanism when sending mails via connectors to smarthosts. > > I can't believe I just looked up MS docs for you, but: > > https://docs.microsoft.com/en-us/powershell/module/exchange/mail-flow/set-sendconnector?view=exchange-ps > > > Note the -SmartHostAuthMechanism and -AuthenticationCredential parameters. The document says: "This cmdlet is available only in on-premises Exchange." Therefore not supported on O365. Kind regards, Martijn Briners
Re: authenticate o365 users with postfix without smtp auth
Emmanuel Fust?: > The "proper" Microsoft way is to use their proprietary XOORG SMTP > extension used in their hybrid cloud scenario. - Is there a protocol definition for this, or is there only implementation by trial and error? - How is the XOORG information verified against other information (certificate, header) that is passed in a mail transaction? It would be unsafe to accept XOORG from anyone without further verification. Wietse
Re: authenticate o365 users with postfix without smtp auth
Emmanuel, thank you. That was of great help to see, that others have same isses with o365. Do you have any more infos how you do the experimental certificate matching part with postifx? thank you in advance Stefan Am Mo., 17. Juni 2019 um 12:05 Uhr schrieb Emmanuel Fusté < emmanuel.fu...@external.thalesgroup.com>: > Le 16/06/2019 à 22:37, Viktor Dukhovni a écrit : > > On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote: > > > >> Some of our users use o365 but would like to use our service for > outgoing > >> mails. We are offering smtp sending services. Integrating our service > in > >> o365 is tricky, as one can only specify a smarthost but microsoft does > not > >> offer any kind of authentication for smarthosts. > > Are these individual users or cloud-hosted domains? Who's authorized > > to ask Microsoft to route their outbound traffic through your relay? > > Can you distinguish one such Office365 sender from another? ... > > > > What's the point (if I may ask) of having their mail sent through > > your relay? I assume that Microsoft could quite easily send their > > outbound traffic directly to its destination. > > > Cloud-hosted domains is "hosting" service. You have the control on the > outbound routing. > There is many reason why you want your outbound traffic not directly > delivered to its destination. > Some want to provide "value added services". In my case is is because > the o365 users are only a fraction of my users (hybrid cloud mode) and > that inboud/ouboud internet mails policy/routing/delivery is under the > control of another infrastructure. > > Microsoft is always presenting a client certificate. That the only way > to authenticate O365. (the experimental certificate matching will help you) > For the next part, the complete missing of outbound SMTP AUTH (under the > control of Microsoft or the client organization) is the difficult/crazy > part. > > The easy/lame way is to match the "under Microsoft control" > X-MS-Exchange-CrossTenant-id header and the SMTP From domains to > filter/differentiate o365 customers. > > The "proper" Microsoft way is to use their proprietary XOORG SMTP > extension used in their hybrid cloud scenario. > => after having authenticated o365 with the presented client > certificate, if you announce the XOORG extension in the EHLO, o365 will > provide you the remote o365 organization (in the "MS Exchange" sense) as > part of the MAIL FROM verb. > MAIL FROM: OORG=my-organization.com > > I have implemented the client part in postfix to not have to deploy 40 > Microsoft Exchange Edge servers in a multi-tenant hybrid cloud scenario > and use only my existing postfix infrastructure between o365 and all my > Exchange platforms. It is the easy part. A few simple lines of code. I > don't know what Wietse and Viktor will think about it, so I did not > submit it yet... Will do. Would be great if it could be integrated in > one form or another. > > The hard part is the server part. Will do it some day to simplify our > tenants authentication, but I think that it will be more controversial > and will understand if Wietse and Viktor do not want such thing in Postfix. > As it is a SMTP extension, I did not find a generic mechanism in which > XOORG would fit and which could be added to postfix. > For my use case, as I've done for another reason for the certificate > case, I will add the possibility to silently map an XOORG value to a > SASL id to do proper source domain ownership filtering > (reject_xx_login_mismatch mumbles). > > Emmanuel. >
Re: authenticate o365 users with postfix without smtp auth
Le 16/06/2019 à 22:37, Viktor Dukhovni a écrit : On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote: Some of our users use o365 but would like to use our service for outgoing mails. We are offering smtp sending services. Integrating our service in o365 is tricky, as one can only specify a smarthost but microsoft does not offer any kind of authentication for smarthosts. Are these individual users or cloud-hosted domains? Who's authorized to ask Microsoft to route their outbound traffic through your relay? Can you distinguish one such Office365 sender from another? ... What's the point (if I may ask) of having their mail sent through your relay? I assume that Microsoft could quite easily send their outbound traffic directly to its destination. Cloud-hosted domains is "hosting" service. You have the control on the outbound routing. There is many reason why you want your outbound traffic not directly delivered to its destination. Some want to provide "value added services". In my case is is because the o365 users are only a fraction of my users (hybrid cloud mode) and that inboud/ouboud internet mails policy/routing/delivery is under the control of another infrastructure. Microsoft is always presenting a client certificate. That the only way to authenticate O365. (the experimental certificate matching will help you) For the next part, the complete missing of outbound SMTP AUTH (under the control of Microsoft or the client organization) is the difficult/crazy part. The easy/lame way is to match the "under Microsoft control" X-MS-Exchange-CrossTenant-id header and the SMTP From domains to filter/differentiate o365 customers. The "proper" Microsoft way is to use their proprietary XOORG SMTP extension used in their hybrid cloud scenario. => after having authenticated o365 with the presented client certificate, if you announce the XOORG extension in the EHLO, o365 will provide you the remote o365 organization (in the "MS Exchange" sense) as part of the MAIL FROM verb. MAIL FROM: OORG=my-organization.com I have implemented the client part in postfix to not have to deploy 40 Microsoft Exchange Edge servers in a multi-tenant hybrid cloud scenario and use only my existing postfix infrastructure between o365 and all my Exchange platforms. It is the easy part. A few simple lines of code. I don't know what Wietse and Viktor will think about it, so I did not submit it yet... Will do. Would be great if it could be integrated in one form or another. The hard part is the server part. Will do it some day to simplify our tenants authentication, but I think that it will be more controversial and will understand if Wietse and Viktor do not want such thing in Postfix. As it is a SMTP extension, I did not find a generic mechanism in which XOORG would fit and which could be added to postfix. For my use case, as I've done for another reason for the certificate case, I will add the possibility to silently map an XOORG value to a SASL id to do proper source domain ownership filtering (reject_xx_login_mismatch mumbles). Emmanuel.
Re: smtpd_reipient_restrictions
On 16.06.19 16:12, @lbutlr wrote: Since I have moved all local users to virtual users and switched dovecot to lmtp from lda, I was able to add reject_unverified_recipient to my restrictions, and it occurred to me maybe some of the other restrictions could be eliminated. Do reject_non_fqdn_recipient, reject_unauth_destination, do anything that isn’t done with the check for unverified recipient? smtpd_recipient_restrictions = reject_unauth_destination reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_recipient_domain reject_unknown_sender_domain reject_unlisted_recipient reject_unlisted_sender reject_invalid_hostname this was replaced by reject_invalid_helo_hostname reject_unverified_recipient reject_unknown_reverse_client_hostname reject_unknown_client_hostname reject_unknown_client_hostname is superflous to reject_unknown_reverse_client_hostname, you don't need both of them. people here often advise using reject_unknown_reverse_client_hostname over reject_unknown_client_hostname because it's less strict (doesn't require rdns to be forward confirmed). permit I would reorder this list to do simple rejections first: reject_unknown_client_hostname, reject_invalid_helo_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unlisted_sender, reject_unlisted_recipient, reject_unauth_destination reject_unverified_recipient -- 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. "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist "So does syphillis. Good thing we have penicillin." - Matthew Alton
Re: authenticate o365 users with postfix without smtp auth
I'm glad you're asking. These are cloud-hosted domains at microsofts exchange online (o365) infrastructure. Each user can set outgoing routing to smarthosts(called connectors) in exchanges admin-center. But - as said, no smtp-authentication is offered. We're providing sending-capabilities paired with archive & delivery statistics. So our customers can just sign-up for our services, set there relayhost (in postfix terms) and we take care of the rest. Our non-postfix-users, that are having o365 as mail infrastructure, can set as well a smarthost BUT without any smtp-authentication capability. Thats our problem. We would like to accept our customer mails, coming from the MS world, but need some good/strong way, to authenticate them appropriately. so far, only sender-domain/address and MS own-published ip-ranges are factors, we have available. Am So., 16. Juni 2019 um 22:37 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote: > > > Some of our users use o365 but would like to use our service for outgoing > > mails. We are offering smtp sending services. Integrating our service > in > > o365 is tricky, as one can only specify a smarthost but microsoft does > not > > offer any kind of authentication for smarthosts. > > Are these individual users or cloud-hosted domains? Who's authorized > to ask Microsoft to route their outbound traffic through your relay? > Can you distinguish one such Office365 sender from another? ... > > What's the point (if I may ask) of having their mail sent through > your relay? I assume that Microsoft could quite easily send their > outbound traffic directly to its destination. > > -- > Viktor. >
