Switch to DuckDuckGo Search
   November 1, 2017  
< | 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 | >

Toggle Join/Part | bottom
[00:00:24] *** cemotyz09 <cemotyz09!~cemotyz09@cpe-70-121-157-202.satx.res.rr.com> has joined #postfix
[00:02:47] *** harukomoto <harukomoto!~harukomot@93-41-16-223.ip79.fastwebnet.it> has quit IRC (Ping timeout: 260 seconds)
[00:07:38] *** muh2000_ <muh2000_!~muh2000@HSI-KBW-078-042-015-025.hsi3.kabel-badenwuerttemberg.de> has joined #postfix
[00:14:03] *** DTZUZO <DTZUZO!~DTZUZO@S0106bcd16584b0aa.vs.shawcable.net> has joined #postfix
[00:18:16] *** mattcen <mattcen!~mattcen@c122-108-68-124.sunsh1.vic.optusnet.com.au> has quit IRC (Ping timeout: 258 seconds)
[00:21:52] *** mattcen <mattcen!~mattcen@c122-108-68-124.sunsh1.vic.optusnet.com.au> has joined #postfix
[00:24:26] *** fatdragon <fatdragon!~fatdragon@cpe-107-184-105-188.socal.res.rr.com> has quit IRC (Remote host closed the connection)
[00:24:59] *** fatdragon <fatdragon!~fatdragon@cpe-107-184-105-188.socal.res.rr.com> has joined #postfix
[00:29:01] *** fatdragon <fatdragon!~fatdragon@cpe-107-184-105-188.socal.res.rr.com> has quit IRC (Ping timeout: 240 seconds)
[00:30:04] *** NwS <NwS!~NwS@unaffiliated/nws> has joined #postfix
[00:31:13] *** Isla_de_Muerte <Isla_de_Muerte!~NwS@unaffiliated/nws> has quit IRC (Ping timeout: 248 seconds)
[00:31:50] *** Isla_de_Muerte <Isla_de_Muerte!~NwS@unaffiliated/nws> has joined #postfix
[00:33:53] *** ElDoggo <ElDoggo!~eldoggo@198-27-253-200.static.sonic.net> has quit IRC (Remote host closed the connection)
[00:34:41] *** NwS <NwS!~NwS@unaffiliated/nws> has quit IRC (Ping timeout: 240 seconds)
[01:10:09] *** ariscop <ariscop!~Phase4@icookc.lnk.telstra.net> has joined #postfix
[01:13:28] *** Gaaab <Gaaab!~Gaaab@host200-73-dynamic.182-80-r.retail.telecomitalia.it> has quit IRC (Remote host closed the connection)
[01:28:28] *** cemotyz09 <cemotyz09!~cemotyz09@cpe-70-121-157-202.satx.res.rr.com> has quit IRC (Quit: cemotyz09)
[01:32:27] *** impy <impy!~textual@ptr-g1zxlv3mo8mewisj6rz.18120a2.ip6.access.telenet.be> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[01:37:44] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has quit IRC (Quit: inabit. zz.)
[01:38:50] *** m712 <m712!~annoying@unaffiliated/thefam> has quit IRC (Ping timeout: 255 seconds)
[01:43:45] *** DTZUZO <DTZUZO!~DTZUZO@S0106bcd16584b0aa.vs.shawcable.net> has quit IRC (Ping timeout: 248 seconds)
[01:55:45] *** fatdragon <fatdragon!~fatdragon@cpe-107-184-105-188.socal.res.rr.com> has joined #postfix
[02:00:15] *** fatdragon <fatdragon!~fatdragon@cpe-107-184-105-188.socal.res.rr.com> has quit IRC (Ping timeout: 248 seconds)
[02:13:35] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has quit IRC (Read error: Connection reset by peer)
[02:15:04] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has joined #postfix
[02:24:01] *** fatdragon <fatdragon!~fatdragon@cpe-107-184-105-188.socal.res.rr.com> has joined #postfix
[02:57:51] *** aindilis <aindilis!~aindilis@172-12-3-117.lightspeed.sgnwmi.sbcglobal.net> has quit IRC (Ping timeout: 248 seconds)
[03:00:34] *** sklv <sklv!~sklv@gateway/tor-sasl/sklv> has quit IRC (Remote host closed the connection)
[03:01:03] *** sklv <sklv!~sklv@gateway/tor-sasl/sklv> has joined #postfix
[03:06:08] *** nomeed <nomeed!~nomeed@p579CECC8.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 252 seconds)
[03:08:16] *** nomeed <nomeed!~nomeed@p579CEB40.dip0.t-ipconnect.de> has joined #postfix
[03:45:15] *** troys is now known as troys_
[04:09:22] *** chachasmooth <chachasmooth!~chachasmo@unaffiliated/chachasmooth> has quit IRC (Ping timeout: 264 seconds)
[04:09:39] *** chachasmooth <chachasmooth!~chachasmo@unaffiliated/chachasmooth> has joined #postfix
[04:11:54] *** jaybe <jaybe!~jaybe@unaffiliated/jaybe> has quit IRC (Quit: ~)
[04:12:52] *** jaybe <jaybe!~jaybe@unaffiliated/jaybe> has joined #postfix
[04:20:41] *** sklv <sklv!~sklv@gateway/tor-sasl/sklv> has quit IRC (Remote host closed the connection)
[04:21:12] *** sklv <sklv!~sklv@gateway/tor-sasl/sklv> has joined #postfix
[04:50:37] *** MACscr <MACscr!~MACscr@c-73-9-230-5.hsd1.il.comcast.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[05:15:38] *** aindilis <aindilis!~aindilis@172-12-3-117.lightspeed.sgnwmi.sbcglobal.net> has joined #postfix
[05:25:22] *** led_ir22 <led_ir22!~Thunderbi@hotspot10.rywasoft.net> has quit IRC (Remote host closed the connection)
[05:25:33] *** led_ir22 <led_ir22!~Thunderbi@hotspot10.rywasoft.net> has joined #postfix
[05:26:39] *** troys_ is now known as troys
[06:18:57] *** Dolanyeah19 <Dolanyeah19!~dolanyeah@202.57.8.13> has joined #postfix
[06:21:20] *** MACscr <MACscr!~MACscr@c-73-9-230-5.hsd1.il.comcast.net> has joined #postfix
[06:25:10] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has quit IRC (Read error: Connection reset by peer)
[06:26:32] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has joined #postfix
[06:36:19] *** led_ir22 <led_ir22!~Thunderbi@hotspot10.rywasoft.net> has quit IRC (Quit: led_ir22)
[06:56:39] *** troys <troys!~troys@23-24-139-177-static.hfc.comcastbusiness.net> has quit IRC (Quit: Bye)
[07:14:36] *** Aprogas_ <Aprogas_!aprogas@84.245.48.241> has quit IRC (Quit: moving)
[07:29:37] *** m712 <m712!~annoying@unaffiliated/thefam> has joined #postfix
[08:00:22] *** ukleinek <ukleinek!~ukl@unaffiliated/ukleinek> has quit IRC (Ping timeout: 264 seconds)
[08:09:02] *** ukleinek <ukleinek!~ukl@unaffiliated/ukleinek> has joined #postfix
[08:09:46] *** ariscop <ariscop!~Phase4@icookc.lnk.telstra.net> has quit IRC (Quit: Leaving)
[08:14:10] *** ukleinek <ukleinek!~ukl@unaffiliated/ukleinek> has quit IRC (Ping timeout: 264 seconds)
[08:14:34] *** ukleinek <ukleinek!~ukl@unaffiliated/ukleinek> has joined #postfix
[08:31:03] *** jas02 <jas02!~jas02@193.179.215.98> has joined #postfix
[08:33:46] *** timdotrb <timdotrb!~timdotrb@104.194.27.26> has joined #postfix
[08:36:34] <timdotrb> Evening, all. Was wondering if anyone could help with a DKIM error I’m getting? When I set SOCKET=“inet:8891@localhost” in /etc/default/opendkim the service fails to start with an error. I believe it’s not getting the $SOCKET variable, but the service starts fine with the default value of SOCKET="local:/var/run/opendkim/opendkim.sock"
[08:36:47] <timdotrb> I’m trying to use it with Postfix on Ubuntu 16.04
[08:44:55] <jink> I know nothing, but "an error" triggers my "what error?" response.
[08:52:06] *** zulutango <zulutango!~zulutango@d49-192-7-133.bla1.nsw.optusnet.com.au> has joined #postfix
[09:06:21] *** ariscop <ariscop!~Phase4@pa49-184-153-39.pa.vic.optusnet.com.au> has joined #postfix
[09:12:05] <timdotrb> code=exited, status=64
[09:13:08] <timdotrb> Google hasn’t been much help. I modified the opendkim service and removed $SOCKET and replaced it with the value I wanted for the socket, “inet:8891 at 127 dot 0.0.1” and the service works now, so that leads me to believe my assumption was correct: it wasn’t getting the $SOCKET variable from the config
[09:16:45] <jink> timdotrb: It's an old bug, but maybe it helps? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792458
[09:17:14] <jink> http://terraltech.com/opendkim-to-sign-postfix-mails-on-ubuntu/
[09:17:19] <jink> That's all I can do, for now.
[09:18:05] *** harukomoto <harukomoto!~harukomot@93-41-16-73.ip79.fastwebnet.it> has joined #postfix
[09:19:30] *** Oclair <Oclair!~Oclair@178-190-53-92.adsl.highway.telekom.at> has quit IRC (Ping timeout: 246 seconds)
[09:20:02] *** Oclairi <Oclairi!~Oclair@178-190-52-14.adsl.highway.telekom.at> has joined #postfix
[09:22:43] <timdotrb> jink: hah, that was it. In the first link, it mentioned a lack of support for in-line comments
[09:23:06] <timdotrb> I, of course, had SOCKET=“foo” #bar
[09:23:25] <timdotrb> jink: ty
[09:23:42] *** sebastienthiry <sebastienthiry!~Thunderbi@91.179.29.200> has joined #postfix
[09:28:21] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has quit IRC (Ping timeout: 240 seconds)
[09:30:02] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has joined #postfix
[09:34:05] *** zulutango <zulutango!~zulutango@d49-192-7-133.bla1.nsw.optusnet.com.au> has quit IRC (Ping timeout: 240 seconds)
[09:34:08] *** impy <impy!~textual@ptr-g1zxlv2ats4rj8xq7b7.18120a2.ip6.access.telenet.be> has joined #postfix
[09:43:00] *** stfacc <stfacc!~stfacc@88.191.30.172> has joined #postfix
[09:54:48] <jink> timdotrb: (Y)
[10:03:32] *** Gaaab <Gaaab!~Gaaab@host200-73-dynamic.182-80-r.retail.telecomitalia.it> has joined #postfix
[10:12:32] *** Jellyg00se <Jellyg00se!~Alfie@195.99.134.162> has joined #postfix
[10:20:57] *** bauruine <bauruine!~bauruine@2a01:4f8:130:8285:fefe::36> has quit IRC (Quit: ZNC - http://znc.in)
[10:24:41] *** bauruine <bauruine!~bauruine@2a01:4f8:130:8285:fefe::36> has joined #postfix
[10:24:48] *** nyloc <nyloc!~quassel@darwin.nyloc.de> has quit IRC (Remote host closed the connection)
[10:25:00] *** nyloc <nyloc!~quassel@darwin.nyloc.de> has joined #postfix
[10:39:37] *** NwS <NwS!~NwS@unaffiliated/nws> has joined #postfix
[10:42:21] *** Isla_de_Muerte <Isla_de_Muerte!~NwS@unaffiliated/nws> has quit IRC (Ping timeout: 240 seconds)
[10:47:49] *** Isla_de_Muerte <Isla_de_Muerte!~NwS@unaffiliated/nws> has joined #postfix
[10:50:21] *** NwS <NwS!~NwS@unaffiliated/nws> has quit IRC (Ping timeout: 240 seconds)
[10:53:12] *** NwS <NwS!~NwS@unaffiliated/nws> has joined #postfix
[10:56:15] *** Isla_de_Muerte <Isla_de_Muerte!~NwS@unaffiliated/nws> has quit IRC (Ping timeout: 248 seconds)
[10:56:29] *** Isla_de_Muerte <Isla_de_Muerte!~NwS@unaffiliated/nws> has joined #postfix
[10:59:27] *** NwS <NwS!~NwS@unaffiliated/nws> has quit IRC (Ping timeout: 248 seconds)
[11:04:30] *** internat <internat!biteme2@61.68.164.37> has quit IRC (Ping timeout: 246 seconds)
[11:12:28] *** heroux <heroux!sandroco@gateway/shell/insomnia247/x-pcdethrtilpskpld> has quit IRC (Ping timeout: 240 seconds)
[11:12:48] *** Death_rattle__ <Death_rattle__!~death@p200300EDEBC3AC0094F4695B20AE61BC.dip0.t-ipconnect.de> has joined #postfix
[11:14:57] *** Gaaab <Gaaab!~Gaaab@host200-73-dynamic.182-80-r.retail.telecomitalia.it> has quit IRC (Ping timeout: 240 seconds)
[11:15:45] *** DonAlex <DonAlex!~DonAlex@2a00:23c1:c02:4700:228:f8ff:feba:c4b2> has joined #postfix
[11:17:26] <DonAlex> Help! Did an upgrade a little while back and now postfix is not sending email. It could be because of a legacy configuration or it could be the relay server by the ISP is less secure than it should be. I am getting TLS handshake errors.
[11:17:29] <DonAlex> warning: TLS library problem: error:1417118C:SSL routines:tls_process_server_hello:version too low
[11:17:42] <DonAlex> I thought I had excluded all low stuff I could.
[11:17:46] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has joined #postfix
[11:19:19] <DonAlex> I used this in my main.cf smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
[11:19:24] <DonAlex> is that not sufficient ?
[11:19:47] *** Gaaab <Gaaab!~Gaaab@host200-73-dynamic.182-80-r.retail.telecomitalia.it> has joined #postfix
[11:20:12] <lennard> for *sending* mail you want to look at smtp_tls*, not smtpd_tls*
[11:21:16] <lennard> also, I think those settings and their smtp_ equivalents only apply when you have a tls policy set to 'manditory'
[11:22:18] <lennard> when you're doing oppertunistic tls, which is the more common setup, you probably want *_tls_ciphers
[11:28:22] *** DonAlex <DonAlex!~DonAlex@2a00:23c1:c02:4700:228:f8ff:feba:c4b2> has quit IRC (Remote host closed the connection)
[11:38:21] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has quit IRC (Ping timeout: 240 seconds)
[11:42:12] *** sarri <sarri!~sari@unaffiliated/sarri> has quit IRC (Ping timeout: 260 seconds)
[11:42:18] *** timdotrb <timdotrb!~timdotrb@104.194.27.26> has quit IRC (Quit: timdotrb)
[11:42:41] *** timdotrb <timdotrb!~timdotrb@ip70-190-186-81.ph.ph.cox.net> has joined #postfix
[11:42:51] *** ogny <ogny!~orkun@78.186.178.128> has joined #postfix
[11:42:51] *** ogny <ogny!~orkun@78.186.178.128> has quit IRC (Changing host)
[11:42:51] *** ogny <ogny!~orkun@unaffiliated/ogny> has joined #postfix
[11:43:06] *** timdotrb <timdotrb!~timdotrb@ip70-190-186-81.ph.ph.cox.net> has quit IRC (Client Quit)
[11:43:15] *** ariscop <ariscop!~Phase4@pa49-184-153-39.pa.vic.optusnet.com.au> has quit IRC (Quit: Leaving)
[11:43:51] *** timdotrb <timdotrb!~timdotrb@ip70-190-186-81.ph.ph.cox.net> has joined #postfix
[11:43:51] *** timdotrb <timdotrb!~timdotrb@ip70-190-186-81.ph.ph.cox.net> has quit IRC (Client Quit)
[11:44:25] *** timdotrb <timdotrb!~timdotrb@ip70-190-186-81.ph.ph.cox.net> has joined #postfix
[11:44:36] *** timdotrb <timdotrb!~timdotrb@ip70-190-186-81.ph.ph.cox.net> has quit IRC (Client Quit)
[11:45:43] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has joined #postfix
[11:51:49] *** heroux <heroux!sandroco@gateway/shell/insomnia247/x-uutxzryzhlormkov> has joined #postfix
[11:53:57] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has quit IRC (Ping timeout: 240 seconds)
[11:54:53] *** sarri <sarri!~sari@p50995cae.dip0.t-ipconnect.de> has joined #postfix
[11:54:54] *** sarri <sarri!~sari@p50995cae.dip0.t-ipconnect.de> has quit IRC (Changing host)
[11:54:54] *** sarri <sarri!~sari@unaffiliated/sarri> has joined #postfix
[12:04:20] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has joined #postfix
[12:04:22] *** sebastienthiry <sebastienthiry!~Thunderbi@91.179.29.200> has quit IRC (Quit: sebastienthiry)
[12:06:25] *** zombs is now known as bs
[12:12:52] *** ariscop <ariscop!~Phase4@pa49-184-153-39.pa.vic.optusnet.com.au> has joined #postfix
[12:15:13] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has quit IRC (Ping timeout: 248 seconds)
[12:17:46] *** jas02 <jas02!~jas02@193.179.215.98> has quit IRC (Ping timeout: 252 seconds)
[12:21:53] *** kingkong <kingkong!~Admin@shellium/member/kingkong> has quit IRC (Ping timeout: 255 seconds)
[12:23:30] *** kingkong <kingkong!~Admin@chatq.net> has joined #postfix
[12:23:30] *** kingkong <kingkong!~Admin@chatq.net> has quit IRC (Changing host)
[12:23:30] *** kingkong <kingkong!~Admin@shellium/member/kingkong> has joined #postfix
[12:24:05] *** roxer <roxer!~roxer@q.netatonce.net> has quit IRC (Ping timeout: 240 seconds)
[12:25:00] *** jas02 <jas02!~jas02@193.179.215.98> has joined #postfix
[12:25:13] *** roxer <roxer!~roxer@q.netatonce.net> has joined #postfix
[12:30:33] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has joined #postfix
[12:32:22] *** jas02 <jas02!~jas02@193.179.215.98> has quit IRC (Ping timeout: 260 seconds)
[12:36:07] *** jas02 <jas02!~jas02@193.179.215.98> has joined #postfix
[12:38:09] *** cybrNaut <cybrNaut!~cybrNaut@unaffiliated/cybrnaut> has joined #postfix
[12:47:25] *** rsx <rsx!~rsx@ppp-46-244-247-173.dynamic.mnet-online.de> has joined #postfix
[12:49:27] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has quit IRC (Ping timeout: 240 seconds)
[12:59:33] <cybrNaut> webmail users have an advantage over us postfix users, it seems. When they send a msg, their local IP address does not appear in the msg headers. But if postfix sends a msg to a relay, the relay puts the local IP in the headers
[12:59:37] <cybrNaut> is there a way around that?
[13:01:06] <cybrNaut> (apart from subscribing to a VPN)
[13:08:01] *** synthroid <synthroid!~synthroid@gateway/vpn/privateinternetaccess/synthroid> has joined #postfix
[13:10:09] *** ogny <ogny!~orkun@unaffiliated/ogny> has quit IRC (Ping timeout: 248 seconds)
[13:13:32] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has joined #postfix
[13:17:08] *** rsx <rsx!~rsx@ppp-46-244-247-173.dynamic.mnet-online.de> has quit IRC (Ping timeout: 240 seconds)
[13:17:55] *** rsx <rsx!~rsx@ppp-46-244-241-131.dynamic.mnet-online.de> has joined #postfix
[13:22:03] *** philipneves <philipneves!~philipnev@S010648ee0cf0e253.vc.shawcable.net> has quit IRC (Quit: Leaving)
[13:27:10] *** DonAlex <DonAlex!~DonAlex@2a00:23c1:c02:4700:228:f8ff:feba:c4b2> has joined #postfix
[13:27:13] *** ariscop <ariscop!~Phase4@pa49-184-153-39.pa.vic.optusnet.com.au> has quit IRC (Quit: Leaving)
[13:28:07] <DonAlex> sorry had to go out. So did I paste it in the wrong config file? or just copied the wrong stanza ? Lemme try and see.
[13:31:46] <DonAlex> hmm changed them all to smtp but still seems same error?
[13:32:24] <DonAlex> SSL_connect error to relay.clara.net[80.168.45.10]:465: -1 warning: TLS library problem: error:1417118C:SSL routines:tls_process_server_hello:version too low:../ssl/statem/statem_clnt.c:917
[13:32:53] *** Death_rattle__ <Death_rattle__!~death@p200300EDEBC3AC0094F4695B20AE61BC.dip0.t-ipconnect.de> has quit IRC (Quit: bye)
[13:38:53] <DonAlex> using the testssl.sh script I notice this.
[13:39:05] *** Diemuzi <Diemuzi!~IceChat9@unaffiliated/diemuzi> has joined #postfix
[13:39:41] <DonAlex> https://pastebin.ca/3902406
[13:39:46] <DonAlex> Could that be an issue?
[13:41:12] *** Ellenor is now known as Reinhilde
[13:47:46] <DonAlex> If the server only supports TLSv1 is that even supported any more ?
[13:49:51] *** Dolanyeah19 <Dolanyeah19!~dolanyeah@202.57.8.13> has quit IRC (Read error: Connection reset by peer)
[13:49:56] <DonAlex> Frak.. looks like it is. https://serverfault.com/questions/803920/postfix-configure-to-use-tlsv1-2#836687
[14:14:36] *** patdk-wk <patdk-wk!~dswett@2001:470:e0ba:15:1a03:73ff:fe2a:d75> has joined #postfix
[14:14:55] <DonAlex> Ugggg how can I get around this. :(
[14:25:40] <DonAlex> WAaaaaaaaaaaaaa this driving me nuts.. I even switch to a cert finger print and it still moans about the HELO being too low
[14:27:29] <rob0> no, the SSL "hello" has nothing to do with the SMTP "HELO"
[14:29:05] *** Dolanyeah19 <Dolanyeah19!~dolanyeah@202.57.8.13> has joined #postfix
[14:29:15] <rob0> cybrNaut, no reason why you can't install your own webmail client on your Postfix server.
[14:31:17] *** Dolanyeah19 <Dolanyeah19!~dolanyeah@202.57.8.13> has quit IRC (Read error: Connection reset by peer)
[14:32:28] *** Dolanyeah19 <Dolanyeah19!~dolanyeah@202.57.8.13> has joined #postfix
[14:39:08] <DonAlex> rob0: It is a postfix server sending mail out to a isp mail relay.
[14:39:42] <DonAlex> the problem is that connection not the webmail => dovecot => postfix..
[14:42:17] <rob0> I didn't see the original problem description, but it sounds like maybe too much tinkering; leave TLS settings at defaults.
[14:43:27] *** jelly <jelly!jelly@pdpc/supporter/active/jelly> has quit IRC (Ping timeout: 240 seconds)
[14:43:39] <DonAlex> rob0: It broke after an upgrade.
[14:45:05] <DonAlex> I strongly feel it is because TLSv1 has been deprecated but somehow I cannot get it to accept it again.
[14:45:54] <DonAlex> If I insert TLSv1 on the smtp_tls_mandatory_protocols line it complains it has NO compatible protocols any more..
[14:47:17] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has quit IRC (Read error: Connection reset by peer)
[14:48:16] *** pti-jean_ <pti-jean_!~quassel@226.12.124.78.rev.sfr.net> has joined #postfix
[14:48:34] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has joined #postfix
[14:50:43] *** jelly-home <jelly-home!jelly@pdpc/supporter/active/jelly> has joined #postfix
[14:57:03] *** ogny <ogny!~orkun@78.186.178.128> has joined #postfix
[14:57:03] *** ogny <ogny!~orkun@78.186.178.128> has quit IRC (Changing host)
[14:57:03] *** ogny <ogny!~orkun@unaffiliated/ogny> has joined #postfix
[15:00:51] <cybrNaut> rob0: running my own webmail front-end wouldn't make a difference, as the relay would still detect the IP of my server and include it in the message.
[15:01:09] <rob0> you cannot possibly, ever, hide that
[15:01:44] <rob0> spammers have been trying for years, and well, yes, they do it; they use botnets
[15:02:01] <rob0> botnets get blocked
[15:02:36] <cybrNaut> rob0: i wouldn't go that far. For example, it would be technically feasible to scrape the page of a webmail service, and have postfix feed mail through that. To the webmail service, it would just be like a user logging in over the web using their GUI
[15:03:49] <cybrNaut> of course that's a big effort to setup, and i think it would also break the possibility of writing my own From: field, which may differ from the webmail svc
[15:04:45] <rob0> you cannot possibly, ever, hide your server IP address if you are an honest operator.
[15:04:59] <cybrNaut> but in any case, the solution would likely be a departure from smtp
[15:05:45] <rob0> what you describe would require valid credentials for the webmail service, and if you are abusing those credentials, they will cut you off
[15:05:46] <cybrNaut> also, a mailgun interface could be an answer here
[15:06:18] <rob0> you're going to have to think about your goal and perhaps discuss it with ESPs
[15:06:22] <rob0> !esp
[15:06:22] <knoba> rob0: "esp" : Email Service Provider
[15:06:24] <cybrNaut> i'm just not sure if mailgun injects originator's IP addresses
[15:07:28] <cybrNaut> in principle, there's no reason webmail users should have more privacy than users of mail clients
[15:07:38] <rob0> Legitimate ESPs don't like hiding; they earn their money by building and maintaining a good reputation.
[15:07:43] <cybrNaut> it's just a clumbsy state of things
[15:08:00] <cybrNaut> sure, but e-mail users like privacy
[15:08:00] <rob0> and you don't seem to get what "webmail" is
[15:08:03] <cybrNaut> privacy is important
[15:08:07] <rob0> use gmail
[15:08:37] <cybrNaut> gmail has a webmail interface and an smtp server, but i don't see how that solves my problem
[15:10:33] <rob0> yes, if you submit to them via SMTP, they put your address in a Received: header. If you use webmail they hide it. And you can do all sorts of illegal and nasty things, hiding behind a gmail address; they won't act on abuse reports, that I have ever seen.
[15:10:53] <rob0> All spammers use gmail drop boxes to receive payment.
[15:12:21] <cybrNaut> either they've scraped gmail, or they're tolerating the manual effort of using gmail's GUI. That's good for criminals perhaps, b/c the payout is worth the effort, but not good for a legit user who doesn't want to expose their IP, and also wants to use their own mail client to make GPG practical
[15:13:04] <DonAlex> I am using a virrtual domain from an ISP that has been taken over ages ago.. call it a legacy email domain, point being up until about 2 weeks ago there was not a problem sending or receiving emails. Now I am receiving them fine but outbound mails get stuck because of a warning: TLS library problem: error:1417118C:SSL routines:tls_process_server_hello:version too low:../ssl/statem/statem_clnt.c:917: error
[15:13:38] <DonAlex> The relay server only supports TLSv1
[15:13:59] <DonAlex> So if the hello version is too low what the hell can I do about it?
[15:14:28] <DonAlex> And no , turning off TLS is NOT a solution.
[15:14:43] <cybrNaut> there should be a way to use postfix without subjecting oneself to criminals who would attack their IP address
[15:15:22] <DonAlex> cybrNaut: if you mean people spamming your postfix server trying to relay mail throuhg you then yes there is.
[15:15:46] <cybrNaut> DonAlex: no, i don't mean that. spam is not a risk in my scenario
[15:15:58] <DonAlex> cybrNaut: then what do you mean ?
[15:16:10] <cybrNaut> DonAlex: there are many attacks not related to spam that target an IP address
[15:16:31] <cybrNaut> i mean literally every kind of penetration attack that stands apart from sending spam
[15:16:43] <DonAlex> cybrNaut: Fail2ban then.. Else if you are talking about DDOS attacks use cloudflare or the like.
[15:16:45] <cybrNaut> notwithstanding the possibility of sending spam after compromise
[15:17:06] <rob0> Postfix is a general-purpose MTA, not a specialized mail anonymizer. No, it's not useful for hiding. The whole point of publishing your domain in DNS is for others to be able to find it.
[15:17:25] *** aindilis <aindilis!~aindilis@172-12-3-117.lightspeed.sgnwmi.sbcglobal.net> has quit IRC (Read error: Connection reset by peer)
[15:17:35] <cybrNaut> DonAlex: you're talking about incident response and perimeter defense, which comes after the disclosure. Better to not have the disclosure in the first place
[15:17:51] <cybrNaut> DonAlex: of course one should still protect their perimeter anyway
[15:19:36] <DonAlex> Then run SNORT on your mailserver, or a edge gateway..
[15:19:59] *** aindilis <aindilis!~aindilis@172-12-3-117.lightspeed.sgnwmi.sbcglobal.net> has joined #postfix
[15:20:20] <cybrNaut> DonAlex: again, that's another IDS solution, which should be in force of course, but cannot replace diligent anti-recon
[15:20:50] <cybrNaut> DonAlex: the IP exposure alone indicates whereabouts, which in itself can be exploited even non-electronically
[15:21:03] <DonAlex> Then hide behind a proxy machine then only open up out going ports and monitor all incoming ones.
[15:21:24] <cybrNaut> DonAlex: that just moves the target
[15:21:28] <DonAlex> I cannot help but feel you are over complicating the issue.
[15:22:00] *** Dolanyeah19 <Dolanyeah19!~dolanyeah@202.57.8.13> has quit IRC (Quit: Nettalk6 - www.ntalk.de)
[15:22:51] <cybrNaut> DonAlex: using a vpn or vps may indeed be the best answer, sadly enough. But that's not gratis (or if it is, there's cause for concern as well)
[15:22:54] <DonAlex> A proxy does not move the target because your proxy will be secure against attack.
[15:23:01] <rob0> Internet mail is impossible to hide. If you want to receive mail, your domain must point to a server which is reachable on port 25.
[15:23:21] <DonAlex> rob0: Or a machine the forward mail to your machine on 25.
[15:23:46] <cybrNaut> rob0: have a look at the mixmaster network. it's not impossible
[15:23:54] <DonAlex> There are plenty of TCP proxies out there that can do all this. You really are not looking hard enough.
[15:23:54] <rob0> If you want to send mail, you must have a valid sender address, and see above; you must be reachable.
[15:24:26] <DonAlex> rob0: you can have a valid sender address if you control your DNS which lets face it should be the only time you run your own mailserver
[15:24:40] <cybrNaut> the sender address is not a problem for me.. that does not contain my IP, and can be retrieved over tor using pop3
[15:26:21] <rob0> If you send mail to me as cybrNaut at example dot onion, I'm not going to accept it, because my mail server can't resolve .onion names.
[15:27:02] <cybrNaut> that's fair enough, i'm not worried about that. onion services tend to have a surface web domain for that purpose
[15:27:52] <rob0> and a surface MAIL domain if using mail. And that address must be findable and reachable.
[15:27:53] <cybrNaut> e.g. protonmail.ch has https://protonirockerxow.onion
[15:28:20] <cybrNaut> sure, that's fine with me
[15:28:45] <cybrNaut> it's the IP that's a problem, not the From: field. I can control the from field
[15:29:07] *** section1 <section1!~section1@181.29.229.252> has joined #postfix
[15:29:09] *** troys <troys!~troys@23-24-139-177-static.hfc.comcastbusiness.net> has joined #postfix
[15:30:08] <rob0> When you submit mail through your server, your server has to deliver it somewhere.
[15:33:14] <DonAlex> Again it is all done with proxies..
[15:33:32] <Gaaab> what might be the cause of mails delivered to gmail ending up in gmails spam folder?
[15:33:45] <DonAlex> How you think google sends and received all it mail with just 6 declared MX records ?
[15:33:59] <cybrNaut> DonAlex: but speaking of proxies, how is that done in postfix? AFAIK, postfix does not have SOCKS capability
[15:34:41] <DonAlex> cybrNaut: Does not need socks if it is on your network does it? Do it over a VPN for all I care.. if the proxy is under your control then what is the problem ?
[15:36:09] <DonAlex> point being the proxies only has to forward x ports in and out and have NOTHING ELSE that could be exploited on the box.
[15:36:31] <cybrNaut> DonAlex: whether the proxy is under my control is a separate question. Certainly i can buy service which is under someone elses control (non-gratis generally), or i can make my own, but I still need to rent access
[15:37:22] <DonAlex> The proxy can be a VM on your Server machine if it comes to that. Bottom line is when you separate services you separate attack vectors..
[15:37:26] <cybrNaut> if i make my own proxy, then I have the effort of securing it, and still the cost of the rack space
[15:38:00] <DonAlex> cybrNaut: Oh FFS what do you want security or ease of use?
[15:38:03] <rob0> If you want Mixmaster, why aren't you using Mixmaster?
[15:38:07] <DonAlex> You cannot have both.,
[15:38:57] <patdk-wk> DonAlex, sure you can, outsource it
[15:39:11] *** FinboySlick <FinboySlick!~shark@74.117.40.10> has joined #postfix
[15:39:51] <DonAlex> patdk-wk: Yeah but he is complaining about rack rental. You think he wants to pay double that to get someone to do it for him?
[15:40:00] <cybrNaut> DonAlex: i don't need ease of setup, just the ease of using my own client and postfix, but ideally gratis, of course w/the security constraint of not leaking IP
[15:41:16] <DonAlex> Well good luck with that because it is basic administration skills being about to mask services..
[15:41:26] <cybrNaut> rob0: i am, but mixmaster has the problem of /forcing/ the From: field to be something unusable, which means replies are not possible. I could nest the address in the body, but that creates extra burdon for the recipient
[15:42:52] <patdk-wk> donalex, then your added a third option, cheap
[15:42:54] <cybrNaut> mixmaster is also extremely slow and absurdly unreliable
[15:43:07] <patdk-wk> cybrNaut, that is insane
[15:43:15] <patdk-wk> you should always be able to reply
[15:43:41] <patdk-wk> how else will you keep your mailings clean of bounces that will move you into a spam source
[15:43:51] <cybrNaut> patdk-wk: i wouldn't say always.. sometimes i want to prevent replies. But sure most of the time I want a reply option
[15:44:00] <patdk-wk> ALWAYS
[15:44:28] <rob0> Gaaab, could be lots of things, most likely not associated with Postfix or how it is configured. The one thing I'll WAG is this:
[15:44:35] <rob0> !tell Gaaab fcrdns
[15:44:35] <knoba> Gaaab: "fcrdns" : http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS : your IP address should resolve to $myhostname, which in turn should resolve back to your IP. This is very important if you want big sites to accept your mail. If you can't have it from your ISP, see !relayhost
[15:44:40] <cybrNaut> no, not always. why do you think banks send msgs formed as: no-reply at bankofamerica dot com?
[15:45:07] <Gaaab> cybrNaut mixmaster from field is not unusable but is an ordinary email address of some mixmaster node in the form user@domain
[15:45:18] <patdk-wk> cybrNaut, they can do that, but they still have to accept replies to that address
[15:45:29] <cybrNaut> sometimes i'm sending a msg to a hostile recipient and i don't want them to easily reply
[15:45:42] <cybrNaut> patdk-wk: they don't. The address is often defunct
[15:45:48] <cybrNaut> and rightly so
[15:45:53] <patdk-wk> no not rightly
[15:45:53] <rob0> DonAlex, if you want help you're going to have to make a pastebin,
[15:45:59] <rob0> !relevant_logs
[15:45:59] <knoba> rob0: "relevant_logs" : mail.* syslog Postfix log messages (NOT verbose, see !no_verbose) which show ONLY the entire handling of a single mail which illustrates the issue with which you want help. Random selections from your mail log are not adequate. IMAP/POP3 daemons and external delivery agents often log to the same syslog facility and should not be shown. Also see http://rob0.nodns4.us/postfix-logging
[15:46:01] <patdk-wk> they should accept and process bounce emails
[15:46:04] <rob0> !showconfig
[15:46:04] <knoba> rob0: "showconfig" : when asked to provide your config, please provide a SINGLE pastebin (see !pastebin) with postconf -nf and postconf -Mf. if your version is too old for those commands to work (< 2.9), you should upgrade, but see !showconfig_old
[15:46:12] <patdk-wk> if not, they go to the spam list
[15:46:23] <cybrNaut> patdk-wk: that's a recipe for /backscatter/
[15:46:33] <cybrNaut> bounces should come at connection time
[15:46:48] <cybrNaut> as the server is connected, not relying on a return address
[15:46:53] <patdk-wk> heh?
[15:47:00] <patdk-wk> who do you send mail to?
[15:47:17] <patdk-wk> over half the people I send email to, do not process valid receipients at the edge
[15:47:50] <patdk-wk> now half of my mail goes to dod
[15:48:34] <cybrNaut> what's dod?
[15:48:45] <patdk-wk> .mil
[15:49:33] <cybrNaut> you would think dod would not be using a technique that is vulnerable to backscatter
[15:49:41] <patdk-wk> heh
[15:49:43] <cybrNaut> but that's not really your problem
[15:49:47] <patdk-wk> you forget that they are segmented
[15:49:58] <patdk-wk> so it is impossible for their edge to know what is 3 or 4 layers deper
[15:50:05] <patdk-wk> its a huge problem with .mil
[15:51:27] <DonAlex> rob0: I have made a few here is it all together https://pastebin.ca/3902477
[15:53:06] <DonAlex> rob0: I only added the fingerprint stuff recently trying to get around the hello version issue
[15:53:26] <DonAlex> rob0: Made no difference anyway
[15:53:42] <rob0> wrappermode?
[15:54:04] <cybrNaut> patdk-wk: it depends on the situation though.. i was once on a mailing list where other members foolishly sent a personal copy along with a list copy, the order of which is not deterministic, and so it would screw up procmail filtering. Since I didn't need a personal reply from list members, i used a bogus address, and that stopped the abuse
[15:54:11] <DonAlex> Yeah mandates it some reason.
[15:54:53] <patdk-wk> well, your using port 465 that shouldn't be used
[15:55:03] <rob0> I guess the other end doesn't support what you have limited your side to use.
[15:55:25] <DonAlex> patdk-wk: Yeah well tell that to my stupid ISP
[15:55:57] <patdk-wk> DonAlex, seems to work fine on port 587
[15:56:09] <DonAlex> oh?
[15:56:22] <DonAlex> That is not SSL
[15:56:30] <patdk-wk> heh?
[15:56:42] <DonAlex> openssl s_client -host relay.clara.net -port 587
[15:56:48] <DonAlex> go check
[15:57:02] <DonAlex> openssl s_client -connect relay.clara.net:465
[15:57:05] <DonAlex> is however
[15:57:05] <patdk-wk> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA256
[15:57:05] <patdk-wk> Server public key is 2048 bit
[15:57:05] <patdk-wk> Secure Renegotiation IS supported
[15:57:05] <patdk-wk> Compression: NONE
[15:57:05] <patdk-wk> Expansion: NONE
[15:57:06] <patdk-wk> SSL-Session:
[15:57:08] <patdk-wk> Protocol : TLSv1.2
[15:57:12] <patdk-wk> Cipher : DHE-RSA-AES256-SHA256
[15:57:14] <patdk-wk> Session-ID: CA21DC4C50A187B802F7488D1522761291C4100E6F020FEEC37F27D3757B2A97
[15:57:16] <patdk-wk> Session-ID-ctx:
[15:57:18] <patdk-wk> Master-Key: 71DFBF5F584D229D3E7DF0B8C32DA4074762E5E39ACDF1308DC717D65944126809FCFE337B38BD4FB119404346740CA3
[15:57:21] <patdk-wk> Key-Arg : None
[15:57:23] <patdk-wk> PSK identity: None
[15:57:25] <patdk-wk> PSK identity hint: None
[15:57:27] <korozion> jebus man, pastebin
[15:57:27] <patdk-wk> SRP username: None
[15:57:29] <patdk-wk> Start Time: 1509548210
[15:57:31] <patdk-wk> Timeout : 300 (sec)
[15:57:33] <patdk-wk> Verify return code: 20 (unable to get local issuer certificate)
[15:57:37] <patdk-wk> 250 HELP
[15:57:39] <patdk-wk> looks like tls to me, not ssl
[15:57:39] <DonAlex> Yeah pastebin buddy
[15:57:43] <patdk-wk> donalex, use openssl s_client correctly
[15:58:12] <patdk-wk> openssl s_client -connect relay.clara.net:587 -starttls smtp
[15:58:18] <DonAlex> well if it is just a case of moving ports that is simple.
[15:58:19] <DonAlex> one mo
[15:58:41] <rob0> probably not that simple, no
[15:58:50] <patdk-wk> looks like it is
[15:58:54] <patdk-wk> 465 only does tls1.2
[15:58:58] <patdk-wk> but 587 does the full range
[15:58:59] <rob0> oh
[15:59:06] <patdk-wk> ony ldoes tlsv1.0 I mean
[15:59:23] <patdk-wk> and only aes-sha
[15:59:33] <patdk-wk> I get full cipher options and protocol on 587
[15:59:35] <DonAlex> patdk-wk: Frak me you are right..
[15:59:38] <rob0> interesting, why would they have different SSL on different ports of the same host?
[15:59:44] <DonAlex> Seems to work now.. Terrific.
[15:59:52] <patdk-wk> likely using ssltunnel or something on 465
[15:59:54] <DonAlex> Oh no wait..
[16:00:09] <DonAlex> Nope spoke too soon
[16:00:19] <patdk-wk> ssl/tls issue or something else?
[16:01:05] *** ogny <ogny!~orkun@unaffiliated/ogny> has quit IRC (Ping timeout: 240 seconds)
[16:03:03] *** cemotyz09 <cemotyz09!~cemotyz09@cpe-70-121-157-202.satx.res.rr.com> has joined #postfix
[16:03:18] <DonAlex> patdk-wk: bottom of the pastebin. https://pastebin.ca/3902485
[16:04:01] <DonAlex> HAng on I blocked !SSLv3 ?
[16:04:09] <DonAlex> wtf is it complaining about that?
[16:05:03] <DonAlex> Ahh wait it is that the cache to blame?
[16:05:11] <DonAlex> let me remove it and try again.
[16:06:15] <DonAlex> BLEAH.. no apparently not.
[16:06:28] <patdk-wk> I would remove the smtp_tls_protocols line
[16:07:12] <patdk-wk> like 38 should be redundand as that is the default
[16:08:27] *** Voovode <Voovode!~Alex@webaccess1.hq.purplewifi.net> has joined #postfix
[16:08:40] <DonAlex> hmmm ok
[16:08:43] *** stfacc <stfacc!~stfacc@88.191.30.172> has left #postfix ("Good Bye")
[16:09:49] <DonAlex> Nope.. still the same :(
[16:11:41] <patdk-wk> must be something with your ssl lib
[16:11:49] <patdk-wk> your not using like centos5 are you?
[16:12:51] <DonAlex> No.. Debian/Testing openssl 1.1.0f-5
[16:13:40] <DonAlex> postfix 3.2.3-1
[16:15:34] <DonAlex> I could try cranking up debugging I suppose..
[16:22:27] <DonAlex> patdk-wk: ok.. new pastebin. verbose 5 peer https://pastebin.ca/3902493
[16:22:43] <patdk-wk> what the hell?
[16:22:46] <patdk-wk> !verbose
[16:22:46] <knoba> patdk-wk: "verbose" : You probably do not need verbose logging, but in very rare cases, the extra detail might assist in debugging. To set verbose logging, add a -v after the command name (such as smtpd) in master.cf, then 'postfix reload' after that
[16:22:53] <patdk-wk> !getting_help
[16:22:53] <knoba> patdk-wk: "getting_help" : before asking your question, read the !relevant_logs and !showconfig factoids, and prepare a single pastebin containing all of that data. if you don't understand what this means, or if you need help doing this, please let us know. also see !pastebin
[16:24:23] <DonAlex> knoba: Yes I have an existing pastebin but that last log would make it incomprehensibly big.
[16:25:31] <DonAlex> patdk-wk: You can turn on debug_peer and log between peers..
[16:25:42] <DonAlex> patdk-wk: That is what I did,
[16:25:47] <patdk-wk> ya, I just don't remember anyone asking for verbose>0
[16:25:54] <patdk-wk> or a debug output
[16:26:07] <patdk-wk> that log is useless
[16:26:09] <DonAlex> patdk-wk: Yeah well we were getting nowhere with the standard log were we ?
[16:26:23] <patdk-wk> it's not a postfix issue, postfix logs won't fix it
[16:26:56] <DonAlex> patdk-wk: I am sure postfix is able to fix it but the trouble is what needs fixing ?
[16:27:20] <patdk-wk> tls
[16:28:11] <DonAlex> patdk-wk: Where though , the server ? in which case I am SOL
[16:28:29] <DonAlex> patdk-wk: or the postfix smtp client ?
[16:31:56] <rob0> !smtp_tls_loglevel
[16:31:56] <knoba> rob0: "smtp_tls_loglevel" : Enable additional Postfix smtp(8) client logging of TLS activity, default 0, 1 is a good operational setting. Each logging level also includes the information that is logged at all lower logging levels.
[16:32:48] <rob0> it MIGHT be worth looking at smtp_tls_loglevel=2, but I won't have time to do that.
[16:33:09] <rob0> otherwise stay strictly with non-verbose logs
[16:34:41] <rob0> If you're able to discern anything from that messy TLS loglevel, it will be that you have limited your side to settings the other side doesn't support.
[16:34:59] <rob0> Often just going back to default settings will fix this. :)
[16:35:53] <DonAlex> rob0: well like I say was working 2 weeks ago.. upgrade broke it so.. ?
[16:36:11] <rob0> yep, probably upgraded openssl also
[16:38:49] <DonAlex> yeah..
[16:38:59] <DonAlex> *sighs*
[16:39:31] <patdk-wk> probably disabled things to make *https* safer
[16:39:42] <patdk-wk> debian is known for doing that
[16:39:51] <patdk-wk> in the openssl package
[16:40:21] <DonAlex> maybe.. still curious why the error appears inthe ssl3 library ?
[16:40:39] <DonAlex> warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252:
[16:40:41] <patdk-wk> heh?
[16:40:57] <patdk-wk> that is all normal
[16:41:18] <DonAlex> glad you think so ;) It is a warning too not an error. but even so.
[16:41:46] <DonAlex> This is actual error
[16:41:49] <patdk-wk> yes it's a warning, cause it could failover to non-ssl, but you had that disabled so
[16:41:50] <DonAlex> Cannot start TLS: handshake failure
[16:42:22] <DonAlex> hell yeah.. no way I am not using SSL for smtp at the very least
[16:44:46] *** Robby <Robby!robby@chillum.thcgirls.com> has joined #postfix
[16:49:19] *** aindilis <aindilis!~aindilis@172-12-3-117.lightspeed.sgnwmi.sbcglobal.net> has quit IRC (Ping timeout: 248 seconds)
[16:52:52] *** r0kc4t <r0kc4t!~frosch@felderundfiguren.de> has quit IRC (Remote host closed the connection)
[16:53:28] <jimpop> i get those SSL errors often, it's because you are delivering email to old outdated servers (MS Exchange) that are using vulnerable protocols.
[16:53:56] *** timdotrb <timdotrb!~timdotrb@ip70-190-186-81.ph.ph.cox.net> has joined #postfix
[16:58:41] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has quit IRC (Read error: Connection reset by peer)
[16:58:58] <patdk-wk> jimpop, not true
[16:59:05] <patdk-wk> if that was the case, it wouldn't support tls 1.2
[16:59:28] <patdk-wk> it would only support ssl3 and iffy if it supported tls 1.0
[17:00:04] <patdk-wk> in a generic case, sure, but no in this specific case
[17:00:08] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has joined #postfix
[17:00:16] *** Oclairi <Oclairi!~Oclair@178-190-52-14.adsl.highway.telekom.at> has quit IRC (Quit: Bye Bye)
[17:00:27] <jimpop> the logged error is because there is no SSLv3 enabled on the sending host, no?
[17:00:49] <patdk-wk> it might be
[17:00:51] <patdk-wk> dunno
[17:00:59] <patdk-wk> but I have no ssl3 enabled and I connect fine using tls 1.2 to it
[17:01:11] *** troys is now known as troys_
[17:01:31] <jimpop> you proably have those same log errors if you enable some verbose level of logging.
[17:01:34] <patdk-wk> it is saying his server and the remote server cannot agree, that doesn't mean, only ssl3 works
[17:01:55] <patdk-wk> he didn't enable verbose though for tls
[17:01:58] <jimpop> agreed, but i never said that ;-)
[17:01:59] <patdk-wk> only for postfix
[17:02:21] <patdk-wk> and he can connect to it using openssl s_client, using tls 1.2
[17:02:32] <patdk-wk> so openssl works, it's just likely a config setting he added to postfix
[17:02:45] <patdk-wk> debian disabled ssl3 in openssl and you cannot reenable it
[17:02:56] <patdk-wk> not without compiling it yourself and reinstalling openssl
[17:03:22] <jimpop> but why would anyone do that?
[17:04:12] <jimpop> postfix still logs errors when the remove server wants to talk SSLv3, even if the local server (postfix on debian) doesn't support it.
[17:04:53] <patdk-wk> yes
[17:05:12] <patdk-wk> still not the issue though
[17:05:41] <jimpop> i don't support sslv3, but constantly see tons of sslv3 errors. i.e.:
[17:05:44] <jimpop> warning: TLS library problem: error:14094417:SSL routines:ssl3_read_bytes:sslv3
[17:06:21] <jimpop> those errors are related to smtp (not smtpD) transactions.
[17:07:28] *** troys_ is now known as troys
[17:10:07] <patdk-wk> yes, but what does that have to do with THIS case?
[17:10:20] *** jas02 <jas02!~jas02@193.179.215.98> has quit IRC (Remote host closed the connection)
[17:10:35] <patdk-wk> we know what the message means
[17:10:52] <patdk-wk> in the order of finding a match, it didn't find one, and it errored at the lowest level, ssl3
[17:10:55] <patdk-wk> that is to be expected
[17:11:04] <patdk-wk> it is not the case that the server only supports ssl3, it supports higher
[17:11:07] *** jas02 <jas02!~jas02@193.179.215.98> has joined #postfix
[17:11:20] <patdk-wk> so we can make it work, it's just finding what bad config option was givin to cause the better match to fail
[17:12:28] <jimpop> it's the remote server saying it only supports sslv3
[17:12:52] <jimpop> if you can find the bad config in the remote server.... go for it :-)
[17:13:37] <jimpop> the REAL problem is postfix logging sslv3 errors in the same verbosity needed to see TLS details in log files.
[17:13:59] <patdk-wk> no, it's not
[17:14:17] <jimpop> unsupported protocol errors should be at verbosity 3 or higher
[17:14:17] <patdk-wk> I can connect to the remove server using tls 1.2, and so can he
[17:14:45] <jimpop> but can you send email to the remote server using tls 1.2?
[17:15:00] <patdk-wk> that is a totally different issue
[17:15:12] <patdk-wk> he cannot connect to the remote server with ssl, at all
[17:15:13] <jimpop> you may not be hitting the actual mx, but rather a frontend
[17:15:32] <patdk-wk> hmm, we are diagnosing ssl, not smtp
[17:15:44] <patdk-wk> we haven't even made it to smtp, cause ssl won't connect
[17:16:33] *** jas02 <jas02!~jas02@193.179.215.98> has quit IRC (Ping timeout: 248 seconds)
[17:16:41] *** timdotrb <timdotrb!~timdotrb@ip70-190-186-81.ph.ph.cox.net> has quit IRC (Quit: timdotrb)
[17:17:37] <jimpop> ssl shouldn't work (it's 2017), tls should be the gold standard (or maybe I'm missing what you are saying)
[17:18:02] <patdk-wk> oh, now you want to split hairs?
[17:18:12] <jimpop> not really
[17:18:14] <patdk-wk> ssl was renamed to tls over political issues
[17:18:17] <patdk-wk> but it's the same thing
[17:18:25] <patdk-wk> tls 1.0 is ssl 3.1
[17:18:28] <patdk-wk> by definition
[17:18:54] <patdk-wk> the server won't agree with the client on tls 1.2, tls 1.1, tls 1.0
[17:19:01] <jimpop> i read "ssl" as "sslv3" because you previousy wrote "tls 1.2" when you meant tls
[17:19:03] <patdk-wk> so then the client spits out a ssl 3.0 won't work cause it's denied
[17:19:20] <patdk-wk> it connects fine on tls 1.0, tls 1.1 and tls 1.2
[17:19:29] <patdk-wk> on the same box
[17:19:32] <patdk-wk> just not using postfix
[17:19:38] <jimpop> that sounds like a downgrade attack
[17:19:47] <patdk-wk> no
[17:19:48] <jimpop> force the server to use an insecure protocal
[17:19:53] <jimpop> *protocol
[17:19:59] <patdk-wk> it could be, but that would happen to ALL connections
[17:20:02] <patdk-wk> not just ones from postfix
[17:20:07] <jimpop> mitm or a company with shaddy practices
[17:20:22] <patdk-wk> then why does another application on the same postfix machine work?
[17:20:30] <patdk-wk> mitm knows exactly what application is being used?
[17:20:37] <jimpop> load balanced MX?
[17:20:38] <patdk-wk> and only selectively mitm's the connection
[17:20:46] <patdk-wk> same issue
[17:20:52] <patdk-wk> how do they know to ONLY affect postfix
[17:21:02] <jimpop> by source IP?
[17:21:02] <patdk-wk> when the source ip is the same, and randomized source ports
[17:21:15] <jimpop> whitelist?
[17:21:30] <patdk-wk> whteilst is a list, what is on the list
[17:21:44] <patdk-wk> how does it know the difference between ssl/tls/... clients before connection?
[17:21:49] <jimpop> IPs to downgrade for an IDS?
[17:21:51] <patdk-wk> when the source location is the exact same
[17:22:01] <patdk-wk> IDS info is the same
[17:22:07] <patdk-wk> ssl data from same source ip and os
[17:22:29] <patdk-wk> using the same libssl
[17:22:57] <jimpop> some Intrusion Detection Systems downgrade security to read content
[17:23:18] <patdk-wk> yes, but why doesn't it downgrade openssl s_client, but only postfix?
[17:23:26] <patdk-wk> there is no way for it to know the difference between the two
[17:23:33] <jimpop> different fingerprint probably
[17:23:40] <patdk-wk> there is no different fingerprint
[17:23:46] <patdk-wk> both fingerprints are libssl and the os
[17:23:48] <jimpop> think nmap
[17:24:03] <patdk-wk> yes, but nmap can only detect the os based on tcp params from the os defaults
[17:24:06] <patdk-wk> the os is the same
[17:24:10] <patdk-wk> so fingerprints are the same
[17:24:41] <patdk-wk> unless postfix is overriding the window sizes and other things (that it doesn't do)
[17:24:42] <jimpop> i highly doubt the handshake or handshake timing (retries, etc.) would be identical
[17:24:54] <patdk-wk> how so?
[17:25:00] <patdk-wk> those are not being adjusted by postfix
[17:25:03] <patdk-wk> but are set by the os
[17:25:22] <patdk-wk> so yes, they should be identical if coming from the *same* box, that they are in this case
[17:25:54] <jimpop> maybe s_client tries multiple times, whereas postfix tries once
[17:26:00] <jimpop> or vice versa
[17:26:03] <patdk-wk> nope
[17:26:08] <patdk-wk> both connect on first try
[17:26:11] <patdk-wk> there was no retry
[17:26:24] <jimpop> what's the data sent with each?
[17:26:27] <patdk-wk> and no, postfix doesn't even offer you a retry, only a timeout
[17:26:28] *** zw <zw!~wesley@spider.pfoe.be> has quit IRC (Quit: leaving)
[17:26:34] <jimpop> header data?
[17:26:43] <jimpop> surely there is some difference
[17:26:52] <patdk-wk> if there is, your os is very screwy
[17:27:04] <patdk-wk> to make that much of a difference between tcp connections
[17:27:32] <jimpop> it's like SSH vs s_client, there is just no way they fingerprint the same on "connect"
[17:27:43] <patdk-wk> ssh and s_client are TOTALLY different
[17:27:46] <patdk-wk> ssh isn't even ssl
[17:28:04] <jimpop> yeah, but you get my point
[17:28:14] <patdk-wk> I get you point, and telling you it doesn't apply at all
[17:28:25] <jimpop> using lbssl doesn't mean all transactions are identical
[17:28:38] <jimpop> there are lots of variables
[17:28:54] <jimpop> and it's highly possible that postfix sets something that s_client doesn't
[17:28:55] <patdk-wk> yes, and I'm saying those variables are controlled within postfix
[17:29:12] <patdk-wk> it's not an issue that only the remote side can solve
[17:29:16] <patdk-wk> cause s_client works fine
[17:29:37] <patdk-wk> so we know it's not some stupid only supports ssl3 issue
[17:29:57] <patdk-wk> if it is or is not an IDS, doesn't matter
[17:30:02] <patdk-wk> cause it works
[17:30:08] <jimpop> but s_client only replicates a tiny piece of the transaction
[17:30:10] <patdk-wk> postfix just has to be corrected on that machine to work
[17:30:17] <patdk-wk> jimpop, heh?
[17:30:25] <patdk-wk> it replicates connecting with ssl/tls
[17:30:28] <patdk-wk> that is the problem
[17:30:35] <patdk-wk> we don't are about smtp, we haven't gotten to smtp yet
[17:30:40] <patdk-wk> it fails before smtp
[17:31:03] <jimpop> i think it's failing after connect when the remote tries to downgrade to sslv3
[17:31:16] <patdk-wk> yes
[17:31:21] <patdk-wk> cause tls 1+ fails
[17:31:26] <jimpop> you don't see the downgrade with s_client
[17:31:40] <patdk-wk> yes, cause ssl/tls connection works using tls 1+
[17:31:47] <patdk-wk> so there is an issue with ssl, not smtp
[17:31:54] <patdk-wk> come on, this is all basic crap
[17:32:06] <patdk-wk> downgrade is standard ssl policy, forever
[17:32:15] <patdk-wk> try what you can do, and downgrade to something that works
[17:32:16] <jimpop> but sslv3 is disabled, so the sending postfix can't continue
[17:32:25] <patdk-wk> start with tls 1.2, then 1.1 then 1.0, then ssl 3.0, then ssl 2.0
[17:32:36] <patdk-wk> when it hits the bottom of the client support (ssl 3.0) it fails, in this case
[17:32:40] <patdk-wk> it is EXPECTED
[17:32:47] <jimpop> yep
[17:32:53] <jimpop> there is no fixiing that
[17:32:55] <patdk-wk> the question is why TLS 1.0 1.1 and 1.2 ALL FAILED
[17:33:02] <patdk-wk> there is fixing that
[17:33:07] *** Voovode <Voovode!~Alex@webaccess1.hq.purplewifi.net> has quit IRC (Remote host closed the connection)
[17:33:20] <patdk-wk> when it clearly works with s_client
[17:33:24] <jimpop> they didn't fail, unless they fail on ALL smtp transactions
[17:33:30] <patdk-wk> they do
[17:33:41] <jimpop> so no tlsv1.2 ?
[17:33:46] <jimpop> can't send to gmail?
[17:33:56] <patdk-wk> hmm, ssl ia a per connection issue
[17:34:11] <patdk-wk> gmail can support a different collection of ciphers than the other host
[17:34:16] <patdk-wk> but both would support tls 1.2
[17:34:17] <jimpop> right, and i read it as only failing on one endpoint
[17:34:21] <patdk-wk> yes
[17:34:39] <patdk-wk> but we can't say that both support the DHE encryption, that has been depressiated
[17:34:43] <patdk-wk> that that client supports
[17:34:49] <patdk-wk> I don't believe gmail EVER supported DHE
[17:35:02] <jimpop> and i am saying that one endpoint is doing a downgrade "attack" probably to inspect traffic at the edge
[17:35:05] <patdk-wk> dhe is very cpu intensive
[17:35:26] <patdk-wk> then why would it work?
[17:35:31] <patdk-wk> it's not a downgrade attack
[17:35:43] * jimpop bets the endpoint in question is a health care provider or a financial organization.
[17:35:58] <patdk-wk> his ISP?
[17:36:07] <jimpop> is that the endpoint?
[17:36:09] <patdk-wk> I don't believe they double up as a healthcare or bank
[17:36:10] <patdk-wk> yes
[17:36:19] <jimpop> oh, well then that's just lame
[17:36:33] <patdk-wk> DHE is a windows normally only support cipher though
[17:36:38] <jimpop> but then again ISPs aren't known for security
[17:36:45] <patdk-wk> but that proves he is running atleast windows 2008r2
[17:36:50] <patdk-wk> well, his ISP
[17:37:17] <patdk-wk> it's not normally used due to it's cpu intesiveness
[17:37:37] <jimpop> unless it was sold that way by a hardware vendor
[17:47:51] *** gu1lle_ <gu1lle_!~Thunderbi@181.167.195.114> has joined #postfix
[17:50:28] *** Jellyg00se <Jellyg00se!~Alfie@195.99.134.162> has quit IRC (Quit: Leaving)
[17:51:43] *** troulouliou_div2 <troulouliou_div2!~troulouli@unaffiliated/troulouliou-div2/x-0271439> has joined #postfix
[17:55:42] *** olegfusion <olegfusion!~olegfusio@mail.mobileforsale.ru> has quit IRC (Read error: Connection reset by peer)
[17:56:08] *** olegfusion <olegfusion!~olegfusio@mail.mobileforsale.ru> has joined #postfix
[17:56:33] *** ujjain <ujjain!~ujjain@unaffiliated/ujjain> has quit IRC (Ping timeout: 248 seconds)
[18:01:19] *** nomeed <nomeed!~nomeed@p579CEB40.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
[18:01:20] *** ujjain <ujjain!~ujjain@144.76.19.126> has joined #postfix
[18:01:21] *** ujjain <ujjain!~ujjain@144.76.19.126> has quit IRC (Changing host)
[18:01:21] *** ujjain <ujjain!~ujjain@unaffiliated/ujjain> has joined #postfix
[18:06:36] <DonAlex> Sorry had another call. So any ideas on this TLS hello issue?
[18:07:35] *** led_ir22 <led_ir22!~Thunderbi@hotspot10.rywasoft.net> has joined #postfix
[18:09:20] <sla3k> Hi, I generated SSL certificates using openssl for my testing with postfix/dovecot. When I try to send an email on the submission port (587), I see these errors logging in in the log file: http://sprunge.us/TaWM Any ideas?
[18:12:27] *** SCHAPiE <SCHAPiE!~schapie@unaffiliated/schaap137> has quit IRC (Ping timeout: 260 seconds)
[18:12:28] *** roxlu <roxlu!~roxlu@37-97-169-45.colo.transip.net> has quit IRC (Ping timeout: 240 seconds)
[18:12:43] <rob0> The "unknown ca" warning is not a problem. The "lost connection" means that the client, for some reason known only to it, was unable to continue.
[18:13:02] *** Freeaqingme <Freeaqingme!~quassel@149.210.181.20> has quit IRC (Ping timeout: 260 seconds)
[18:14:57] *** roxlu <roxlu!~roxlu@vps.roxlu.com> has joined #postfix
[18:15:43] *** spammy <spammy!~shawniver@206.225.79.131> has quit IRC (Ping timeout: 248 seconds)
[18:16:13] *** spammy <spammy!~shawniver@208-70-47-114.bb.hrtc.net> has joined #postfix
[18:17:03] *** Freeaqingme <Freeaqingme!~quassel@149.210.181.20> has joined #postfix
[18:20:12] *** SCHAPiE <SCHAPiE!~schapie@unaffiliated/schaap137> has joined #postfix
[18:25:35] <sla3k> rob0: hmm, interesting...This happens when I try to telnet and issue STARTTLS.....http://sprunge.us/ZYNM
[18:25:49] <sla3k> And the same error is logged in the log file.
[18:26:21] *** some <some!~1@189.164.24.26> has joined #postfix
[18:29:40] *** some <some!~1@189.164.24.26> has quit IRC (Changing host)
[18:29:40] *** some <some!~1@unaffiliated/tharkun> has joined #postfix
[18:29:45] *** some is now known as tharkun_
[18:31:41] *** albech <albech!~Thunderbi@5.103.131.12> has quit IRC (Read error: Connection reset by peer)
[18:32:51] *** albech <albech!~Thunderbi@5.103.131.12> has joined #postfix
[18:39:12] *** nomeed <nomeed!~nomeed@p579CEB40.dip0.t-ipconnect.de> has joined #postfix
[18:39:32] *** nomeed <nomeed!~nomeed@p579CEB40.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
[18:39:53] *** nomeed <nomeed!~nomeed@p579CEB40.dip0.t-ipconnect.de> has joined #postfix
[18:40:32] *** nomeed <nomeed!~nomeed@p579CEB40.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
[18:42:28] *** nomeed <nomeed!~nomeed@p579CEB40.dip0.t-ipconnect.de> has joined #postfix
[18:43:41] <lunaphyte> sla3k: telnet does not do encryption
[18:45:11] <sla3k> lunaphyte: So that is the reason the connection is closed by the server..
[18:46:39] <sla3k> But I cannot figure out why is it closing the connection after the client do STARTTLS...I am using this PHP plugin for wordpress for testing which sends email using SMTP server instead of phpmail(), not related but I thought I'd mention. Also, the certificates are self generated, maybe that is the case?
[18:52:02] <lunaphyte> if you want to test encryption, use s_client
[18:52:21] <lunaphyte> or gnutls-cli
[18:55:00] *** Gaaab <Gaaab!~Gaaab@host200-73-dynamic.182-80-r.retail.telecomitalia.it> has quit IRC (Remote host closed the connection)
[19:23:47] *** TheGallopingFox <TheGallopingFox!~TheGallop@gateway/vpn/privateinternetaccess/thegallopingfox> has joined #postfix
[19:24:17] <TheGallopingFox> what is the best way to setup a out of office reply message on postfix?
[19:24:38] <TheGallopingFox> i could do it client end but that means keeping the client machine on
[19:26:35] <TheGallopingFox> vacation is the tool!
[19:29:42] *** troys is now known as troys_
[19:32:52] *** trn <trn!jhj@prone.ws> has quit IRC (Quit: quit)
[19:40:53] <jaybe> TheGallopingFox, may wish to learn about dovecot and sieve
[19:48:11] <TheGallopingFox> i wonder if there is a clever way to turn on auto reply by sending a email
[19:48:21] <TheGallopingFox> rather than logging into the mail server to do it, pain
[19:48:45] <TheGallopingFox> i run dovecot already, need to learn sieve
[19:50:12] <TheGallopingFox> auto reply when its not spam is important!
[19:50:13] <TheGallopingFox> https://wiki2.dovecot.org/Pigeonhole/Sieve/Examples
[19:53:09] *** trn <trn!jhj@prone.ws> has joined #postfix
[20:11:13] *** synthroid <synthroid!~synthroid@gateway/vpn/privateinternetaccess/synthroid> has quit IRC (Remote host closed the connection)
[20:15:35] *** synthroid <synthroid!~synthroid@gateway/vpn/privateinternetaccess/synthroid> has joined #postfix
[20:17:56] *** golden_receiver <golden_receiver!~golden_re@unaffiliated/golden-receiver/x-4949035> has quit IRC (Read error: Connection reset by peer)
[20:19:12] *** golden_receiver <golden_receiver!~golden_re@unaffiliated/golden-receiver/x-4949035> has joined #postfix
[20:19:57] *** synthroid <synthroid!~synthroid@gateway/vpn/privateinternetaccess/synthroid> has quit IRC (Ping timeout: 240 seconds)
[20:30:45] *** synthroid <synthroid!~synthroid@gateway/vpn/privateinternetaccess/synthroid> has joined #postfix
[20:47:39] *** troys_ is now known as troys
[20:55:03] *** NwS <NwS!~NwS@unaffiliated/nws> has joined #postfix
[20:55:43] *** jas02 <jas02!~jas02@193.165.24.163> has joined #postfix
[20:57:17] *** DonAlex <DonAlex!~DonAlex@2a00:23c1:c02:4700:228:f8ff:feba:c4b2> has quit IRC (Quit: Ex-Chat)
[20:57:57] *** Isla_de_Muerte <Isla_de_Muerte!~NwS@unaffiliated/nws> has quit IRC (Ping timeout: 240 seconds)
[20:57:59] *** section1 <section1!~section1@181.29.229.252> has quit IRC (Quit: Leaving)
[21:09:20] *** rsx <rsx!~rsx@ppp-46-244-241-131.dynamic.mnet-online.de> has quit IRC (Remote host closed the connection)
[21:10:16] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has quit IRC (Read error: Connection reset by peer)
[21:11:37] *** jucaroba <jucaroba!~quassel@static-2-251-85-188.ipcom.comunitel.net> has joined #postfix
[21:14:15] *** Oclair <Oclair!~Oclair@178-190-52-14.adsl.highway.telekom.at> has joined #postfix
[21:26:27] *** troys is now known as troys_
[21:34:30] *** patdk-wk <patdk-wk!~dswett@2001:470:e0ba:15:1a03:73ff:fe2a:d75> has quit IRC (Ping timeout: 246 seconds)
[21:35:02] *** patdk-wk <patdk-wk!~dswett@2001:470:e0ba:15:1a03:73ff:fe2a:d75> has joined #postfix
[21:39:59] *** idkCpp <idkCpp!~martin@193-81-103-172.adsl.highway.telekom.at> has joined #postfix
[21:55:41] *** synthroid <synthroid!~synthroid@gateway/vpn/privateinternetaccess/synthroid> has quit IRC ()
[21:56:23] *** troulouliou_div2 <troulouliou_div2!~troulouli@unaffiliated/troulouliou-div2/x-0271439> has quit IRC (Quit: Leaving)
[22:05:26] *** FinboySlick <FinboySlick!~shark@74.117.40.10> has quit IRC (Quit: Leaving.)
[22:14:37] *** jas02 <jas02!~jas02@193.165.24.163> has quit IRC (Remote host closed the connection)
[22:16:35] *** gu1lle_ <gu1lle_!~Thunderbi@181.167.195.114> has quit IRC (Remote host closed the connection)
[22:23:46] *** syshero <syshero!~chm@80.111.127.7> has joined #postfix
[22:23:54] *** syshero <syshero!~chm@80.111.127.7> has quit IRC (Client Quit)
[22:37:57] <tharkun_> quit
[22:38:00] *** tharkun_ <tharkun_!~1@unaffiliated/tharkun> has quit IRC (Quit: leaving)
[22:39:18] <rob0> tharkun, you can't /quit, you're /fired!
[22:47:20] *** Diemuzi <Diemuzi!~IceChat9@unaffiliated/diemuzi> has quit IRC (Quit: See you on the flip side)
[23:41:42] *** dvl <dvl!~dvl@freebsd/developer/dvl> has quit IRC (Max SendQ exceeded)
[23:41:48] *** Gaaab <Gaaab!~Gaaab@host200-73-dynamic.182-80-r.retail.telecomitalia.it> has joined #postfix
[23:43:23] *** dvl <dvl!~dvl@znc.unixathome.org> has joined #postfix
[23:43:24] *** dvl <dvl!~dvl@znc.unixathome.org> has quit IRC (Changing host)
[23:43:24] *** dvl <dvl!~dvl@freebsd/developer/dvl> has joined #postfix
[23:48:53] *** dvl <dvl!~dvl@freebsd/developer/dvl> has quit IRC (Max SendQ exceeded)
[23:50:26] *** dvl <dvl!~dvl@2610:1c1:0:4::7> has joined #postfix
[23:50:26] *** dvl <dvl!~dvl@2610:1c1:0:4::7> has quit IRC (Changing host)
[23:50:26] *** dvl <dvl!~dvl@freebsd/developer/dvl> has joined #postfix
[23:54:23] *** gaab <gaab!~Gaaab@host200-73-dynamic.182-80-r.retail.telecomitalia.it> has joined #postfix
top

   November 1, 2017  
< | 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 | >