January 7, 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 | 31 | >
January 7, 2017 [00:13:18] *** thowe <thowe!~tim@2607:fda0:41::6c> has joined #postfix[00:14:32] *** infides_afk <infides_afk!~infides@p5B167DE5.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds)[00:15:34] <thowe> I would like to configure different sender restrictions for ipv4 and ipv6. I have attempted this by setting the ipv6 options I want in master.cf on a separate smtpd process configured for the ipv6 address, but there's a few reasons why I don't think that would work... Do I have to run a completely seperate postfix set if I want to do this?[00:16:16] *** KaiForce <KaiForce!~chatzilla@107-223-70-10.lightspeed.bcvloh.sbcglobal.net> has joined #postfix[00:22:43] <pj> thowe: it should work, show your config[00:22:47] <pj> !tell thowe showconfig[00:22:47] <knoba> thowe: "showconfig" : when asked to provide your config, please provide a SINGLE 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[00:24:01] <thowe> Well, when I telnet to port 25 of the ipv6 address, instead of telling me "220 hostname ESMTP Postfix", it just closes within a second with "Connection closed by foreign host."[00:24:20] <pj> show your config[00:25:27] *** fling <fling!~fling@fsf/member/fling> has joined #postfix[00:28:28] <thowe> https://gist.github.com/thowe/8b5261718e091fc7a85b9f39bca93f64[00:30:46] <thowe> I started by just trying to set different smtpd_sender_restrictions[00:30:59] <thowe> stricter REV PTR checking slightly[00:31:05] <pj> thowe: I'm going to try connecting to you to see if I get the same results.[00:32:13] <thowe> I'll probably also have to replace smtpd_recipient_restrictions to take out the RBLs that don't seem to help much with ipv6[00:32:24] <pj> thowe: I'm getting connection refused. This is generally a firewall issue, and could possibly be blocked by your host as well...[00:32:37] <pj> do keep in mind that IPv6 firewall rules are not the same as IPv4 ones.[00:32:47] <thowe> Yeah I may need to alter the firewall... I was testing on local machine... just a sec...[00:34:19] <pj> ok[00:37:28] <thowe> hrm, I actually think I may have found the issue, but I also updated firewalll.[00:38:21] <pj> yeah, it's working for me now[00:38:32] <pj> you should see my connection in your logs.[00:38:53] <thowe> indeed I do[00:39:16] <thowe> it started working when I stopped trying to change the banner. I must have had some syntax wrong.[00:39:56] <pj> ok, I suggest setting a different syslog_name in your master.cf for each entry, then you can tell which one someone connects to when you check your logs.[00:40:20] <thowe> Yeah, that's what I have in my production system, but thanks for the reminder...[00:40:25] <pj> yw[00:41:30] <thowe> Trying to get a newer config with some ipv6 stuff I can test for some actual custoemr stuff... My other ipv6 box already is very strict, but I don't answer to customers on that one ;P[00:41:58] <thowe> i also plan to switch to lmtp for my dovecot delivery...[00:42:18] <pj> ...and you should check out postscreen as well, I generalyl recommend it nowadays.[00:42:26] <pj> !tell thowe postscreen[00:42:26] <knoba> thowe: "postscreen" : SMTP triage server available in Postfix 2.8, see http://www.postfix.org/POSTSCREEN_README.html and http://www.postfix.org/postscreen.8.html[00:42:35] <thowe> Yeah, I have meant to do that for a while now...[00:42:51] <thowe> I just haven't looked through the config docs.[00:43:04] <pj> yeah, you need to read through them, and this will help as well...[00:43:06] <pj> !cheatsheet[00:43:06] <knoba> pj: "cheatsheet" : (#1) http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt : A HOWTO for pre-DATA spam control., or (#2) A postscreen cheatsheet can be seen at http://rob0.nodns4.us/postscreen.html (updated 2016-01-16, now requires Postfix 2.11+)[00:43:16] <thowe> I figure with google doing ipv6 mail, and being strict about it, I should be able to get away with being just as strict.[00:44:36] <pj> maybe, google tends to reject a lot of legitimate mail and spam bins a fair bit more.[00:45:43] <thowe> I have seen complaints about them, but it seems everything is fine for me as long as DNS is set up as it should be anyway... Some folks seem to say they are ending up on lists, though.[00:47:00] *** davidw <davidw!~davidw@apache/committer/davidw> has quit IRC (Ping timeout: 248 seconds)[00:47:53] <thowe> I also think I need to get SRS set up...[00:52:31] <pj> you only need SRS if you're planning to do forwarding, but that's not recommended anyways, for various reasons.[00:53:38] <lunaphyte> if you're entertaining srs, then it means you have made a bad choice earlier ;)[00:53:47] <thowe> I have some people that insist on forwarding everything to their gmail accounts or what have you.[00:53:55] <lunaphyte> yeah, that's not ok to do[00:53:55] <pj> it's a bad idea[00:54:23] <lunaphyte> it never has been [despite how "common" it may have been], and it's even less doable now[00:54:37] <thowe> No kidding... I've been talking about some much stricter email policies and if people don't like them they can host email someplace else. gmail will even pick the mail up for them if they like.[00:54:56] <pj> if they want to see their mail in gmail then they can set up gmail to fetch it via POP3 from dovecot.[00:54:59] <lunaphyte> right. fetching mail is the proper way to do that[00:55:29] <thowe> Yeah, that's what I want them to do. I also think I want to ban the auto-respnder[00:55:37] <lunaphyte> setting aside the obvious actual answer of gmail hosting it in the first place, if they are infatuated with using google...[00:56:05] <thowe> It's just a few employees at that one customer.[00:57:00] <pj> How lazy can you be anyways if you can't be assed configuring your MUA to access one more account, or to view it via webmail if that'[00:57:03] <thowe> Also, historically we have forwarded people's mail for different reasons, but I really think the new policy needs to be no bouncing and no forwarding.[00:57:07] <pj> if that's your preference[00:57:45] <pj> anyways, really the only exception I make to the no forwarding rule is for mailing lists, and even that's not a great idea, it just tends to be a necessary evil.[00:58:12] <thowe> Your comments have strengthened my resolve on this.[00:58:41] <thowe> Oh, man, I still have some folks who use me for their marketing blasts... It's even against my AUP...[00:59:35] <pj> grand[01:00:12] <pj> you should just throttle everyone, I mean a limit of 100 messages per day is perfectly reasonable for the vast majority of people doing normal email.[01:00:43] <pj> for someone trying to send out a marketing blast they will quickly reach it and their email will stop working.[01:01:40] *** tharkun_ <tharkun_!~0@fixed-190-62-187-190-62-81.iusacell.net> has quit IRC (Changing host)[01:01:40] *** tharkun_ <tharkun_!~0@unaffiliated/tharkun> has joined #postfix[01:01:48] <tharkun_> !dkim[01:01:48] <knoba> tharkun_: "dkim" : DomainKeys Identified Mail (DKIM) is a method for email authentication that allows an organization to take responsibility for a message in a way that can be validated by a recipient. this is typically implemented in postfix by means of a milter such as !opendkim. alternatively, existing content filters (e.g. !amavisd-new) may also have their own implementation mechanism.[01:02:00] <thowe> Our other system does that, I haven't put a policy server here yet.[01:02:07] <tharkun_> !opendkim[01:02:07] <knoba> tharkun_: "opendkim" : A commonly used milter for dkim signing your messages based on Sendmail's dkim-milter. See http://www.opendkim.org/[01:02:45] <thowe> My biggest confusion is how I am going to go about limiting forwards to just being to the same domain. My interfaces don't support that today... I'll probably have to write something custom[01:03:57] <thowe> fully have my domains seem to have a bunch of aliases for "info" or "marketing" and so forth, and I want to allow those but not allow them to be to different domains...[01:04:48] <rob0> For the purpose of the limit, I would define "message" as one RCPT TO, rather than as Postfix would define it, as one DATA.[01:34:51] *** Dat <Dat!dat@gotpot.org> has joined #postfix[01:35:07] *** Dat <Dat!dat@gotpot.org> has quit IRC (Changing host)[01:35:07] *** Dat <Dat!dat@unaffiliated/dat> has joined #postfix[01:36:16] *** muse <muse!~muse@unaffiliated/grok> has joined #postfix[01:37:07] *** muse <muse!~muse@unaffiliated/grok> has quit IRC (Client Quit)[01:40:57] *** thowe <thowe!~tim@2607:fda0:41::6c> has quit IRC (Quit: Leaving)[01:42:25] *** davidw <davidw!~davidw@apache/committer/davidw> has joined #postfix[01:59:24] *** namyzarc <namyzarc!~namyzarc@2601:989:4202:cde1:3552:33f1:613a:441d> has joined #postfix[01:59:30] *** namyzarc <namyzarc!~namyzarc@2601:989:4202:cde1:3552:33f1:613a:441d> has quit IRC (Remote host closed the connection)[02:00:14] *** namyzarc <namyzarc!~namyzarc@2601:989:4202:cde1:3552:33f1:613a:441d> has joined #postfix[02:03:51] *** howitdo <howitdo!~howitdo@unaffiliated/howitdo> has joined #postfix[02:07:14] *** NwS <NwS!~NwS@unaffiliated/nws> has quit IRC (Ping timeout: 256 seconds)[02:30:33] *** leprechau <leprechau!gqvgqsls3g@c-67-187-127-110.hsd1.tn.comcast.net> has quit IRC (Excess Flood)[02:31:11] *** leprechau <leprechau!lfwksb93y1@c-67-187-127-110.hsd1.tn.comcast.net> has joined #postfix[02:36:52] *** davidw <davidw!~davidw@apache/committer/davidw> has quit IRC (Ping timeout: 240 seconds)[02:55:26] *** gu1lle_ <gu1lle_!~Thunderbi@190.18.4.241> has joined #postfix[03:07:18] *** CyberDems <CyberDems!~dems@srv.webintuitive.co.za> has joined #postfix[03:36:55] *** J0hnSteel <J0hnSteel!~J0hnSteel@92.55.116.125> has quit IRC (Ping timeout: 265 seconds)[03:43:11] *** Diemuzi <Diemuzi!~IceChat9@unaffiliated/diemuzi> has quit IRC (Quit: See you on the flip side)[04:06:26] *** chachasmooth <chachasmooth!~chachasmo@unaffiliated/chachasmooth> has quit IRC (Ping timeout: 245 seconds)[04:11:41] *** chachasmooth <chachasmooth!~chachasmo@unaffiliated/chachasmooth> has joined #postfix[04:34:09] *** chachasmooth <chachasmooth!~chachasmo@unaffiliated/chachasmooth> has quit IRC (Ping timeout: 248 seconds)[04:37:11] *** chachasmooth <chachasmooth!~chachasmo@unaffiliated/chachasmooth> has joined #postfix[04:44:40] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has quit IRC (Quit: inabit. zz.)[04:46:36] *** d0nn1e <d0nn1e!~d0nn1e@cpe-104-138-218-156.triad.res.rr.com> has quit IRC (Ping timeout: 258 seconds)[04:49:16] *** d0nn1e <d0nn1e!~d0nn1e@cpe-104-138-218-156.triad.res.rr.com> has joined #postfix[05:04:16] *** stray131 <stray131!~stray@pool-71-175-174-110.phlapa.east.verizon.net> has joined #postfix[05:04:29] <stray131> hello all[05:11:36] <jimpop> does postfix enforce (i.e. modify the body) emails which have lines longer than 998 chars?[05:13:31] <jimpop> msg988char -> MLM -> 587 -> milter_OpenDKIM -> 25[05:14:14] <jimpop> i suspect a problem where OpenDKIM is signing a msg, and then postfix modfies the body on the way out[05:14:36] <jimpop> and then recievers say: "dkim=neutral (body hash did not verify)"[05:15:00] <jimpop> *receivers[05:20:45] <pj> jimpop: I don't think so, but I might be wrong.[05:22:00] *** Motoko <Motoko!~maoyama@simplemachines/serverteam/Motoko> has joined #postfix[05:22:00] <jimpop> some googling found me this: smtp_line_length_limit (default is 998)[05:22:40] <jimpop> so i think it does.. now to track down what mailman offers for trimming lines[05:24:03] <pj> ahhh, you are correct, I didn't know about that.[05:24:12] <jimpop> me either :-)[05:24:30] <jimpop> and there is a darth of info on mailman and 998[05:24:39] <jimpop> so i'm guessing mailman doesn't[05:24:51] <pj> it's an SMTP protocol limit, so if it's getting lines longer than that then the MUA is breaking the protocol.[05:25:18] <pj> postfix does it so that it doesn't break the protocol in turn when passing the message on.[05:25:25] <jimpop> yep[05:25:49] <jimpop> i'm putting my $$ on the MUA being Exchange... 2secs, let me check[05:25:50] <pj> what version of postfix do you have?[05:26:33] <pj> I don't think exchange is an MUA, unless there's something about it I don't know.[05:26:52] <jimpop> yep, msg originated from msxedgnsprd02.gw.upmc.edu[05:27:14] <pj> what version of postfix do you have?[05:27:40] <jimpop> 12.2[05:27:42] <jimpop> doh[05:27:44] <jimpop> 11.2[05:27:57] <jimpop> wat[05:28:01] <pj> ok, yeah, then it will be 998 by default[05:28:06] <jimpop> 2.11.2[05:28:20] <pj> yeah, that's what I figured you meant, heh[05:28:23] <jimpop> :-)[05:29:31] <jimpop> so my MTA (postfix) accepts >998 and hands them off to Mailman, they get reflected back to 587, then DKIM signed, and then postfix trims the lines to 998[05:30:02] <pj> well, it wouldn't do that[05:30:12] <pj> hrmmmm, or maybe it would[05:30:17] <pj> how does it hand them off to mm?[05:31:18] <jimpop> virtual aliases[05:31:51] <pj> that doesn't answer the question, does it use pipe?[05:31:55] *** axisys <axisys!~axisys@ip68-98-177-162.dc.dc.cox.net> has quit IRC (Quit: leaving)[05:32:17] *** axisys <axisys!~axisys@unaffiliated/axisys> has joined #postfix[05:33:07] <jimpop> no, it uses virtual aliases[05:33:08] <jimpop> :-)[05:33:16] <jimpop> !virtual[05:33:16] <knoba> jimpop: "virtual" : a way to configure additional domains and mailboxes that do not require individual system accounts. See: http://www.postfix.org/VIRTUAL_README.html[05:33:46] <pj> that's not the delivery mechanism.[05:34:12] <jimpop> Here's a good overview of postfix+mailman integration http://www.list.org/mailman-install/postfix-integration.html[05:34:22] <pj> what is the log entry in your mail logs that show the delivery to mm?[05:34:31] <jimpop> the return from mailman back to postfix is 587 (submission)[05:37:26] <jimpop> here's the email with the line broken at 998 http://paste.debian.net/plainh/c2fbc84c[05:39:18] <jimpop> what i need is smtpD_line_length_limit such that postfix fixes incoming emails that have lines that exceed 998[05:42:17] <pj> !tell jimpop relevant_logs[05:42:17] <knoba> jimpop: "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 (mail); filter such messages out unless asked not to.[05:42:22] <pj> just show this jimpop ^^^^^[05:44:52] <pj> ...and, I suspect what you'll need to do is have postfix deliver the mail to itself via smtp and then send it to opendkim. Show your config and I can tell you how to do that...[05:44:57] <pj> !tell jimpop showconfig[05:44:57] <knoba> jimpop: "showconfig" : when asked to provide your config, please provide a SINGLE 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[05:45:34] <pj> an ugly workaround but it would fix the issue as it would run the message through smtp before signing instead of after that way.[05:46:08] <jimpop> thanks, but no thanks. :-) Postfix is doing the right thing, the problem is Exchange is sending (to postfix) lines longer than 998[05:46:53] <pj> oh, try setting line_length_limit to 998[05:47:22] <pj> that will chop the lines up from smtpd, before they hit the content filter (I think)[05:47:58] <pj> errr before they hit opendkim, I mean[05:48:36] <pj> jimpop: and yes and no. Postfix *is* doing the right thing, but if you can get it to do that right thing before opendkim instead of after then it will solve your issue.[05:49:06] <jimpop> that's interesting... why would it chop them up into 2048 chars, only to later (smtp) chop them up into 998?[05:50:16] <pj> jimpop: I suspect that 2048 is the limit to help postfix with its internal buffers, etc, 998 is done on the way out because it's the limit imposed by the smtp protocol. If postfix were to deliver the message then it presumably doesn't need to worry about smtp protocol limits.[05:50:48] <pj> ...except that you do need to worry about it because of your unique environment.[05:51:42] <pj> so yeah, set line_length_limit and it will likely fix the issue for you.[05:51:43] <jimpop> yeah, that seems to be the case. line_length_limit = 998[05:51:52] <jimpop> thx pj[05:51:55] <pj> yw[05:52:36] <pj> now realize that inbound messages with lines longer than 998 that are signed will have their signatures broken when you check them (if you check them).[05:53:01] <pj> if that's the case then you may need to do some more tweaking to get everything to work just right.[05:53:39] <jimpop> good point. I shall look into that angle too[05:54:05] <pj> do you check signatures? maybe just with SA?[05:54:50] <pj> at least with SA it will just affect the SPAM score, and that's not necessarily a bad thing since the message breaks protocols anyways it probably should get hit on the SPAM score a bit for it.[05:54:58] <jimpop> i sv them with opendkim[05:55:19] <pj> I see, I generally just use opendkim for outbound signing, not for inbound checking.[05:56:28] <pj> well, the messages come from mm on port 587, so you can put the line_length_limit setting in master.cf on the submission service in order to not have it affect inbound messages before they are checked.[05:56:53] <jimpop> yeah, that's what i was just looking into doing[05:57:10] <jimpop> great minds![05:57:13] <pj> :-)[06:04:28] <jimpop> the thing about master.cf is that it is hard to comment a one line addition (-o ...)[06:04:46] <pj> ummmmm, you just comment it.[06:04:46] <jimpop> i will forget why i added[06:05:01] <jimpop> i will forget why i added line_length_limit, and years from now be here asking what it's for[06:05:03] <pj> oh, I see[06:05:04] <jimpop> :-)[06:05:36] <pj> I think you can put the comment right above it so long as it doesn't have whitespace before the #, but I would put it above the service itself.[06:06:21] <jimpop> i would be nice to do this: -o line_length_limit=998 # because pj said to[06:06:35] <lunaphyte> that would be nice[06:06:47] <lunaphyte> i wonder how you postfix could detect the end of the comment[06:06:53] <lunaphyte> a newline maybe?[06:07:30] <jimpop> i would think that would work[06:07:32] <pj> yeah, but there are cases where you might have to have a # in the middle of the line for other reasons.[06:07:34] <lunaphyte> maybe even if a newline within a logical line began with #, it could still be detected as a comment[06:08:03] <lunaphyte> quoting might be able to address the ned for a "literal" #[06:08:06] <lunaphyte> *need[06:08:37] <pj> foo .... pipe argv=bar ... filenamewith#init ...[06:08:50] <lunaphyte> yeah[06:09:03] <lunaphyte> those edge cases are frustrating sometimes :)[06:09:26] <pj> at any rate, it's not something that would warrant a change, imo, it's not that much of a needed feature.[06:09:34] <lunaphyte> the "real" answer is the no one in their right mind should be naming files for that sort of use with a stupid # in it :p[06:09:43] <lunaphyte> yet it would be remiss to not account for it[06:09:45] <jimpop> :-)[06:09:49] * pj looks at his IRC log files[06:09:55] <pj> most have #'s in the names, heh[06:10:27] <pj> but yeah, I know what you mean, but the thing is it would break BC to change that now.[06:10:55] <lunaphyte> yeah - but, now we have comptaibility_level![06:11:06] <lunaphyte> *compatibility_level[06:12:18] <pj> true enough, but then it involves writing a parser that checks the file for the mid-line #'s and spits out a warning if the level is below X so someone can fix it before updating the level and I just don't know if it's worth all that work for this particular feature.[06:12:29] <pj> it doesn't actually add any functionality to postfix.[06:12:36] <lunaphyte> imho, it's definitely not[06:12:41] <lunaphyte> screw jimpop![06:12:45] <pj> hahaha[06:15:13] <jimpop> wait, what?[06:15:28] <jimpop> :-)[06:32:53] *** robinho86 <robinho86!~robsonjf@201.22.86.124.static.gvt.net.br> has quit IRC (Read error: Connection reset by peer)[06:44:31] <tuxick> he meant jimbob[06:53:42] *** gu1lle_ <gu1lle_!~Thunderbi@190.18.4.241> has quit IRC (Remote host closed the connection)[06:54:00] *** gu1lle_ <gu1lle_!~Thunderbi@190.18.4.241> has joined #postfix[07:02:27] *** J0hnSteel <J0hnSteel!~J0hnSteel@92.55.116.125> has joined #postfix[07:52:25] *** Ekho- <Ekho-!~Ekho@unaffiliated/ekho> has joined #postfix[07:52:48] *** Ekho <Ekho!~Ekho@unaffiliated/ekho> has quit IRC (Ping timeout: 246 seconds)[07:59:43] *** joulez is now known as joules[08:33:24] *** infides_afk <infides_afk!~infides@p5B167C36.dip0.t-ipconnect.de> has joined #postfix[08:48:34] *** Motoko <Motoko!~maoyama@simplemachines/serverteam/Motoko> has quit IRC (Quit: Bye)[08:50:58] *** stray131 <stray131!~stray@pool-71-175-174-110.phlapa.east.verizon.net> has quit IRC (Ping timeout: 255 seconds)[08:52:26] <monkeynuts> hi, I just want to check that my mail server is behaving correctly, it manages mail for about 20 domains. I have their MX records set to mail.domain.tld >> Servers IP record and this works fine with no encryption and with STARTTLS. I have a signed SSL set up on the server for the servers hostname say, mail.server.tld.[08:52:27] <monkeynuts> If I try to use an SSL/TLS connection to this using the settings mail.domain.tld the connection fails, but works fine if I use mail.server.tld. Is the SSL/TLS conenction more restrictive on what domain name is used to connect to the server from the mail client?[08:54:49] <honestly> monkeynuts sounds like postfix verified the hostname against the cert which fails[08:56:33] <monkeynuts> honestly, Yes thats what I believe happened, can this be changed or is it something that should happen?[08:56:33] <nate> I believe postfix is capable of SNI if the client sends a host header? Probably what the case is[08:57:21] <honestly> http://www.postfix.org/TLS_README.html#client_tls_levels[08:59:13] <monkeynuts> excellent honestly, thanks..I'll check the conf files[08:59:50] <honestly> I'd say this is something that should happen[09:00:11] <honestly> please get a certificate that is valid for all hostnames you want to receive mail on[09:06:47] <monkeynuts> yeah...but thats would be unreasonable for me as I would have to renew the cert everytime I add a domain. I think I should be able to set it so that it will flag that the cert is not for mail.domain.tld but the user can use this cert to connect using SSL/TLS[09:07:18] <monkeynuts> similar to STARTTLS[09:07:52] <honestly> there are two ways to solve this[09:08:02] <honestly> 1) use a single hostname[09:08:30] <honestly> 2) use SNI[09:09:17] <honestly> and actually there's a third way, get a better certificate workflow so renewing the cert every time you add a domain is not a pain[09:09:27] <honestly> (use letsencrypt, for example)[09:10:04] *** mcfate <mcfate!~textual@174-134-145-16.res.bhn.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)[09:10:14] <monkeynuts> 4) Set the MX records of the domain to the hostname of the mail server, then just get the clients to use that as their mail server setting in their clients[09:10:45] <honestly> that's what I meant for 1, yes[09:11:38] <monkeynuts> yes. Might be the simplest solution which is usually the best....I'll look into my settings anyway to see if I can figure out why its so restrictive, not that its a bad thing really[09:17:38] <monkeynuts> just seems to be the outgoing thats so restrictive, recieves mail ok on mail.domain.com using TLS/SSL imap on 993. So just need to look into the smtp settings[09:31:05] <nate> monkeynuts: Could just use let's encrypt to generate one each time[09:31:21] <nate> STARTTLS has nothing to do with this other than it's kind of a silly way of doing TLS[09:33:36] *** markus_e92 <markus_e92!~markus_e9@62-46-31-170.adsl.highway.telekom.at> has quit IRC (Quit: ZNC - http://znc.in)[09:34:03] <monkeynuts> but it just seems to be the smtps port that has an issue with the cert being for a different domain, could also be thunderbird and how it handles this[09:34:48] <monkeynuts> master.cf : smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes[09:35:09] <monkeynuts> I'll do some more reading[09:35:52] <nate> Both should effectively do the same SNI support (straight TLS or STARTTLS), the only real difference between the two is the latter is somewhat MitM vulnerable[09:36:02] *** markus_e92 <markus_e92!~markus_e9@62-46-31-170.adsl.highway.telekom.at> has joined #postfix[09:39:54] <monkeynuts> I agree which is why I would like to get TLS/SSL to work, I can add the incoming ok if I use a different outgoing server, but if I try to add incoming and outgoing to thunderbird it throws a wobbly.[09:40:32] <monkeynuts> I should be able to add the account and accept the cert once I try to send and receive a mail..?[09:44:00] <honestly> yes, you should[09:44:09] <honestly> thunderbird should give you a certificate warning[09:45:56] <monkeynuts> and TLS/SSL smtp is by default on 465?[09:46:16] <monkeynuts> or is the norm[09:47:24] *** rsx <rsx!~dummy@ppp-93-104-53-61.dynamic.mnet-online.de> has joined #postfix[09:59:36] *** golden_receiver <golden_receiver!~andry@unaffiliated/golden-receiver/x-4949035> has quit IRC (Read error: Connection reset by peer)[10:04:11] <monkeynuts> ok its something to do with Thunderbird, just set it up on Outlook and no probs, just accept the cert and it adds the account and sends mail with no issue. May be my AV or a plugin thats causing the issue with the SSLs on Thunderbird for me. Doesnt seem to be a postfix issue. Thanks for you help folks[10:10:12] <pj> nate: SMTPS is deprecated and should not be used. STARTTLS when properly set up and used is not vulnerable and postfix does not support SNI in either.[10:10:49] <pj> monkeynuts: you want to configure thunderbird for port 587 and STARTTLS encryption.[10:15:21] <honestly> "when properly set up and used is not vulernable" <- that's not a useful statement about a cryptosystem[10:15:56] <monkeynuts> pj, 587 works fine for submission and STARTTLS, issue seems to lie with my thunderbird and SMTPS[10:15:56] <nate> pj: "When properly set up"? Exactly how does a "properly set up postfix" prevent STARTTLS stripping? Unless you're talking about simply disabling any form of plaintext support at all (which means if STARTTLS is stripped the connection will simply fail)[10:15:59] <honestly> it's equivalent to "insecure by default"[10:16:22] <pj> honestly: no crypto will be secure if it's not properly set up and used.[10:17:45] <pj> !smtpd_tls_auth_only[10:17:46] <knoba> pj: "smtpd_tls_auth_only" : When TLS encryption is optional in the Postfix SMTP server, do not announce or accept SASL authentication over unencrypted connections.[10:17:52] <pj> !smtpd_tls_security_level[10:17:52] <knoba> pj: "smtpd_tls_security_level" : the smtp tls security level for the postfix smtp server; when a non-empty value is specified, this overrides the obsolete parameters smtpd_use_tls and smtpd_enforce_tls. this parameter is ignored with smtpd_tls_wrappermode = yes . this feature is available in postfix 2.3 and later[10:17:53] <honestly> pj, please take a look at what browsers have been doing with HTTPS to make it secure by default as opposed to "secure when properly setup and used"[10:17:56] <pj> nate: ^^^^^^^^^[10:20:22] <nate> pj: So basically forbid non-encrypted stuff, technically works yes but doesn't inherently fix the vulnerability, just means the authentication won't go at all :P[10:21:07] <pj> nate: it means that nothing will happen without encryption.[10:21:10] <pj> not just authentication.[10:21:46] <pj> honestly: smtp != http.[10:21:47] <honestly> unencrypted port 25, encrypted-only port 587 is the common setup[10:22:17] <pj> no, 25 should be opportunistic encryption.[10:22:39] <honestly> yes.[10:22:43] <pj> unfortunately you can't really require that it be encrypted as you will end up not being able to communicate with a large number of email servers if you do.[10:23:00] *** NwS <NwS!~NwS@unaffiliated/nws> has joined #postfix[10:23:06] <pj> I do hope that there will come a day when it is reasonable to require encryption on 25 as well.[10:23:31] <monkeynuts> tbh all conenctions should be encrytped and be done with it[10:24:03] <pj> monkeynuts: that's easy to say, in the real world, however, we have to deal with a large number of old servers that just don't work that way.[10:24:48] <honestly> and they'll never have an incentive to fix that if we don't give them one[10:24:55] <monkeynuts> pj Oh I know...but has to start somewhere[10:25:36] <pj> honestly: the way it will work is old servers are retired and as new ones are set up they will work with encryption.[10:26:07] <pj> it takes time, but it will happen. Google is kind of helping by making a push for TLS connections.[10:26:35] <pj> but also consider that encrypted connections on port 25 are overrated.[10:26:43] <pj> they give a false sense of security.[10:27:05] <pj> and the actual level of security they provide is quite limited.[10:27:43] <honestly> they give a false sense of security to people who don't understand what their thread model is, which means they probably also don't understand what "false sense of security" means[10:27:51] <honestly> can't do much about that other than try to educate[10:28:01] <honestly> threat model*[10:28:36] <pj> they are not very secure to begin with. For starters your message could end up going through any number of connections downstream that are not encrypted.[10:28:58] <pj> the message is passed through and queued on each server unencrypted.[10:29:22] <pj> and anyone with access to any intermediate server can read your mail anyways.[10:30:50] <pj> all that an encrypted connection secures is that single channel of communication. It does not secure the message, it does not secure any other channel that the message passes through.[10:38:22] <monkeynuts> nothing is secure...all you can do is make it hard to compromise[10:40:44] <pj> my point is more related to what google has been doing, trying to indicate to people if their mail is secure or not based on the encrypted channel. It's a false indicator.[10:54:58] *** golden_receiver <golden_receiver!~andry@unaffiliated/golden-receiver/x-4949035> has joined #postfix[10:56:50] *** markus123123 <markus123123!~markus_e9@62-46-101-29.adsl.highway.telekom.at> has joined #postfix[10:58:25] *** markus_e92 <markus_e92!~markus_e9@62-46-31-170.adsl.highway.telekom.at> has quit IRC (Ping timeout: 258 seconds)[11:00:57] *** ced117_ <ced117_!~ced117@AStrasbourg-552-1-26-76.w90-13.abo.wanadoo.fr> has joined #postfix[11:01:20] *** ced117_ <ced117_!~ced117@AStrasbourg-552-1-26-76.w90-13.abo.wanadoo.fr> has quit IRC (Remote host closed the connection)[11:04:37] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has joined #postfix[11:20:18] *** shoonya <shoonya!~unknown@122.179.25.160> has joined #postfix[11:25:21] *** Darcidride <Darcidride!~Darcidrid@qbuissondebon.info> has joined #postfix[11:30:47] *** Deathrattle <Deathrattle!~death@p200300868A6B4C010000000000000001.dip0.t-ipconnect.de> has joined #postfix[11:39:51] *** markus123123 <markus123123!~markus_e9@62-46-101-29.adsl.highway.telekom.at> has quit IRC (Quit: ZNC - http://znc.in)[11:40:24] *** markus_e92 <markus_e92!~markus_e9@62-46-101-29.adsl.highway.telekom.at> has joined #postfix[11:51:27] *** Darcidride <Darcidride!~Darcidrid@qbuissondebon.info> has quit IRC (Ping timeout: 256 seconds)[12:07:42] *** Darcidride <Darcidride!~Darcidrid@ALyon-656-1-691-122.w90-14.abo.wanadoo.fr> has joined #postfix[12:49:51] *** Darcidride <Darcidride!~Darcidrid@ALyon-656-1-691-122.w90-14.abo.wanadoo.fr> has quit IRC (Ping timeout: 272 seconds)[13:09:19] *** Deathrattle <Deathrattle!~death@p200300868A6B4C010000000000000001.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)[13:16:02] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has quit IRC (Quit: inabit. zz.)[13:24:43] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has joined #postfix[13:33:33] *** pti-jean_ <pti-jean_!~quassel@7.41.124.78.rev.sfr.net> has joined #postfix[13:39:02] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has quit IRC (Quit: inabit. zz.)[14:30:46] *** mcfate <mcfate!~textual@174-134-145-16.res.bhn.net> has joined #postfix[14:56:39] *** infides_afk <infides_afk!~infides@p5B167C36.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 246 seconds)[15:05:48] *** aegis <aegis!~aegis@unaffiliated/aegis> has left #postfix ("Leaving")[15:06:12] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has joined #postfix[15:11:56] *** Diemuzi <Diemuzi!~IceChat9@unaffiliated/diemuzi> has joined #postfix[15:12:39] *** muh2000 <muh2000!~muh2000@unaffiliated/muh2000> has quit IRC (Quit: Konversation terminated!)[15:34:06] *** benone <benone!~benone@web.tiangola.co.ao> has quit IRC (Ping timeout: 246 seconds)[15:34:13] *** kjsaihs <kjsaihs!~kjsaihs@78.90.75.111> has joined #postfix[15:40:10] *** froz-gab <froz-gab!~froz-gab@host163-28-dynamic.56-79-r.retail.telecomitalia.it> has joined #postfix[15:53:57] *** NwS <NwS!~NwS@unaffiliated/nws> has quit IRC (Ping timeout: 258 seconds)[16:04:52] *** KaiForce <KaiForce!~chatzilla@107-223-70-10.lightspeed.bcvloh.sbcglobal.net> has quit IRC (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507])[16:09:06] *** Oclairi <Oclairi!~Oclair@88-117-77-209.adsl.highway.telekom.at> has joined #postfix[16:10:41] *** Oclair <Oclair!~Oclair@178-191-69-63.adsl.highway.telekom.at> has quit IRC (Ping timeout: 248 seconds)[16:30:19] *** stray131 <stray131!~stray@pool-71-175-174-110.phlapa.east.verizon.net> has joined #postfix[16:30:25] *** d0nn1e <d0nn1e!~d0nn1e@cpe-104-138-218-156.triad.res.rr.com> has quit IRC (Ping timeout: 248 seconds)[16:30:43] *** stray131 <stray131!~stray@pool-71-175-174-110.phlapa.east.verizon.net> has quit IRC (Client Quit)[16:57:11] *** pijiu <pijiu!~pijiu@unaffiliated/pijiu> has joined #postfix[16:57:23] *** pijiu <pijiu!~pijiu@unaffiliated/pijiu> has quit IRC (Max SendQ exceeded)[16:58:50] *** mxyzptlkfishstix <mxyzptlkfishstix!~mxyzptlkf@cpe-2606-A000-1503-C0EF-5CCE-13A3-46E-7640.dyn6.twc.com> has quit IRC (Ping timeout: 240 seconds)[16:59:03] *** mactimes_ is now known as mactimes[17:32:10] *** mxyzptlkfishstix <mxyzptlkfishstix!~mxyzptlkf@cpe-2606-A000-1503-C0EF-3826-ED6-8EB7-9ECF.dyn6.twc.com> has joined #postfix[17:53:52] *** benone <benone!~benone@web.tiangola.co.ao> has joined #postfix[18:06:09] *** shoonya <shoonya!~unknown@122.179.25.160> has quit IRC (Quit: Leaving)[18:07:31] *** systeem <systeem!~systeem@2001:bc8:24e8:800:a:27ba:0:c9f1> has joined #postfix[18:09:03] *** markus_e92 <markus_e92!~markus_e9@62-46-101-29.adsl.highway.telekom.at> has quit IRC (Ping timeout: 272 seconds)[18:10:30] *** markus_e92 <markus_e92!~markus_e9@91-115-157-242.adsl.highway.telekom.at> has joined #postfix[18:37:21] *** JanC_ <JanC_!~janc@lugwv/member/JanC> has joined #postfix[18:38:34] *** JanC is now known as Guest36383[18:38:34] *** Guest36383 <Guest36383!~janc@lugwv/member/JanC> has quit IRC (Killed (livingstone.freenode.net (Nickname regained by services)))[18:38:34] *** JanC_ is now known as JanC[19:16:58] *** mikecmpbll <mikecmpbll!~mikecmpbl@ruby/staff/mikecmpbll> has quit IRC (Quit: inabit. zz.)[19:17:16] *** phunyguy <phunyguy!~torpedo@ubuntu/member/phunyguy> has quit IRC (Ping timeout: 245 seconds)[19:21:01] *** phunyguy <phunyguy!~torpedo@ubuntu/member/phunyguy> has joined #postfix[19:32:45] *** v1c3_ <v1c3_!~v1c3@wdsl-109-239-161-137.wcli.deg.net> has joined #postfix[19:35:33] *** v1c3 <v1c3!~v1c3@wdsl-109-239-161-137.wcli.deg.net> has quit IRC (Ping timeout: 256 seconds)[20:07:35] *** infides_afk <infides_afk!~infides@p5B167C36.dip0.t-ipconnect.de> has joined #postfix[20:11:15] *** froz-gab <froz-gab!~froz-gab@host163-28-dynamic.56-79-r.retail.telecomitalia.it> has quit IRC (Ping timeout: 256 seconds)[20:33:37] *** gongoputch <gongoputch!~kseel@freebsd/op/gongoputch> has joined #postfix[20:40:56] *** chb <chb!~chb@unixboard/mod/chb> has joined #postfix[21:11:36] *** sphenxes02 <sphenxes02!~sphenxes@192-164-137-158.hdsl.highway.telekom.at> has joined #postfix[21:14:48] *** sphenxes <sphenxes!~sphenxes@192-164-137-158.hdsl.highway.telekom.at> has quit IRC (Ping timeout: 255 seconds)[21:15:15] *** sphenxes01 <sphenxes01!~sphenxes@192-164-137-158.hdsl.highway.telekom.at> has quit IRC (Ping timeout: 272 seconds)[21:15:35] *** sphenxes <sphenxes!~sphenxes@192-164-137-158.hdsl.highway.telekom.at> has joined #postfix[21:46:47] *** pti-jean_ <pti-jean_!~quassel@7.41.124.78.rev.sfr.net> has quit IRC (Remote host closed the connection)[21:47:27] *** mactimes is now known as mactimes_[21:55:16] *** chb <chb!~chb@unixboard/mod/chb> has quit IRC (Read error: Connection reset by peer)[22:37:53] *** vktec <vktec!~vktec@unaffiliated/samadivk> has joined #postfix[22:39:03] <vktec> Is it possible to have multiple people able to send email through one address using different passwords? Ideally, both the sender and the actual address would be logged[22:39:29] <lunaphyte> sure[22:40:09] <vktec> Cool. How would one do that? Would it just be using a different sending address with the same login?[22:41:07] <lunaphyte> is it currently not working?[22:41:55] <vktec> I've not set anything up yet, I'm just doing a preliminary check :)[22:44:15] <rob0> this is more a MUA question ("how do I use email?") than a Postfix one.[22:44:48] <rob0> In Thunderbird they are called "identities", IIRC.[22:46:35] <rob0> The only reason it might not work is if you have done something specifically to break it, i.e., reject_authenticated_sender_login_mismatch. No special passwords are needed otherwise.[23:01:07] *** yarre_ <yarre_!sid37501@gateway/web/irccloud.com/x-sjbpywhnwuflhksn> has left #postfix[23:03:27] *** patdk-wk <patdk-wk!~dswett@2001:470:e0ba:15:1a03:73ff:fe2a:d75> has quit IRC (Ping timeout: 258 seconds)[23:05:59] *** rsx <rsx!~dummy@ppp-93-104-53-61.dynamic.mnet-online.de> has quit IRC (Remote host closed the connection)[23:18:29] *** patdk-wk <patdk-wk!~dswett@firewall1.grsi.com> has joined #postfix[23:26:33] *** KaiForce <KaiForce!~chatzilla@107-223-70-10.lightspeed.bcvloh.sbcglobal.net> has joined #postfix[23:27:55] *** infides_afk is now known as Infides