Re: authenticate o365 users with postfix without smtp auth
Le 17/06/2019 à 21:31, Wietse Venema a écrit : 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. Really no need to forward OORG. It was not designed as an end to end mechanism. It its only stamping email from coming from this or this hosted organization without guaranties that they are doing sane things. OORG value has no meaning downstream, but need to be used in the access and relay policy: dedicated family of restrictions or SASL mapping to reuse some (reject_*_login_mismatch). Cloud/hosting providers could be trusted but without OORG information, it is the same as blindly thrusting the Internet. The cloud/hosting provider is acting as a multiplexer and we need to de-multiplex the flow, without presuming or relying on any inner in-band mechanism (DKIM). If going further, OORG must not be passed downstream but a way to tag some flow should be provided. With that, nothing prevent you to put the same tag as inbound (if there was any). I'm not a networking expert, but it could be view as an MPLS mechanism for SMTP It could help to solve a lots of thing in classic SAS/Cloud scenario, and is unavoidable in "hybrid" configurations. For the o365 hybridization case, destination domain is sufficient to determine the OORG to put for downstream Exchange servers as o365<->on premise emails use a "technical SMTP routing domain" (xxx.onmicrosoft.com) and custom transport fit well and keep the implementation minimal. My case for inbound emails: -> Exchange Office365-> inbound postfix -> routing, filtering layers etc-> internal outbound postfix -> Exchange (OORG access control) (o365 OORG spoofing) -> |_||___| Internet Big Corp trusted central zone Big corp branches/societies With the OORG replaying at the oubound, Exchange will promote these emails as internal, enabling the use/trust of all the specific Exchange headers coming from o365. 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. Yes, XOORG is not a end to end mechanism. It is actually supposed to be used only in o365->MS Exchange Edge case. Following their use, you should provide the XOORG capability only to a trusted server which is for Microsoft a server presenting a validated certificate with a specific CN. Emmanuel.
Re: authenticate o365 users with postfix without smtp auth
Le 17/06/2019 à 20:29, Wietse Venema a écrit : 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. Yes. In the o365 case, the certificate CN is unique and the same for all o365 servers and not differentiated by hosted customers. A global map is need to announce or not XOORG based on the client certificate (verified and matching by CN in the o365 case). Next, to be generic (and not o365 only/hybrid o365 only) you need a way to be able if needed to filter which ccert is tied to which oorg with something like reject_*_sender_ccert-oorg_mismatch. It's different from the case where we want to use the same map irrespective from the used mechanisms (sasl -> from email, ccert -> from email, oorg-> from email) and for witch I would overload/generalize the SASL login to reuse reject_*_sender_login_mismatch. More in my other answer. Emmanuel.
Re: Using always_bcc with FILTER action
Wietse Venema wrote > 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 I cannot change the filters, and the email does not come back from the filters. It is a one way. This means that when using header based routing, there is no postfix built-in way to copy/bcc the Email to an additional server? Thanks, DP -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
RE: How to tell my ISP there's a problem
Hi, your Postfix logs look normal to my untrained eyes. If it was me i would figure out the best contact email for the ISP and tell them as much detailed info as i could, so it is easy for them to get you the answer to "what happened to X email ?". Looks like they just need this line : Jun 17 12:03:16 localhost postfix/smtp[8033]: 10C52100049C: to=, orig_to=, relay=smtp.embarqmail.com[206.152.134.66]:25, delay=3.6, delays=0.05/0.01/0.17/3.3, dsn=2.0.0, status=sent (250 SPF validation soft failure) They will then know the : DATE TIME IP address of server that accepted your email Also i think they will want the FQDN and IP address of your server. Good luck -ANGELO FAZZINA ang...@uconn.edu University of Connecticut, ITS, SSG, Server Systems 860-486-9075 -Original Message- From: owner-postfix-us...@postfix.org On Behalf Of Richard James Salts Sent: Monday, June 17, 2019 11:29 PM To: postfix-users@postfix.org Subject: 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://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fv0rMErQh&data=02%7C01%7Cangelo.fazzina%40uconn.edu%7C442762b0d67a4f43757a08d6f39d536a%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C636964254387499317&sdata=zUjcikOfrs11SwYzM7o%2Bi6txTfWZeuQkXkqNHxOmT9k%3D&reserved=0 > > 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: Using always_bcc with FILTER action
plado: > Wietse Venema wrote > > 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. > > I cannot change the filters, and the email does not come back from the > filters. It is a one way. > > This means that when using header based routing, there is no postfix > built-in way to copy/bcc the Email to an additional server? Again, FILTER takes precedence over recipient-based routing. That means that all recipients will be subject to the FILTER. If you need to fork off another mail stream, put an 'Y' splitter proxy between the before-filter Postfix and the content filter. internet -> postfix -> proxy -> content filter \-> additional server Maybe someone can do an implementation based on smtpprox. Or maybe it is time to bundle a built-in proxy with Postfix. It can't be more complicated than postscreen or tlsproxy. Wietse
Re: How to tell my ISP there's a problem
On Tue, 2019-06-18 at 13:29 +1000, Richard James Salts wrote: > 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? > I'd been told quite awhile back that the spf soft failure isn't a problem by Centurylink Be that as it may I went into chat with Centurylink tech support this afternoon. I had all the information that I could think of to share with them. After over an hour of trying to explain what the problem is I got absolutely no where. In fact the 2nd person I went into chat with just up and terminated the chat on me in the middle of it. I was on the verge of changing my postfix setup to use my gmail account when I decided to try one last thing and that was to change the port from 25 to 587. After updating postfix files and reloading postfix I changed the time on the spamassassin update cronjob and let it run. Amazingly the message I expected was sent and received. I can only conclude that making the change from port 25 to 587 made the difference. I'll know for sure tomorrow when the SA-Update cronjob runs at the regular time. One last item, this isn't a mail server but just my home Ubuntu system. I've had postfix setup for many years from way back in my Mandrake days in order to easily send output of cronjobs to myself. It's probably overkill but it works fine for me and runs without any problems (except this last one). I'd like thank those that replied. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 20:38:34 up 1 day, 3:42, 1 user, load average: 1.20, 0.77, 0.68 Description:Ubuntu 18.04.2 LTS, kernel 4.18.0-22-generic signature.asc Description: This is a digitally signed message part
Milter vs. *_restrictions: evaluation order
Hello, I have a private (firewalled) outgoing-emails-only setup with main.cf containing (among others): smtpd_recipient_restrictions = reject_non_fqdn_recipient reject_unknown_recipient_domain permit_sasl_authenticated reject smtpd_milters = [some local ip:port] The (only) milter used replaces all recipients with a single, hard-coded email address. The use is a production clone setup for an application which sends emails. Production database contains real email addresses to which we do not want to send any email from the clone setup. This setup seems to work well. The reason I'm posting is that one "real" address contained a non-existent domain. reject_unknown_recipient_domain did its job and postfix rejected the email, despite that recipient address not being relevant in practice thanks to the milter. I have no problem with this behaviour (nor would I have a problem if it were the other way around), but it showed me that I did not completely understand how this works. So it made me wonder: - What is the restritions vs. milter evaluation order ? I could not find it in the documentation: MILTER_README does not mention restrictions, SMTPD_ACCESS_README does not mention milters, and (5)postconf does not specify an order on either option (although I could have missed it if it was on a related option, as of course this page contains a lot of matches for both). (8)smtpd documents milters in a "BEFORE QUEUE MILTER CONTROLS" section, but AFAIK milters are involed during the smtp transaction just as the restrictions are, so I don't think this is giving any fine-grained information on execution order. - Is reject_unknown_recipient_domain checked again after milter rewrite ? Although in my setup the final destination is hard-coded and sender would get errors which are not its own fault, I could imagine milters doing some address transformations based on original RCPT-TO, and rejecting the email could maybe be legitimate if it leads to a bogus value. Am I missing a place where this is documented ? Is it a small-enough implementation detail that it does not justify documenting it (which would be perfectly fine for me) ? Regards, -- Vincent Pelletier ERP5 - open source ERP/CRM for flexible enterprises
Re: Milter vs. *_restrictions: evaluation order
fwiw, shared here long ago -- don't remember the origin Restrictions execution order: postscreen, smtpd_mumble_restrictions, milter SMTP command inspection, smtpd_proxy_filter, header/body_checks, milter header/body inspection, content_filter
Some mails just stay in Queue.
Hello all, I am seeing a peculiar problem in on of our servers. Some mails in the queue stay there forever. of course they are very few just 20 or 30 in a month. most of them are from MAILER-DAEMON 3291B6063914! 54880 Mon Jun 17 17:32:24 MAILER-DAEMON veeren...@datasoftcomnet.com 2FF8A601819C! 29081 Mon Jun 17 18:44:24 MAILER-DAEMON veeren...@datasoftcomnet.com 20D90601819D! 1041140 Tue Jun 18 16:14:20 eb...@jio.com d...@datasoftcomnet.com some are from others as well. I've tried everything like postfix flush, restarting the services etc. still they stay there. Any hints please? Thanks DP
Re: Some mails just stay in Queue.
Durga Prasad Malyala writes: > Hello all, > I am seeing a peculiar problem in on of our servers. Some mails in the > queue stay there forever. of course they are very few just 20 or 30 in > a month. > most of them are from MAILER-DAEMON > > 3291B6063914! 54880 Mon Jun 17 17:32:24 MAILER-DAEMON > veeren...@datasoftcomnet.com > > 2FF8A601819C! 29081 Mon Jun 17 18:44:24 MAILER-DAEMON > veeren...@datasoftcomnet.com > > 20D90601819D! 1041140 Tue Jun 18 16:14:20 eb...@jio.com > d...@datasoftcomnet.com > some are from others as well. > > I've tried everything like postfix flush, restarting the services etc. > still they stay there. > Any hints please? Usually, postqueue -p gives the reason why the messages a queued. Anything your side? Olivier > > Thanks > DP > --
