March 20, 2019 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 20, 2019 [00:13:48] *** pajamian <pajamian!~pj@centos/ops/pj> has joined #postfix[00:14:51] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has quit IRC (Remote host closed the connection)[00:16:07] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has joined #postfix[00:16:52] *** ddBz_ <ddBz_!~gary@cpe-67-246-27-81.nycap.res.rr.com> has joined #postfix[00:21:17] *** random_yanek <random_yanek!~random_ya@87.116.237.230> has quit IRC (Ping timeout: 245 seconds)[00:21:55] *** ddBz_ <ddBz_!~gary@cpe-67-246-27-81.nycap.res.rr.com> has quit IRC (Ping timeout: 246 seconds)[00:27:26] *** Diemuzi <Diemuzi!~diemuzi@unaffiliated/diemuzi> has quit IRC (Quit: See you on the flip side!)[00:38:02] *** random_yanek <random_yanek!~random_ya@host-89-230-168-63.dynamic.mm.pl> has joined #postfix[00:55:43] *** pajamian is now known as pj[00:58:35] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has quit IRC (Remote host closed the connection)[00:58:44] *** Elisha <Elisha!~elisha@188-230-142-97.dynamic.t-2.net> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[00:59:49] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has joined #postfix[01:04:51] *** _ruben <_ruben!~ruben@2001:470:7c94:ffff:1ce:c01d:c0ca:c01a> has quit IRC (Ping timeout: 252 seconds)[01:09:02] *** Tourist <Tourist!~Tourist@unaffiliated/tourist> has quit IRC (Remote host closed the connection)[01:09:24] *** Tourist <Tourist!~Tourist@ip97.ip-51-254-159.eu> has joined #postfix[01:09:33] *** Tourist <Tourist!~Tourist@ip97.ip-51-254-159.eu> has quit IRC (Changing host)[01:09:33] *** Tourist <Tourist!~Tourist@unaffiliated/tourist> has joined #postfix[01:15:46] *** cemotyz09 <cemotyz09!~cemotyz09@cpe-70-121-128-59.satx.res.rr.com> has joined #postfix[01:19:33] *** random_yanek <random_yanek!~random_ya@host-89-230-168-63.dynamic.mm.pl> has quit IRC (Ping timeout: 246 seconds)[01:19:54] *** _cr_ <_cr_!~quassel@srv.ncxs.de> has quit IRC (Ping timeout: 272 seconds)[01:35:35] *** ]SiB[1 <]SiB[1!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[01:36:30] *** random_yanek <random_yanek!~random_ya@host-89-230-166-229.dynamic.mm.pl> has joined #postfix[01:36:49] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Ping timeout: 244 seconds)[01:36:49] *** ]SiB[1 is now known as ]SiB[[01:42:07] *** GNU\colossus <GNU\colossus!~colo@truschnigg.info> has quit IRC (Ping timeout: 252 seconds)[01:44:07] *** GNU\colossus <GNU\colossus!~colo@truschnigg.info> has joined #postfix[01:48:55] *** ]SiB[1 <]SiB[1!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[01:51:45] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Ping timeout: 246 seconds)[01:51:45] *** ]SiB[1 is now known as ]SiB[[01:52:50] *** GNU\colossus <GNU\colossus!~colo@truschnigg.info> has quit IRC (Ping timeout: 244 seconds)[01:55:07] *** GNU\colossus <GNU\colossus!~colo@truschnigg.info> has joined #postfix[02:00:03] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Ping timeout: 245 seconds)[02:00:22] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[02:01:33] *** TheFatherMind <TheFatherMind!~TheFather@cpe-104-34-204-52.socal.res.rr.com> has quit IRC ()[02:07:51] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Read error: Connection reset by peer)[02:07:57] *** ]SiB[1 <]SiB[1!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[02:10:18] *** ]SiB[1 is now known as ]SiB[[02:13:15] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Read error: Connection reset by peer)[02:13:20] *** ]SiB[1 <]SiB[1!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[02:15:42] *** ]SiB[1 is now known as ]SiB[[02:16:22] *** random_yanek <random_yanek!~random_ya@host-89-230-166-229.dynamic.mm.pl> has quit IRC (Ping timeout: 246 seconds)[02:16:39] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has joined #postfix[02:21:00] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has quit IRC (Quit: inabit. zz.)[02:21:00] *** Bebef <Bebef!sbreit@phobos.bebef.de> has quit IRC (Read error: Connection reset by peer)[02:22:05] *** Bebef <Bebef!sbreit@phobos.bebef.de> has joined #postfix[02:27:03] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has quit IRC (Quit: Ex-Chat)[02:28:20] *** random_yanek <random_yanek!~random_ya@host-89-230-171-108.dynamic.mm.pl> has joined #postfix[02:50:32] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Read error: Connection reset by peer)[02:50:42] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[03:10:04] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has quit IRC (Ping timeout: 255 seconds)[03:14:50] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has quit IRC (Quit: yvyz)[03:15:23] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has joined #postfix[03:16:10] *** _ruben <_ruben!~ruben@2001:470:7c94:ffff:1ce:c01d:c0ca:c01a> has joined #postfix[03:16:46] *** hjjg_ <hjjg_!~hg@91.34.26.70> has joined #postfix[03:20:14] *** hjjg <hjjg!~hg@p5B22176C.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 272 seconds)[03:29:09] *** ]SiB[1 <]SiB[1!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[03:30:30] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has quit IRC (Quit: yvyz)[03:32:07] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has joined #postfix[03:32:33] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Ping timeout: 245 seconds)[03:33:35] *** ]SiB[1 <]SiB[1!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Ping timeout: 244 seconds)[03:56:21] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has quit IRC (Quit: yvyz)[03:57:21] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has joined #postfix[04:00:38] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has quit IRC (Client Quit)[04:01:25] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has joined #postfix[04:01:25] *** cemotyz09 <cemotyz09!~cemotyz09@cpe-70-121-128-59.satx.res.rr.com> has quit IRC (Quit: cemotyz09)[04:04:12] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has quit IRC (Client Quit)[04:09:05] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has joined #postfix[04:20:55] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has quit IRC (Quit: yvyz)[04:21:29] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has joined #postfix[04:31:18] *** Blubberbop <Blubberbop!~quassel@mail.capmega.com> has quit IRC (Ping timeout: 245 seconds)[04:33:12] *** MACscr <MACscr!~MACscr@c-98-215-100-46.hsd1.il.comcast.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)[05:11:08] *** angersec <angersec!~quassel@quassel.angersec.com> has quit IRC (Read error: Connection reset by peer)[05:12:37] *** angersec <angersec!~quassel@quassel.angersec.com> has joined #postfix[05:21:01] *** yvyz <yvyz!~yvyz@gateway/tor-sasl/yvyz> has left #postfix ("WeeChat 2.3")[06:15:42] *** _cr_ <_cr_!~quassel@srv.ncxs.de> has joined #postfix[06:24:31] *** gu1lle_ <gu1lle_!~Thunderbi@45-251-16-190.fibertel.com.ar> has joined #postfix[06:24:37] *** _cr_ <_cr_!~quassel@srv.ncxs.de> has quit IRC (Ping timeout: 245 seconds)[06:27:18] *** _cr_ <_cr_!~quassel@srv.ncxs.de> has joined #postfix[06:28:56] *** gu1lle_ <gu1lle_!~Thunderbi@45-251-16-190.fibertel.com.ar> has quit IRC (Ping timeout: 246 seconds)[06:35:27] *** gu1lle_ <gu1lle_!~Thunderbi@45-251-16-190.fibertel.com.ar> has joined #postfix[06:58:31] *** MACscr <MACscr!~MACscr@c-98-215-100-46.hsd1.il.comcast.net> has joined #postfix[07:18:45] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has quit IRC (Remote host closed the connection)[07:20:01] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has joined #postfix[07:22:07] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has quit IRC (Read error: Connection reset by peer)[07:22:49] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has joined #postfix[07:24:46] *** A|TARIS <A|TARIS!~altaris@cronometroonline.net> has quit IRC (Ping timeout: 255 seconds)[07:36:55] *** TheFatherMind <TheFatherMind!~TheFather@cpe-104-34-204-52.socal.res.rr.com> has joined #postfix[08:04:50] *** thansen <thansen!~thansen@mx.thansen.me> has quit IRC (Ping timeout: 244 seconds)[08:05:37] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has joined #postfix[08:29:56] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has quit IRC (Remote host closed the connection)[08:31:14] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has joined #postfix[08:38:53] *** _snd <_snd!~alexh@login.boxed.no> has joined #postfix[08:40:40] <_snd> morn, is there any way to make postifx behave so that email with attachments gets stuck in a queue that delays the delivery with N seconds?[08:46:03] *** led_dark_1 <led_dark_1!~Thunderbi@217.66.160.14> has quit IRC (Quit: led_dark_1)[08:48:59] *** led_dark_1 <led_dark_1!~Thunderbi@217.66.160.14> has joined #postfix[09:21:40] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[09:36:42] <bhuddah> _snd: what are you trying to do?[09:37:39] <_snd> bhuddah: i want it so that i have a queue that by default lets an email sit for some seconds, 30-60 typically, before it is forwarded[09:38:19] <_snd> i use amavis on top, so i could do the mathcing on attachments there, but then i'd need to deliver it back to an smtp process that will stick it in a qeuue that has a minimum delay before it is handled further[09:39:18] <_snd> the reason is that would allow me to catch a lot more malware, as currnetly emails flow too fast for our palo alto's to cut the connection in real time and if i had a delay like that then we would have enough time to evaluate bad attachments and then the next PA would kill it[09:45:55] <bhuddah> _snd: you should use a proper spam filter like rspamd. that is by far a lot simpler.[09:56:39] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has quit IRC (Quit: Konversation terminated!)[10:00:26] <_snd> bhuddah: im stuck with amavis fo rother rasons, but thats not the point here, im just trying to find how to make postfix make a queue that is treated so that anything in it cannot be sent until it has been a minimum number of seconds on the queue[10:02:31] *** ychaouche <ychaouche!~ychaouche@197.201.1.50> has joined #postfix[10:03:20] <bhuddah> _snd: i think there is no way to do that. but please step back and re-evaluate what you're trying to do there. this cannot be the right solution.[10:04:47] <blackflow> _snd: attachments are higher level than what postfix deals with. they're "stuff" encoded as based64 or some other form, in the mail content. so only a content filter can be an arbiter here. I also second what bhuddah suggested. This totally sounds like a wrong approach.[10:07:10] <blackflow> *base64[10:23:52] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has joined #postfix[10:40:25] <_snd> blackflow: i only need postfix to deal with the queue and the delay, i can get amamvis to point the attachment to the right smtpd that services the queue[10:40:54] <_snd> and, nothing wrong i cauing a minor delay to let us sandbox and evaluate evil attachments[10:44:30] <tuxick> _snd: i smell manager[10:44:33] <blackflow> _snd: you misunderstood. you want postfix to do <something> based on <higher level encoding/interpretation> of something in the mail content. postfix doesn't do that. you need a content filter, policy or a milter[10:44:43] <tuxick> normal people don't bother with such silly requests[10:47:02] *** kurkale6ka <kurkale6ka!~kurkale6k@84.45.99.125> has joined #postfix[10:47:56] *** kurkale6ka <kurkale6ka!~kurkale6k@84.45.99.125> has quit IRC (Client Quit)[10:49:47] <ychaouche> managers aren't normal people ? oh boy[10:50:11] <tuxick> depends[10:50:36] <tuxick> most IT managers i had to deal with were clueless idiots[10:51:39] <tuxick> and on irc i learned that pretty much all crazy requests/questions traced back to managers[10:51:59] <tuxick> "why would anyone want that???"[10:52:17] <tuxick> closely related to XY problems[11:00:41] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has joined #postfix[11:02:07] *** bhuddah <bhuddah!~michael@unaffiliated/bhuddah> has quit IRC (Ping timeout: 245 seconds)[11:03:36] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has joined #postfix[11:04:49] <blackflow> tuxick: but you gotta understand them, sometimes they make sense. like this forwarding thing. clients (end users) don't care about best practices. they say "but <competition using cpanel> allowed me to forward [to gmail] with no issues! I'm unsatisfied with your service!"[11:05:21] <blackflow> that was my case, but thankfully I hold a rank sufficiently high to say "Yeah, I don't care, no moar forwarding, kthnksbai" without getting fired. I did catch some flak from clients, but survived.[11:05:57] <tuxick> for me it was a good reason to quit[11:06:04] <blackflow> (and I could because mailing is _not_ our primary service. If it were, I'm sure I wouldn't be able to)[11:06:19] <tuxick> they refused to listen to me, and then tried to blame me for mails getting blacklisted[11:06:54] <tuxick> and to top it off they hired an idiot con sultan who didn't even know what spf was[11:06:59] <blackflow> so often there's "advice in #postfix" which is sometimes in direct confrontation with "business requirements", and sometimes|often that confrontation ends up with "Manager: do as I say or you're fired"[11:07:17] <tuxick> yup[11:07:49] <tuxick> and that's why in most occasions managers where my reason to change job[11:08:13] <blackflow> And the rank I hold is as high because I co-own the thing. So I am _very_ much concerned if customers start to leave. I'm not just an employee who works from 9 to 5 and doesn't care about the company.[11:08:26] *** ddBz_ <ddBz_!~gary@cpe-67-246-27-81.nycap.res.rr.com> has joined #postfix[11:08:44] <blackflow> (they didn't because mailing ain't our primary service, but I'm just saying, if it _was_, I'd have to allow forwarding)[11:08:58] <tuxick> you can't. simple.[11:09:19] <tuxick> not even if you have a very anal spamfilter[11:09:50] <blackflow> my point is, the end user doesn't care or understand the intricacies.[11:09:53] <tuxick> unless you can convince them not to use gmail/hotmail[11:10:04] <blackflow> they'll see you as preventing them from doing something they can (and want) elsewhere.[11:10:21] <tuxick> make them sign an agreement[11:10:37] <blackflow> pretty much: every shared hosting company, every email saas, google, yahoo, hotmail, everyone who's not running Postfix on their own and monitors the logs and goes "ho, hum, maybe I'll POP3 fetch to gmail instead of forward".[11:10:39] <tuxick> "yes, i've been warned that at certain point my mails will get blocked"[11:11:06] <blackflow> I have the liberty to send them off to GSuite or Office365.[11:11:23] <blackflow> I can understand if emailing was our primary service, that'd be impossibru :)[11:11:24] <tuxick> that's why i hate them[11:11:51] <blackflow> yeah.[11:14:01] *** RadoQ <RadoQ!~cheater@unaffiliated/radoq> has quit IRC (Remote host closed the connection)[11:14:26] *** RadoQ <RadoQ!~cheater@unaffiliated/radoq> has joined #postfix[11:19:56] <tuxick> "why can't i send 600MB attachments????"[11:20:18] <tuxick> "why can't my car fly?"[11:23:42] <blackflow> well, that's gonna change. 640k ought to be enough for everyone :) and then I thought, many orbits ago, Google is giving 15GB for free? that's like infinite storage, who's gonna use all that! > Cat videos in powerpoint slides/PDFs shared as attachments: Hold my beer![11:24:03] <blackflow> so these days I regularly see google NOQUEUE due to over quota, lol.[11:24:17] *** olegfusion <olegfusion!~olegfusio@mail.mobileforsale.ru> has joined #postfix[11:24:41] <blackflow> actually deferred with a mailerdaemon bounce, but you get the point[11:26:02] <tuxick> i can't imagine gmail allows 600MB mails[11:26:29] <blackflow> yet.[11:30:51] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has quit IRC (Read error: Connection reset by peer)[11:31:20] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has joined #postfix[12:09:56] *** epony <epony!~epony@unaffiliated/epony> has quit IRC (Quit: QUIT)[12:24:39] <_snd> blackflow: back. yes, thats what i said. i'm not doing that higher level logic in psotfix, i need postfix to just have a queue and anything in that queue gets to sit for 30-60 seconds, how it gets to the queue, what criteria is used to put it in that queue, that is all amavis[12:24:54] *** section1 <section1!~section1@178.33.109.106> has joined #postfix[12:25:46] <_snd> tuxick: no, im not a manager, i just trying to get the most out of my money that has been spent on a palo alto unit, and i dont want the pa to be more than transparent inspection of taffic, no L3 stuff in the pa[12:26:19] <_snd> tuxick: i've been working with reasonably large networks for 20 years, as a hands on person, never tried to become a mananger of anything :)[12:26:45] <blackflow> _snd: maybe a custom transport and http://www.postfix.org/postconf.5.html#transport_destination_rate_delay not sure, never tried that before[12:27:13] <_snd> blackflow: that is what it looks like, from a day of looking around[12:27:14] <blackflow> but how you place mail in that transport based on whether it has an attachment, no idea without a content filter reinjection or something.[12:29:48] <_snd> blackflow: he're the thing im trying to get at: the pa's are pretty good at sandboxing weird attachmanets and evaluate if they are bad or good, but that requires up to 30-40 seconds sometimes, and if i run the pa as a l2 device i can't get it done quick enough that i can reject the email containing custom malware in time, but, if i get this delay in, then between our cloudy mailserver i dont touch and the outer mx'es i can then have things that contain weird s[12:30:17] <_snd> blackflow: all the logic of getting the mail into that transport is done in amavis, that is easy[12:30:28] <blackflow> _snd: come again, what's a "pa"?[12:31:41] <_snd> palo alto[12:31:42] <_snd> pa[12:32:03] <blackflow> what's that.... aside from a town where fakebook resides[12:32:08] <_snd> fancy application based firewall that can do some nice tricks if used right[12:32:24] <blackflow> and why do you need to delay the mail?[12:32:30] <_snd> epxlained above[12:33:06] <_snd> the pa thing has a system where it can send attachments off to be evaluated by more intelligent things, and has a very good catch rate for custom malware that antivirus doesnt catch[12:33:14] <_snd> but, that takes a few seconds to accomplish[12:33:35] <blackflow> okay, and?[12:34:00] <_snd> so, between the outer mx seeing an email (and the first pa reading out the attachments and sedning them off to be analysed and get a verdict back) it can last up to 30-40 seconds[12:34:06] <blackflow> I don't get it. postfix gets the mail, sends off to content filter that does <whatever in whatever time frame> and reinjects back into postfix queue when done[12:34:14] <_snd> no[12:35:22] <_snd> the palo alto box basically scans all the traffic that goes through a wire, as a transparent layer 2 device[12:35:35] <_snd> for the network it looks just like another set of switch ports[12:35:47] <_snd> but, it scans and analyses traffic inreal time[12:36:00] <_snd> (sorry for the speeeling, not on my own laptop now)[12:36:25] <_snd> and for most traffic it does this in real time, within the first 2-3 packets in a flow it will know to kill the flow or not[12:36:57] <_snd> but emails with attachments require more time, it needs to see the whole email, read out the attachment, send it off tothe cloud, get a verdict back if whatever ai deems to to be dangerous or not[12:37:11] <_snd> by the time i have a verdict up to 30-40 seconds may have lapsed[12:38:08] <_snd> so, if you go back and think of a network with mx'es exposed to the internet (wish one pa unit attachd) and then they pass email to the inside where the users have mailboxes in various servers, just like a normal network[12:38:53] <_snd> what i want to accomplish is to have the postfix on the outer mx delay certain emails by up to a minute, so that by the time it passes the second palo alto, it will know the results of the ai analysis of the attachment[12:39:11] <_snd> and then the email can be killed before it gets to the servers on the inside[12:39:32] <_snd> that is the whole scheme, nothing too complicated[12:40:42] <_snd> so from the perspective of postifx it is just an outer mx and sevrers on the inside, and some boxes that at will can intercept bad emails[12:41:02] <_snd> and we are someone that frequently receive targeted custom malware[12:41:54] <_snd> so integrating this into the flow is something that can allow us a nice way of doing this without dealing with more products on the servers that add more bloat[12:42:03] <_snd> did that make it a bit clearer?[12:43:10] *** level7 <level7!~quassel@31.44.17.250> has joined #postfix[12:43:14] <blackflow> _snd: sounds too convoluted for little to no actual gain.[12:43:49] <blackflow> the part I don't quite understand is why is the processing time a problem. You ahve an avalanhe of same emails so you want to..... pre-empt them with a forced scan?[12:44:03] <_snd> blackflow: as said, we see regular custom malware, this stops it, without adding any complications to any servers that already are full of exchange and it's related issues[12:45:35] <_snd> blackflow: it's not a huge stream, the key here is the ai-stuff in the cloud (fancy talk, palo alto does a lot of malware analysis, and they tend to be very good at it) means attachments get rad out from the tcp stream by a tranparent netowrk box, but it needsto go up into the cloud, the system needs to do whatever it does and then hand bac kdown a verdict if the malware is bad or not[12:45:41] <_snd> thats the processing time[12:47:00] <_snd> and just runnign the mail through the outer mx and into the sefrvers on the inside is less than a second, so we get the joy of seeing that the palo alto tells us we relayed malware in, but not enough time that the palo alto firewall can intercept the smtp connection and kill it before it goes to exchange[12:48:35] <blackflow> there's only so much you can do on this end of SMTP. sometimes you have to accept the fact that nothing is 100% perfect and things will get through, that's why I think thre's no gain really in this.[12:49:57] <blackflow> after all the proper way to do this is mark the mail, then decide what to do on delivery, eg. lmtp. bonus points for getting the firewall informed about malusers, but... moot point when the mal is distributed[12:51:50] *** olegfusion <olegfusion!~olegfusio@mail.mobileforsale.ru> has quit IRC (Ping timeout: 268 seconds)[12:52:09] *** olegfusion <olegfusion!~olegfusio@mail.mobileforsale.ru> has joined #postfix[13:04:44] *** gu1lle_ <gu1lle_!~Thunderbi@45-251-16-190.fibertel.com.ar> has quit IRC (Remote host closed the connection)[13:08:09] <_snd> blackflow: yes, and as i've said above, all im asking from postfix is a queue that i can put things into, and that the queue only services emails that have a minimum age, all the other details here are already in place[13:09:09] <_snd> blackflow: and you can't support stating "there is no gain here" when we see this as a way of actually killing a few dozen targeted pieces of malware that are customized to some of our reciptients, thats a pretty large hole to chalk off as patched[13:09:10] <blackflow> _snd: postfix support multi-instance mode so you technically have multiple queues with that.[13:09:43] <blackflow> it's just that each would need to listen on its own port or IP, so you'll need an arbiter that sends mail to another instace via a transport.[13:10:29] <_snd> blackflow: a single instance has multiple queues, too, its just like the deferred queue, but making the queue runner use some criteria that isnt here yet... and if that means finding a developer and paying them then that is within the scope :)[13:10:51] <blackflow> _snd: my point about "no gain" is that killing malware is orthogonal to firewall ops. whatever is scanning those mails can tag them and then you act accordingly on the delivery end. you don't have any holes[13:11:34] <_snd> no, you didnt read what is said about timing here: its a layer 2 transparent box, by the time we have a verdict back the email is way past the box, hence we need to delay the emails[13:11:47] <blackflow> if anything, that should be the _primary_ way to deal with malware. firewll ops are only convenience measures to reduce the pressure.[13:12:10] <blackflow> _snd: that's the part I fail to understand how is that happening at all[13:12:27] <_snd> blackflow: we have other constraints and loading up various exchange servers with more software isn't something those teams are ok with[13:12:42] <_snd> blackflow: how the scanning happens in real time? plenty of network boxes can do that[13:12:57] <blackflow> _snd: no, I mean, content filtering typicall works by checking the mail and _waiting_ for results before reinserting the mail into the queue[13:13:10] <_snd> yes, that is how it's traditionally done[13:13:32] <blackflow> I'd say a "normal" one. sounds like wrong kind of config there if you send off mail and don't wait for results, what's the point[13:13:59] <_snd> by there are many firewalls out there that can look at traffic in real time, and for example when it sees smtp traffic it reconstructs the email in real time from sniffed traffic, extracts attchments, sends them off and then can make an informed opinion on them[13:14:44] <blackflow> so like DPI[13:14:50] <blackflow> "sees smtp and <something">[13:14:54] <_snd> blackflow: this isn't an email appliance that interacts with the regular mail flow, its a network device that scans the traffic in real time and can interact with the ip traffic as needed[13:15:04] <_snd> yes, its a dpi thing, thats another buzzword[13:15:11] <blackflow> _snd: and what does it do with TLS connections?[13:15:23] <_snd> the whole thing is hey are completely transaprent, until lthey dont want to be and then they can interfere with your traffic[13:16:17] <blackflow> sounds to me it's overly complex and convoluted for no real gain, like I said. mail filtering should be done as it should be done, not via DPI-like sniffers inserted somewhere in the network[13:16:37] <blackflow> because indeed you've got yourself a race condition there[13:16:43] <_snd> blackflow: if i give a copy of the cert on my mx to the palo alto, then when you send me an email and the connection to my mx uses tls, this box will in real time insert itself and do a decryption of it that is transparent to you and transparent to te postfix server, so to postifx it looks like i have a solid tls inbound from you, and yet the palo alto can read it all[13:17:23] <blackflow> that's call MITM :)[13:17:33] <_snd> blackflow: that is the constraint, the people that should do this won't do it because of lots of reason, stability and skill probably factors in[13:17:41] <blackflow> most evil thing I can think of in various "antimalware" solutions[13:18:01] <_snd> blackflow: mitm is what it is, but it still works with dh keys, which makes it closer to black magic[13:18:05] <blackflow> bottom line, my opinion: you need to set up proper mail filtering, not do any DPI-like inspections[13:18:40] <blackflow> with that you'll have maximum control, with a straightforward execution, not race condition with async filtering and requeuing and artificial delays.[13:19:21] <blackflow> you can even "insert" a box that does that. MX -> inspector -> LMTP-or-SMTP-nexthop-post-processing[13:19:26] <_snd> but again: the big problem we have is a) the people running those servers cant/wont and b) the dpi stuff catches things that antivirus seems unable to deal with[13:19:51] <blackflow> I don't know how else to help you fit a square peg into a round hole. :)[13:20:43] <_snd> but you alredy helped me, and i just said it 10-15 lines up: i've looked and it seems this isnt out of the box with postfix, all we need is just to get it devleoped, it isnt rocket science :)[13:21:33] *** olegfusion <olegfusion!~olegfusio@mail.mobileforsale.ru> has quit IRC (Read error: Connection reset by peer)[13:21:36] <blackflow> _snd: I mean you can _divert_ port 25 to a box that does that, no need for async DPI checks[13:21:37] <_snd> i was just in her eto see if there was any obivous postfix config i had missed[13:22:16] <blackflow> _snd: yes with transports, but postfix on itself can't decide which transport based on attachment[13:22:23] *** treehug88 <treehug88!~textual@pool-98-113-184-194.nycmny.fios.verizon.net> has joined #postfix[13:22:38] <_snd> but iæve told you now 5-10 times: im not asking postifx to decide this[13:22:55] <blackflow> so you can have multi-instance postfix, which is actually multiple queues, if you need that[13:22:58] <_snd> im only asking postifx to haveaa queue and a queue runner that delivers thigns that are minimu N seconds old[13:23:15] <_snd> multi instance postifx is not what i am looking for[13:23:36] <_snd> and now i know that we need that developed,and thats fine by me, its only a bit of c :)[13:23:51] <blackflow> but everything I'm saying is based on transport destination rate delay[13:24:04] <_snd> and that isn't doing what im asking for[13:24:06] <blackflow> so I thought that covers your use case? or did I misunderstand[13:24:10] <blackflow> ah I see.[13:24:24] <_snd> i need the email to sit still for N seconds[13:24:49] <_snd> with rate delay the email is still sent at line speed if you are within limits on the rate of delivery[13:25:09] <_snd> i need the email to not leave the outer mx within N seconds of arriving[13:25:27] <blackflow> queue _retries_ can be adjusted yes, but I don't know of any config option that would delay the first attempt (other than transport delay which indeed I think is also between subsequent relays)[13:25:52] <_snd> think of it as the deferred queue, but the queue runner will check the time stamp and forward the email if the timestamp is minimum N seconds old[13:26:47] <blackflow> going back in circles, but if I had your problem, I'd totally push to do it TheRightWay(tm) with proper mail filtering. surely if you can insert anything, then you can divert port 25 to an instance where amavis or whatever scans one by one, waits for results?[13:26:58] <_snd> and thus my simple answer: we will just get somone to write the needed functionality, and get it clean and nice enough that it can be given back to postifx if anyone wants it[13:28:07] <_snd> blackflow: i fully comprehend what you write, but again, im not allowed to do that, and we are very comfy with these transparent devices and how they do what they do and all that, so we see it as a very uncomlpicated thing on the network side[13:29:08] <blackflow> _snd: did you look into things like postscreen and policyd? maybe they can do something[13:29:37] <_snd> yes, i looked thoruhg those and i dont get that one simple thing from those, even if they do lots of other neat stuff :)[13:29:52] <_snd> we use postscreen quite a bit[13:30:08] <blackflow> _snd: I guess i don't fully understand your use case then. you're asking about postfix, so postfix is obviously processing that mail, so I don't understand where DPI comes from, if postfix is handling the mail already, and thus can serialize content filter checks[13:31:23] <blackflow> what I mean is, you already apparently have postfix in the flow, that I'm guessing accepts, and delivers to a transport based on some mapping. inbetween those it could do content filtering, and the content filter can wait for results, reinsert into postfix. that's why I don't understand your use case, at which point in SMTP is it asynchronous and doesn't wait for pa[13:31:37] <_snd> w are not allowed to add software that can complicate things, the dpi does it without adding more software, thus no differnece in impact on the servers[13:32:03] <_snd> alrady stated ten times above: no added software on servers[13:32:21] <blackflow> so maybe the solution lies outside of postfix completely? simply delay SYN+ACKs ?[13:32:30] <_snd> one moment, brb[13:33:58] <blackflow> _snd: yeah you stated above, but you're asking about postfix and it took a while for me to realize posfix is really a red herring here. your problem is agnostic to the MTA itself.[13:34:09] *** bolt <bolt!~r00t@unaffiliated/bolt> has quit IRC (Remote host closed the connection)[13:34:53] <lunaphyte> software that can complicate things?[13:34:56] <lunaphyte> hah[13:35:15] <lunaphyte> indeed, instead, you've added a device that complicates things worse ;)[13:36:57] *** bolt <bolt!~r00t@unaffiliated/bolt> has joined #postfix[13:37:18] *** epony <epony!~epony@unaffiliated/epony> has joined #postfix[13:37:25] <_snd> lunaphyte: it doesnt complcate a thing, they are transparent and when they fail nothing is interferred with[13:37:50] <blackflow> _snd: so you want to coerce postfix to compensate by artificially delaying stuff for the out-of-band filter to catch up. nowai without third party software used via check_policy_service during SMTP, or content filter -- nowa that I personally know of. someone smarter might chime in with a config option, now that the problem is clear -- sorry it took me a while to realize your use case is MTA agnostic.[13:37:52] <lunaphyte> sorry, but that's a crazy statement[13:38:16] <lunaphyte> you've just spent 5 hours dealing with issues caused by this device[13:38:25] <lunaphyte> so yes, it very much complicates things[13:38:42] <lunaphyte> i'm fine with that, btw, it doesn't really matter, but please let's just at least be honest about what's going on[13:39:30] <_snd> lunaphyte: no?[13:42:46] <blackflow> _snd: one more tiny bit.... how is PA's decision used by your postfix instance? that part threw me off the scent[13:43:28] <_snd> blackflow: it isnt, i never said that[13:43:56] <blackflow> I could've sworn you did... lemme check the backlog[13:45:00] <_snd> i said amavis decides this[13:47:22] <blackflow> 12:24 < _snd> blackflow: back. yes, thats what i said. i'm not doing that higher level logic in psotfix, i need postfix to just have a queue and anything in that queue gets to sit for 30-60 seconds, how it gets to the queue, what criteria is used to put it in that queue, that is all amavis[13:47:46] <_snd> yes?[13:47:53] <blackflow> so it's contradicting. you seem to suggest PA is working completely MTA agnostic by DPI-like inspections[13:48:00] <blackflow> but then where does amavis come into play here[13:48:14] <blackflow> how would amavis requeue based on "what criteria is used to put it in that queue, that is all amavis"[13:48:20] <_snd> one moment, on a call[13:48:28] <blackflow> sure[13:48:43] *** bolt <bolt!~r00t@unaffiliated/bolt> has quit IRC (Remote host closed the connection)[13:49:35] <blackflow> at any rate, I apparently misunderstood the role of amavis here. I thought you meant (because it's its job!) amavis does the scans via PA -- which should wait for the response, and the bag&tag the mail. another red herring.[13:50:51] *** NickBusey <NickBusey!~NickBusey@c-67-176-95-15.hsd1.co.comcast.net> has quit IRC (Read error: Connection reset by peer)[13:51:02] <blackflow> anyway, it's clear now <MTA-not-important> needs to delay so the <external DPI-like thing> can do <out-of-band firewall ops>.[13:51:25] *** NickBusey <NickBusey!~NickBusey@c-67-176-95-15.hsd1.co.comcast.net> has joined #postfix[13:51:27] *** bolt <bolt!~r00t@unaffiliated/bolt> has joined #postfix[13:51:40] <_snd> forget all i said above, all 100 lines, and think of just a plain postfix with amavis as a post-queue scanner[13:51:58] <blackflow> right <MTA not important>[13:52:11] <_snd> doesnt need to be postfix[13:52:19] <blackflow> so you need <MTA not important> (incidentally it's postfx) to delay queue processing[13:52:20] <_snd> we just happen to have it running solidly[13:52:30] <blackflow> right. okay. now it's clear :)[13:52:59] <_snd> and we have amavis running as a post-queue scanner, it does a few very simple tasks but none of this is a/v scanning because that has multiple ways of failing[13:53:01] <blackflow> sorry, like I said you askinng in #postfix and mentioning amavis, I totally thought you had amavis use the PA and then PA doing side-effects elsewhere based on contents of that mail.[13:53:19] <_snd> no, like i said, this is very simple[13:53:46] <blackflow> right, just saying why it took so long for me to understand your issue.[13:53:58] <_snd> all im asking is: can postifx be configured in such asway that it has a queue (kinda like deferred) that has a parameter that says "only process stuff older than N seconds"[13:54:16] <blackflow> I was presupposing you were using postfix+amavis to do the content filtering, based on an external cloudy thing that does the actual scans[13:54:17] *** robinho86 <robinho86!~robsonjf@191.36.239.241> has joined #postfix[13:54:39] *** robinho86 <robinho86!~robsonjf@191.36.239.241> has quit IRC (Client Quit)[13:54:55] <_snd> amavis is fully in charge of looking at the mail and saying "oh, here's a neat attachment, ill process yo uaccording to policy X, which means I pass you back on port 10030, not 10028 like the other emails"[13:55:06] <blackflow> _snd: I don't think such a parameter exists, other than various transport and delay params and queue re-runs, which I believe are not useful for you because they react on subsequent rates/deliveries.[13:55:23] <_snd> i understood you thought htat and tried many time to tell you you are overthinking it[13:55:57] <_snd> blackflow: exactly, so then we wil lfind someone to cook up the neccesary c code to get such a queue going[13:56:28] <blackflow> it's not _me_ whos overthinking it. :) my line of thought was in what like pretty much every postfix(+amavis) setup does. you just have an issue that has nothing to do with postfix or amavis but would like postfix to compensate for that fact with an artificial delay.[13:56:51] <blackflow> _snd: but wait you said no third party software installations[13:56:58] <_snd> and to make a fancy diagram: internet ---<outer-DPI>--- MX ---<inner-DPI>--- multiple Exchange and other cruft[13:57:15] <blackflow> ify ou can install your custom code, why can't you setup amavis or policyd or postcreen based delay?[13:58:08] *** get <get!get@elite.bshellz.net> has quit IRC (Changing host)[13:58:08] *** get <get!get@unaffiliated/get> has joined #postfix[13:58:13] <_snd> blackflow: i haven't found a way to make amavis delay it without holding it as an open connection, and that overwhelms amavis resourcewise[13:58:44] <_snd> blackflow: if you just have a queueu its basically passive store-n-forward, no dpeending on software holding anything in memory, less resource intensive[13:58:45] <blackflow> it shouldn't. postfix can regulate how many parallel instances of content_filter (if that's how you use it) it runs, holding the mail in queue[13:59:08] <_snd> blackflow: so what happens when we rach max number of amavises?[13:59:24] <blackflow> nothing, postfix will wait until one is "freed" for next in queue[13:59:25] <_snd> reach, even[13:59:54] <_snd> so then we don't accept emails inbound until we have a free amavis? thats a self inflicted dos right there?[13:59:58] <blackflow> that's teh whole point of (on-disk) postfix queue. that's how it scales, as long as writing into the queue and reading from it, is handled by the hardware, it can scale up.[14:00:25] <blackflow> postfix accepts mail, queues it, and THEN delivers off to amavis[14:00:50] <blackflow> you can have 100/s incoming but only 10/s amavis, you'll get 90/s filing up the queue. so you mitigate that by adding amavis instances until you can handle 100/s incoming.[14:01:07] <_snd> that part i get[14:02:07] <_snd> but if you want amavis to hold them for N seconds after it picks them from the queue, then what happens once amavis suddenly has to hold N pieces of mail because all N triggered the rules that say we want to delay then, then no other mail gets past[14:02:25] <blackflow> which means a simple perl based amavis rule or plugin to hold off reinjection until X seconds have passed since timestamp in the headrrs[14:03:07] <_snd> all i want is amavis toquickly evaluate it, if its of interest, then send it back to a diffrent post-queue process in postfix that sticks it on disk like a normal queue, and the important part: tell postfix that piece stays in that queue for whatever time we deem needed, while processing all other queues[14:03:32] <_snd> no, there is alreayd scripts out there that do that, but they are a selfinflicted dos[14:03:33] <blackflow> _snd: there is no "amavis suddenly". you configure how many parallel instances will be queued up by postfix[14:03:43] <_snd> ok, let me explain it more clearly[14:05:03] <_snd> lets say you have postifx with amavis as a post-queue content filter, like 90% of postifx-amavis combos do it[14:05:24] <_snd> lets say you configure is to that you can scale up to 40 simultaneous amavis instances[14:05:59] <_snd> then you get one email that is of interest, amavis matches and goes off and sleeps for 60 seconds[14:06:10] <_snd> now you have 19 working amavises[14:06:19] <blackflow> first of all, how are you using amavis? via content_filter?[14:06:24] <_snd> yes[14:06:58] <_snd> but back to the above, if someone hits you with 20 emails with the right type of attachment all your amavis instaces are suddenly busing snoring and doing a "sleep 60"[14:07:02] <blackflow> default_destination_concurrency_limit then, if I'm not mistaken, or specific transport concurrency limit[14:07:07] <_snd> you are no longer moving *any* email[14:07:23] <blackflow> _snd: precisely. but how else?[14:07:43] <_snd> what about the few thousand other emails that want to arrive or leave during those 60 seconds?[14:07:46] <blackflow> if you had postfix wait_initially_before_queueing = "60s", you'd get the _same_ result[14:07:49] <_snd> not all emails are of interest[14:07:59] <_snd> but thats not what im tryign to do[14:08:06] <blackflow> then I totally lost you :)[14:08:21] <blackflow> those few thousand other emails will be accepted by postfix and queued up[14:08:31] <_snd> lets go back to just a very simple postfix with amavis as content_filter set up as post-queue?[14:08:43] <blackflow> SMTP satisfied, but final delivery will have to wait until it's processed by one of your N amavises that each sleeps 60 seconds in turn[14:08:53] <blackflow> if they really do just sleep you can fire up thousands of them in parallel[14:09:15] <_snd> thousands of amavises in paralell? how much memory do you have?[14:09:37] <_snd> look, let me explain it again, and let me finish explaining?[14:09:47] <_snd> a simple postfix with amavis as post-queue[14:10:15] <_snd> in amavis you make a cimplse policy that says "if attachment matching X is found, pass it back on port 10030, otherwise pass it back on port 10028"[14:10:26] <blackflow> okay[14:10:30] <_snd> this is what 90% of all setups of postfix/amavis look like[14:10:55] <_snd> so on port 10028 you have postfix waiting again, with an smtpd process and a few paramters overriden in master.c[14:10:57] <blackflow> (technically they reinject back into same port/queue but okay)[14:10:58] <_snd> master.cf[14:11:11] <_snd> they reinject back on port n+1[14:11:42] <_snd> so i want the usual postfix setup you already are familiar with to be on 10028, like it always has been[14:11:48] <blackflow> I meant amavis doesn't do "if attachment matching X" in 90% of setup. it scans, then injects back into same (n+1) port regardless of downstream decision.[14:12:08] <blackflow> but continue, I'm listening.[14:12:10] <_snd> but, on port 10030 i want a default queue that doesnt attempt delivery, but just stores it on disk, and a queue runner that picks up items older than N[14:12:21] <_snd> then i can't dos myself like a thosuand amavis processes can[14:12:37] <_snd> yes, correct[14:12:39] <_snd> my bad[14:12:53] <_snd> normal amavis is "scan and reinject on n+1"[14:13:01] <blackflow> right, you still can. you just need this other queu runner to have _another_ amavis, or policyd or postscreen or custom plugin (wiht no need to rebuild postfix) that sleeps[14:13:23] <_snd> and that is where you dont fully grasp the use of resoruces[14:13:29] <blackflow> therefore two instances/queues. amavis injects into the instances that has a plugin that sleeps, mail that has to go there.[14:13:42] <_snd> if i have to scale up to a thousand amavises, ust in case, the server will either be huge or implode[14:13:54] <blackflow> no, you didn't catch the very important detail[14:13:59] <_snd> no, once you tell amavis to sleep and hold it you get a bottleneck[14:14:01] <blackflow> you have 40 amavises that are decision makers[14:14:16] <blackflow> they inject into queue A or B based on some decision. B needs to "sleep" right?[14:14:29] <_snd> yes[14:14:41] <_snd> and how do you servie B then?[14:14:58] <blackflow> so in B you have a plugin (content filter, policy, whatever) that JUST sleeps. you can whip up a simple pipe(8) perl script that does that. you can have tens of thousands that just sleep() and then reinject into wherever.[14:15:10] <blackflow> point is: no need to rebuild postfix, s'all[14:15:40] <_snd> im not rebulding postfix, im just talking about a minor piece of code to deal with servicing the queues[14:15:56] <blackflow> how would that minor piece of code run?[14:16:27] *** Diemuzi <Diemuzi!~diemuzi@unaffiliated/diemuzi> has joined #postfix[14:16:37] <blackflow> you have lmtp(8), pipe(8), smtp(8) and virtual(8) delivery agent. that's all postfix does. eitehr you rebuild postfix, or use one of these with an external piece of code.[14:17:03] <blackflow> oh and local(8)[14:17:35] *** heroux <heroux!sandroco@gateway/shell/insomnia247/x-utidlobdczmxljhu> has quit IRC (Read error: Connection reset by peer)[14:18:07] <_snd> what im seeing it as is that the piece that runs the defrred queue would be somwher to start and jsut get another queue and an optional paramater that says minimum delay[14:18:16] *** heroux <heroux!sandroco@gateway/shell/insomnia247/x-sfsuymeapsleuqmo> has joined #postfix[14:18:19] <_snd> without having to work a pile of processes[14:18:33] <_snd> that would be qmgr i guess?[14:18:41] <blackflow> yes, but again, where is this extra minor piece of code? in the postfix source, or externally to which postfix delivers using one of the above mentioned agents[14:18:59] *** robinho86 <robinho86!~robsonjf@191.36.239.241> has joined #postfix[14:19:25] <blackflow> if postfix source, that's a rebuild. if externally, that's a, say, simple perl sleep() script you pipe(8) into from the secondary instance into which amavis injected mail that needs to hold off.[14:19:32] <_snd> if going the route of modding qmgr it would be not a oneoff hack, it would need to be public enough for others to see if the code was good enough[14:20:08] <_snd> blackflow: i understand what you are saying, but suddnely that means the content of mail in transit is held somewhere in memory, no?[14:21:08] <blackflow> yes, probably[14:23:59] <_snd> so, if we have a pile of mails in memory and something dies?[14:24:56] <_snd> i know gettign an optional parameter into qmgr (or somewhere) is more invasive, but im literally looking for getting it to be a modified deferred queue so that thigns stay on disk and there are no bottlenecks[14:25:25] <blackflow> sure that's better, but that's a postfix rebuild right there.[14:25:29] <_snd> with that approach im only limited by how fast a the current amavisd_instances can classify and queue things, no holding things untill time is up[14:26:04] <blackflow> I was looking into the access(5) manpage to see if a policy process can respond with something like "hold off and retry later, when you re-run the queue"[14:26:06] <_snd> that is looking more likely now that ive spent a day looking at it :)[14:26:27] <blackflow> looks like there is. see HOLD action of access(5)[14:26:38] <blackflow> http://www.postfix.org/access.5.html[14:26:52] <_snd> yes, that sorts it getting into the queue, but then i need someting to get iti out of the queue after a suitable time[14:27:08] <blackflow> with this, and a "plugin" to check_policy_service, memory has no role here[14:27:21] <blackflow> _snd: get it out after a suitable time is regular queue re-run[14:28:00] <blackflow> queue_run_delay if I'm not mistaken[14:28:34] *** double-p <double-p!~pbuehler@xfw.fips.de> has quit IRC (Ping timeout: 246 seconds)[14:30:31] <blackflow> I can of course not speak in the name of devs, but personally, even if you wrote such a qmgr option, I don't see it being generally useful to hold off queue processing for the _initial_ queue run. that's just personal opinion. maybe ask on the mailing list and if it seems like a potential waste of time (because if you don't upstream, you perpetually need to keep local mods and rebuild on updates)[14:30:46] <blackflow> definitely look into a policy plugin[14:31:18] <blackflow> in fact I'd start with that first. revert to modifying postfix if all else fails.[14:31:56] <blackflow> and uh.... before the grand inquisitor hears me, consider maybe exim which is a bit more configurable in the way it processes mail.[14:32:00] <_snd> well, im not stepping near modding postifx.... ill get someone that knows c a lot better than me :p[14:32:41] <blackflow> well You you or you as your org you :)[14:33:16] <_snd> yup :)[14:33:22] <_snd> i know my networking[14:33:38] <_snd> my only claim to fame dev-wise is i went to the same uni as weitse at roughly the same time :p[14:33:56] <blackflow> bonus points for the ML query :)[14:35:10] <_snd> hehe[14:35:15] <blackflow> so anyway, check_policy_service, and a [perl] script that checks timestamps and either responds with HOLD or OK if sufficiently "old"[14:35:57] <_snd> i hadn't tought of that route, that might be equally simple and avoid having anything sleeping in memory[14:36:22] <blackflow> I mean your org's devs can whip up such a checker in anything. perl, py, C, C++.... postfix uses network sockets to communicate with it. if code's to be written, this way you have full control over your plugin.[14:37:08] <_snd> if we talk perl i can whip it up :][14:37:36] <blackflow> _snd: there will be memory used in transit, so parallel processes means amounts of RAM used, but you can discard the contents afte you check the headers. the mail stay in the postfix queue so you can't lose it with a poorly written, buggy or otherwise unreeachable policy decision maker[14:37:43] <_snd> thanks for coming up with this, i knew something would come out of persisting in explaining this :)[14:38:08] <_snd> yes, thats what i was aiming for, not a thousand perl scripts doing sleep[14:38:16] <blackflow> right.[14:39:38] <_snd> so basically if i get amavis to just inject a header and not deal with two queues, and then the process in master.cf that takes the reinjection calls check_policy_service which can cause HOLD to be triggered[14:40:16] <blackflow> well.... yeah technically you don't even need multiple queues. and you can daisy chain policy checks if you had multiple if I'm not mistaken[14:40:24] <_snd> yup[14:40:36] *** gislaved <gislaved!b9e814cc@gateway/web/cgi-irc/kiwiirc.com/ip.185.232.20.204> has quit IRC (Ping timeout: 244 seconds)[14:41:01] <_snd> when i use HOLD they get stuck into the deferred queue?[14:41:14] <blackflow> yes[14:41:32] <_snd> then just add the same check_policy_service to process when to pick them out and continue the delivery then[14:41:40] <_snd> cool[14:41:45] <blackflow> uhh, incoming queue in this case, deferred is for outgoing[14:41:54] <_snd> and since check_policy_service allows foe a default DUNNO then it's pretty fail safe[14:41:57] <blackflow> if we're talking about /var/spool/postfix/<queues>[14:42:33] <_snd> well, we run amavis as post-queue, so amavis picks up from incoming, doesnt it?[14:42:33] <blackflow> _snd: precisely. but one thing still isn't clear. what happens to mail _after_ X seconds have passed?[14:42:55] <_snd> after x seconds has passed im happy to let the mail continue as if nothing had happened[14:42:57] <blackflow> _snd: yes but when it reinjects, the check_policy_service would happen on the incoming side of the injection[14:43:03] <blackflow> I think, at least.[14:43:03] <_snd> ok[14:43:08] <_snd> ill check that[14:43:16] <blackflow> never did this particular setup, so I could be wrong.[14:43:36] <blackflow> _snd: the part I don't get here, what blocks that mail if it's found to be bad[14:43:57] <blackflow> postfix got it, amavis saw attachment, reinjected into "hold" pattern, x seconds passed, and then what?[14:44:12] <_snd> continue delivery[14:44:18] <blackflow> your out-of-band PA found malware, how does it prevent postfix from delivering to final destination?[14:44:21] <_snd> lets find my luvely ascii art[14:44:23] <_snd> 13:56 < _snd> and to make a fancy diagram: internet ---<outer-DPI>--- MX ---<inner-DPI>--- multiple Exchange and other cruft[14:44:41] <_snd> there is two layers of PA/DPI/fancy stuff[14:44:57] <blackflow> so this policy thing would happen at the "MX" node?[14:45:01] <_snd> so it hits the outer one on the way into the MX, the MX starts its "hold for N seconds"[14:45:04] <_snd> yes[14:45:25] <_snd> by the time we have held it N seconds, the inner part would know the verdict of the outer DPI[14:45:31] <blackflow> I see[14:46:17] <_snd> so once the mail with the nasty malwar that regular a/v cant deal with comes alone th einner DPI box has a mitm on the smtp stream and literally midstream insert "5.7.0 sod off"[14:46:33] <blackflow> sounds like done deal. postfix keeps the job and grand inquistor lunaphyte never hears I attempted to suggest exim.[14:46:37] <_snd> and the mail dies, and the exchange people can sleep[14:47:24] <blackflow> oh waitaminute. inner DPI can't reply back to remote[14:47:57] <blackflow> this is really about losing the mail altogether or instructing "multiple Exchange oand other cruft" nodes not to accept, and essentially to discard to store into .Junk, or whatever the company policy.[14:49:00] <_snd> if the mail contains what is deemed to be custom malware we are happy to drop it[14:49:29] <blackflow> you'll have to either drop it or instruct downstream somehow to .Junk it[14:49:42] <_snd> the inner DPI actually does intercept the tcp/25 stream from mx to the servers in real time and injects the 5.7.0 so cleanly you think it's done by the exchanges[14:49:48] <_snd> no[14:49:51] <blackflow> that 5.7.0 sodoff won't reach the remote client that already delivered to the MX node and disconnected[14:49:52] <_snd> the inner dpi does that[14:49:59] <_snd> yes i know[14:50:04] <_snd> and i dont have to care about that[14:50:21] <blackflow> right, it's okay then.[14:50:25] <_snd> if the mail contains bad malwar eim sure the sender doesn't really hang around to wait for my reply[14:51:20] <_snd> and i couldnt care less, my only aim is that i get that mail killed, and the dpi system will keep a nice packet capture of the whole show for me, so i can pull it out and look at it on my own in wireshark if i want to[14:51:55] <blackflow> ideally you'd want it tagged and bagged. you could be dropping legitimate mail, no system is 100% perfect.[14:52:00] <_snd> but thats the crucial part, since its dpi/l2 transparent/whatever then it is failsafe, but i need to layers and the delay to be able to kill off bad stuff[14:52:30] <blackflow> and when THAT happens, I get clients scream at me that _their_ clients using gmail never received their mail, it's not even in the Junk.[14:52:41] <_snd> blackflow: i have a packet capture, so if it went haywire i could reconstruct it[14:52:54] <_snd> i dont have that problem :)[14:53:13] <blackflow> surely not 6 weeks later when an angry customer calls in to say they couldn't send to "any gmail recipient" for the past 6 weeks :)[14:53:25] <_snd> my problem is that we are very aware we are getting tailored malware and that is potentially very expensive[14:53:32] <lunaphyte> i'm happy to suggest exim :)[14:53:56] <blackflow> and then you check thelogs and see that status=sent and gmail accepted for delivery but never delivered. and you have no idea how to explain to technically illiterate customer :)[14:54:09] <_snd> blackflow: i only deal with inbond malware, not outbound smtp... and all layers above me have told me that hunting malware is all kosher[14:54:13] <blackflow> lunaphyte: I forgot how to trigger mantras.... the don't drop one in particular[14:54:27] <lunaphyte> !mantras[14:54:27] <knoba> lunaphyte: "mantras" : (#1) Do not accept mail that you do not intend (or are unable) to deliver., or (#2) Do not drop mail., or (#3) Do not use wildcards or catchalls., or (#4) Do not forward mail to third party systems., or (#5) Do not use sender address verification.[14:54:29] <lunaphyte> that one?[14:54:32] <blackflow> _snd: that's my point. you're doing what gmail is doing to ME. :)[14:54:56] <blackflow> eh I asked knoba in private but it had no idea about "mantras".[14:55:00] <_snd> blackflow: i only do it inbound to my users, outbound i only log bad stuff[14:55:02] <blackflow> yeah that one :)[14:55:33] <blackflow> _snd: precisely. that's my problem. google is accepting mail but not delivering, it's dropped somewhere in their chain/queues[14:55:36] <blackflow> ;)[14:55:58] <blackflow> you'll cause someone to be yelled at. so better deliver tagged, than drop ;)[14:56:41] <lunaphyte> oh, yeah. /msg knoba whatis #postfix mantras[14:56:47] <lunaphyte> if you want it in private[14:56:53] <_snd> blackflow: in general when filtering spam, yes, but when we are talking tailormade malware not a chance in hell[14:56:57] <blackflow> lunaphyte: ah I see thanks[14:57:02] <lunaphyte> sure thing[14:57:19] <lunaphyte> choices are: reject, quarantine, deliver[14:57:23] <blackflow> _snd: nothing is perfect :)[14:57:30] <_snd> blackflow: do you remember the ransomware stuff that happened to maersk last year?[14:57:39] <blackflow> vaguely[14:57:44] <lunaphyte> if you can't reject, and don't want to deliver, that's fine. quarantine[14:57:54] <blackflow> the SMB whatsit vulnerability caused one?[14:57:58] <_snd> did you read arstechnica or simialr yesterday about a norwegian alumnium company?[14:58:35] <_snd> lunaphyte: my problem is i dont know if i should reject before it's too late[14:58:47] <blackflow> _snd: oh I see "“Severe” ransomware attack cripples big aluminum producer"[14:59:17] <_snd> lunaphyte: but yes, we do have a running quarantine of all emails for $reasons for a week we can quickly re-relase stuff[14:59:29] <lunaphyte> that's perfect[14:59:36] <_snd> blackflow: yup, that isn't me, but we are in a very similar situation[15:00:07] <_snd> blackflow: i.e. not infected, but working hard to make sure we arent, because we are a big target and that stuff would add up to money quickly[15:00:17] <blackflow> understood.[15:00:43] <_snd> hence why "a few malware" isnt something im allow to say "oh well, c'est la view"[15:00:47] <_snd> er[15:00:47] <_snd> vie[15:00:51] <_snd> darn keyboard[15:02:13] *** FinboySlick <FinboySlick!~shark@74.117.40.10> has joined #postfix[15:02:25] <blackflow> oh man I only have to combat things like what I just got in mail. Mr. Bill Gates wants to give me $5M, if I replied to mrgates29 at gmail dot com[15:03:14] <_snd> i luckily dont get to deal with those, but i am sometimes envious of the porn spam some get[15:04:37] <blackflow> I had a nasty rash few weeks ago, rash of emails warning about email quotas being reached. pure phishing. one customer clicked. the "we have porn of you" ransomware is easily blockable, that was solved quickly, had basically zero variation in the content, piece of cake for spamasssassin.[15:07:40] *** hipodilski <hipodilski!~hipo@pc-freak.net> has quit IRC (Ping timeout: 272 seconds)[15:09:37] <_snd> there is only one category spam i know we struggle with, coupon and dating spam that is localised to our users native language[15:10:15] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has quit IRC (Quit: Konversation terminated!)[15:20:30] *** hipodilski <hipodilski!~hipo@pc-freak.net> has joined #postfix[15:39:18] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has quit IRC (Read error: Connection reset by peer)[15:39:49] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has joined #postfix[15:41:47] *** mami64 <mami64!2ef8a1a5@gateway/web/freenode/ip.46.248.161.165> has joined #postfix[15:44:23] *** mami64 <mami64!2ef8a1a5@gateway/web/freenode/ip.46.248.161.165> has left #postfix[15:45:11] *** TyrfingMjolnir <TyrfingMjolnir!~Tyrfing@62.92.82.250> has quit IRC (Ping timeout: 244 seconds)[15:46:21] *** mami64 <mami64!2ef8a1a5@gateway/web/freenode/ip.46.248.161.165> has joined #postfix[15:46:30] <mami64> Hello[15:47:21] <mami64> what is default cache time for incomming connections ? I have vdomain in mysql and for test I stoped mysql. and postfix accept all vdomains.[15:47:43] *** TyrfingMjolnir <TyrfingMjolnir!~Tyrfing@62.92.82.250> has joined #postfix[15:49:34] <mami64> I turn on mysql when I get "Temporary lookup failure". I tested delivery and for some time I get "Temporary lookup failure".[15:49:52] <mami64> I stoped sending test mail for this domain for a some minnut and all works fine[15:51:00] <mami64> probably smtp_connection_cache_on_demand or something but I dont known what cache[15:51:48] <mami64> i read http://www.postfix.org/CONNECTION_CACHE_README.html#configuration[15:58:29] *** double-p <double-p!~pbuehler@xfw.fips.de> has joined #postfix[16:10:30] <mami64> or what is a default cache for vdomain in mysql ? I sending for addres who not added in mysql and I get "access denied" = tyas ok[16:10:47] <mami64> bu I added top mysql vdomain and get this same error[16:11:20] <mami64> some times letter postfix f;ushed cache and working fine[16:14:58] <rob0> If your address maps are in mysql, you don't want mysql to fail. That's pretty much absolute.[16:16:18] <tuxick> makes sense[16:17:36] *** gislaved <gislaved!b9e814cc@gateway/web/cgi-irc/kiwiirc.com/ip.185.232.20.204> has joined #postfix[16:19:21] *** Blubberbop <Blubberbop!~quassel@mail.capmega.com> has joined #postfix[16:25:59] *** edux <edux!~edux@190.247.46.25> has joined #postfix[16:28:35] *** thansen <thansen!~thansen@mx.thansen.me> has joined #postfix[16:29:41] <tuxick> "domme mensen die denken dat nog rechtser stemmen het antwoord is op VVD"[16:29:49] <tuxick> "dus iedereen die niet links stemt is dom?"[16:29:54] <tuxick> oops[16:30:03] <tuxick> ok, i need to insert a window again[16:31:06] <mami64> rob0 this is test lab[16:32:40] *** fiQ2 <fiQ2!~fiQ@mirkk.ninja> has joined #postfix[16:33:04] *** fiQ- <fiQ-!~fiQ@mirkk.ninja> has quit IRC (Read error: Connection reset by peer)[16:34:13] *** ychaouche <ychaouche!~ychaouche@197.201.1.50> has quit IRC (Quit: Leaving)[16:35:42] <lunaphyte> mami64: how does that change things?[16:36:37] <mami64> lunaphyte: ?[16:37:15] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has joined #postfix[16:37:19] <rob0> What are you asking? Connection caching has nothing to do with SQL lookup caching.[16:37:26] <rob0> !proxymap[16:37:26] <knoba> rob0: "proxymap" : A way of proxying expensive database and LDAP connections. See proxymap(8) OR http://www.postfix.org/proxymap.8.html[16:42:22] <mami64> rob0: for test stop mysql with maps vdomain in mysql. I send e-mail (from external sever) to -> user at vdomai dot ltd. Postfix accept e-mail delivery. I weitki some times and send another e-mail. mail was - rejected (thats ok)[16:43:39] <rob0> ^^[16:44:02] <mami64> because postfix have cached request[16:44:08] <rob0> proxymap, NOT smtp connection caching[16:44:17] <rob0> !smtp[16:44:17] <knoba> rob0: "smtp" : Simple Mail Transfer Protocol (SMTP) is an Internet standard for electronic mail (email) transmission. First defined by RFC 821 in 1982, it was last updated in 2008 with Extended SMTP additions by RFC 5321, which is the protocol in widespread use today. See !esmtp[16:44:27] <rob0> hmm[16:44:36] <rob0> !smtp!=smtpd[16:44:36] <knoba> rob0: "smtp!=smtpd" : Postfix smtp_* and smtpd_* configuration parameters have different meanings. smtp_ = client and smtpd_ = server, the client-side sends mail whilst the server-side receives mail. (smtp = client = sends mail) (smtpd = server = receives mail)[16:45:04] <mami64> !memcache[16:45:04] <knoba> mami64: "memcache" : http://www.postfix.org/MEMCACHE_README.html and http://www.postfix.org/memcache_table.5.html for how to use memcache lookup tables in Postfix[16:45:28] <rob0> nope[17:02:24] *** blackflow <blackflow!~r00t@unaffiliated/blackflow> has quit IRC (Ping timeout: 252 seconds)[17:10:37] <double-p> yeh roite.. https://www.youtube.com/watch?v=TZRvO0S-TLU&[17:11:16] <double-p> (currently where this is sourced[17:12:55] *** level7 <level7!~quassel@31.44.17.250> has quit IRC (Ping timeout: 255 seconds)[17:15:07] *** level7 <level7!~quassel@31.44.16.132> has joined #postfix[17:18:54] *** level7 <level7!~quassel@31.44.16.132> has quit IRC (Remote host closed the connection)[17:19:05] *** level7 <level7!~quassel@31.44.16.132> has joined #postfix[17:22:49] *** blackflow <blackflow!~r00t@unaffiliated/blackflow> has joined #postfix[17:29:21] *** Elisha <Elisha!~elisha@188-230-142-97.dynamic.t-2.net> has joined #postfix[17:50:35] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has quit IRC (Remote host closed the connection)[17:51:50] *** i1nfusion <i1nfusion!~i1nfusion@46.101.134.251> has joined #postfix[18:06:07] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has quit IRC (Remote host closed the connection)[18:06:35] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has joined #postfix[18:10:57] *** korozion <korozion!korozion@unaffiliated/korozion> has quit IRC (Quit: brb upgrading irssi)[18:11:24] *** _cr_ <_cr_!~quassel@srv.ncxs.de> has quit IRC (Ping timeout: 244 seconds)[18:12:42] *** korozion <korozion!korozion@linuxgeneration.org> has joined #postfix[18:12:42] *** korozion <korozion!korozion@linuxgeneration.org> has quit IRC (Changing host)[18:12:42] *** korozion <korozion!korozion@unaffiliated/korozion> has joined #postfix[18:12:43] *** Nit_ <Nit_!nit@saphire.uk.to> has quit IRC (Quit: WeeChat 1.6)[18:19:21] *** Nit_ <Nit_!~Nit@2001:bc8:2ad4:100::1> has joined #postfix[18:29:51] *** level7 <level7!~quassel@31.44.16.132> has quit IRC (Remote host closed the connection)[18:31:39] *** treehug88 <treehug88!~textual@pool-98-113-184-194.nycmny.fios.verizon.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)[18:57:05] *** Zilon <Zilon!~Zilon@www.schem.me> has quit IRC (Quit: Bye)[18:59:18] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has quit IRC (Quit: inabit. zz.)[19:02:12] *** Zilon <Zilon!~Zilon@www.schem.me> has joined #postfix[19:02:23] *** netriber <netriber!~Andre@62.28.165.146> has joined #postfix[19:03:34] <netriber> Hello, I'm trying to send e-mail througt google but it says I'm not using smtp auth , I have enabled the following smtp_sasl_auth_enable=truesmtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_tls_security_level = encrypt[19:03:40] <netriber> what can I be doing wrong?[19:10:27] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has quit IRC (Quit: Ex-Chat)[19:16:28] <tuxick> that's for incoming?[19:16:34] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has quit IRC (Ping timeout: 272 seconds)[19:17:03] <tuxick> why would you want postfix to send through google?[19:28:35] *** blackflow <blackflow!~r00t@unaffiliated/blackflow> has quit IRC (Quit: leaving)[19:28:55] *** blackflow <blackflow!~r00t@unaffiliated/blackflow> has joined #postfix[19:30:16] *** gu1lle_ <gu1lle_!~Thunderbi@45-251-16-190.fibertel.com.ar> has joined #postfix[19:31:27] *** dakar <dakar!void@freebsd/user/dakar> has quit IRC (Ping timeout: 252 seconds)[19:32:36] *** Bahhumbug <Bahhumbug!jrd@psychotic/admin/jrd> has quit IRC (Ping timeout: 246 seconds)[19:33:35] *** Fire-Dragon-DoL <Fire-Dragon-DoL!~Fire-Drag@2605:de00:1:1:4a:15:0:2> has quit IRC (Ping timeout: 250 seconds)[19:34:25] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has joined #postfix[19:34:40] *** gu1lle_ <gu1lle_!~Thunderbi@45-251-16-190.fibertel.com.ar> has quit IRC (Ping timeout: 255 seconds)[19:38:02] *** dakar <dakar!void@freebsd/user/dakar> has joined #postfix[19:38:26] *** Bahhumbug <Bahhumbug!jrd@psychotic/admin/jrd> has joined #postfix[19:40:26] *** Fire-Dragon-DoL <Fire-Dragon-DoL!~Fire-Drag@2605:de00:1:1:4a:15:0:2> has joined #postfix[19:41:09] *** gu1lle_ <gu1lle_!~Thunderbi@45-251-16-190.fibertel.com.ar> has joined #postfix[19:59:10] *** edux <edux!~edux@190.247.46.25> has quit IRC (Quit: Leaving...)[20:02:25] *** gu1lle_ <gu1lle_!~Thunderbi@45-251-16-190.fibertel.com.ar> has quit IRC (Remote host closed the connection)[20:13:13] <rob0> netriber, the problem is probably covered in the SASL_README,[20:13:24] <rob0> !saslclient[20:13:24] <knoba> rob0: "saslclient" : See http://www.postfix.org/SASL_README.html#client_sasl when you need client-side SASL authentication to deliver mail to another server[20:19:38] *** ddBz_ <ddBz_!~gary@cpe-67-246-27-81.nycap.res.rr.com> has quit IRC (Ping timeout: 245 seconds)[20:25:21] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has joined #postfix[20:31:44] *** tobeon <tobeon!~tobeon@cm-84.209.8.103.getinternet.no> has quit IRC (Quit: tobeon)[20:34:29] *** section1 <section1!~section1@178.33.109.106> has quit IRC (Quit: Leaving)[20:38:07] *** helmut <helmut!helmut@subdivi.de> has left #postfix[21:01:59] *** ddBz_ <ddBz_!~gary@cpe-67-246-27-81.nycap.res.rr.com> has joined #postfix[21:02:56] *** gruceqq <gruceqq!~gruceqq@fx.annexet.pl> has quit IRC (Quit: Bye)[21:03:50] *** gruceqq <gruceqq!~gruceqq@fx.annexet.pl> has joined #postfix[21:05:01] *** led_dark_1 <led_dark_1!~Thunderbi@217.66.160.14> has quit IRC (Quit: led_dark_1)[21:07:15] *** led_dark_1 <led_dark_1!~Thunderbi@217.66.160.14> has joined #postfix[21:32:18] *** ddBz_ <ddBz_!~gary@cpe-67-246-27-81.nycap.res.rr.com> has quit IRC (Ping timeout: 246 seconds)[21:46:42] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has quit IRC (Ping timeout: 245 seconds)[21:47:49] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has joined #postfix[21:53:23] *** _cr_ <_cr_!~quassel@srv.ncxs.de> has joined #postfix[22:07:23] <zerocool> guys do you know if there is way, with DMARC to say, if both DKIM and SPF fail then policy is refect else none?[22:07:32] <zerocool> reject*[22:08:13] <rob0> that would be more a question for ##email (not anything Postfix about it), but no, I don't know.[22:08:23] *** FinboySlick <FinboySlick!~shark@74.117.40.10> has quit IRC (Quit: Leaving.)[22:10:22] <zerocool> thanks rob0[22:40:30] *** niee <niee!~user@MINE.THE.GAP.NIEE.LOAN> has quit IRC (Max SendQ exceeded)[22:40:36] *** niee <niee!~user@MINE.THE.GAP.NIEE.LOAN> has joined #postfix[22:48:18] *** tobeon <tobeon!~tobeon@cm-84.209.8.103.getinternet.no> has joined #postfix[22:59:43] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has quit IRC (Quit: inabit. zz.)[23:15:51] *** tobeon <tobeon!~tobeon@cm-84.209.8.103.getinternet.no> has quit IRC (Quit: tobeon)[23:15:53] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has joined #postfix[23:16:19] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has quit IRC (Remote host closed the connection)[23:16:38] *** tobeon <tobeon!~tobeon@cm-84.209.8.103.getinternet.no> has joined #postfix[23:21:39] *** robinho86 <robinho86!~robsonjf@191.36.239.241> has quit IRC (Quit: Leaving.)[23:21:55] *** tobeon <tobeon!~tobeon@cm-84.209.8.103.getinternet.no> has quit IRC (Ping timeout: 244 seconds)[23:48:43] *** Elisha <Elisha!~elisha@188-230-142-97.dynamic.t-2.net> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[23:57:39] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has quit IRC (Read error: Connection reset by peer)[23:58:22] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has joined #postfix