March 17, 2019 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 17, 2019 [00:16:20] *** atmx <atmx!~atmx@185.40.20.96> has quit IRC (Remote host closed the connection)[00:16:48] *** atmx <atmx!~atmx@185.40.20.96> has joined #postfix[00:40:27] *** Nit_ <Nit_!~Nit@2001:bc8:2ad4:100::1> has quit IRC (Ping timeout: 252 seconds)[00:44:26] <pj> I would say that if you even need it all 1 would be enough in the vast majority of cases. Note that using -v in master.cf services only increases the level by 1 and that generally provides craptons more logging.[00:54:29] *** Nit_ <Nit_!nit@saphire.uk.to> has joined #postfix[00:55:54] *** Elisha <Elisha!~elisha@188-230-142-97.dynamic.t-2.net> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[01:03:01] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has joined #postfix[01:03:25] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has quit IRC (Remote host closed the connection)[01:29:05] *** Diemuzi <Diemuzi!~diemuzi@unaffiliated/diemuzi> has quit IRC (Quit: See you on the flip side!)[01:33:28] *** Penguin_ <Penguin_!~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net> has quit IRC (Ping timeout: 258 seconds)[01:35:31] *** Penguin_ <Penguin_!~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net> has joined #postfix[01:55:35] *** shibboleth <shibboleth!~shibbolet@gateway/tor-sasl/shibboleth> has joined #postfix[02:02:02] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[02:10:22] *** ddBz <ddBz!~gary@cpe-67-246-27-81.nycap.res.rr.com> has joined #postfix[02:14:37] *** ddBz <ddBz!~gary@cpe-67-246-27-81.nycap.res.rr.com> has quit IRC (Ping timeout: 245 seconds)[02:20:07] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Ping timeout: 272 seconds)[02:20:10] *** Bebef <Bebef!sbreit@phobos.bebef.de> has quit IRC (Read error: Connection reset by peer)[02:21:19] *** Bebef <Bebef!sbreit@phobos.bebef.de> has joined #postfix[02:42:27] *** DTZUZO <DTZUZO!~DTZUZO@S0106bcd16584b0aa.vs.shawcable.net> has quit IRC (Ping timeout: 246 seconds)[02:47:47] *** ddBz <ddBz!~gary@cpe-67-246-27-81.nycap.res.rr.com> has joined #postfix[02:52:15] *** ddBz <ddBz!~gary@cpe-67-246-27-81.nycap.res.rr.com> has quit IRC (Ping timeout: 246 seconds)[04:19:02] *** shibboleth <shibboleth!~shibbolet@gateway/tor-sasl/shibboleth> has quit IRC (Quit: shibboleth)[04:40:02] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has joined #postfix[04:40:17] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has quit IRC (Remote host closed the connection)[05:22:15] *** rsx <rsx!~rsx@ppp-188-174-145-11.dynamic.mnet-online.de> has joined #postfix[05:33:16] *** phoenixz <phoenixz!~quassel@mx1.capmegamail.com> has quit IRC (Ping timeout: 272 seconds)[05:54:12] *** random_yanek <random_yanek!~random_ya@87.116.237.230> has quit IRC (Quit: random_yanek)[05:56:36] *** random_yanek <random_yanek!~random_ya@87.116.237.230> has joined #postfix[06:44:46] *** Fire-Dragon-DoL <Fire-Dragon-DoL!~Fire-Drag@web556.webfaction.com> has joined #postfix[06:44:52] <Fire-Dragon-DoL> !getting_help[06:44:52] <knoba> Fire-Dragon-DoL: "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[06:45:09] <Fire-Dragon-DoL> !showconfig[06:45:09] <knoba> Fire-Dragon-DoL: "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[06:47:49] <Fire-Dragon-DoL> hello! I'm a complete new to this, have a question: I'm trying to make sure that all the emails (sent from any user) are going to be sent From foo at bar dot com and that any email sent, will always be sent to hello at world dot com. Basically a universe made of 2 email addresses. Is this possible?[06:48:30] <Fire-Dragon-DoL> even if root sends a mail to root, it will become From foo at bar dot com, to hello at world dot com (I know sounds super weird, it's for an IoT device that I want to monitor in my house)[06:49:13] <Fire-Dragon-DoL> I'm playing with aliases but I usually get a loop if I send a mail from root to root[06:57:51] <Fire-Dragon-DoL> and I don't really have any config, the default one that comes with debian right now (I deleted all the changes I made, since I didn't achieve anything really)[07:06:35] <pinPoint> Fire-Dragon-DoL: maybe this can help? Vasilie might have an answer? https://serverfault.com/questions/23717/postfix-how-do-you-redirect-all-emails-to-one-user-eg-example-com-%E2%86%92-userex[07:07:15] <Fire-Dragon-DoL> omg thanks, let me try that. It smells correct. I've been chasing this for the last 4 hours XD[07:10:15] <pinPoint> Might be something here as well: https://serverfault.com/questions/560906/postfix-virtual-aliases-and-catchall-for-undefined-addresses[07:12:12] <pinPoint> and possibly this too: https://tecadmin.net/setup-catch-all-email-account-in-postfix/[07:14:11] <pinPoint> @world.com is your domain foo. So in maps something like | @world.com foo |[07:14:29] <pinPoint> @world.com is your domain*[07:16:57] <pinPoint> and maybe | root: foo | -- man, this is out my depth, i'm still learning. Good luck hunting![07:23:24] <Fire-Dragon-DoL> thanks pinPoint. I think I got the idea. I need to understand what sender_canonical and recipient_canonical do too[07:23:46] <Fire-Dragon-DoL> let's see what can I achieve[07:24:11] <pinPoint> ya.[07:29:05] <Fire-Dragon-DoL> OH[07:29:07] <Fire-Dragon-DoL> I did it[07:29:19] <Fire-Dragon-DoL> WOAH[07:29:22] * Fire-Dragon-DoL is mind blown[07:29:25] <Fire-Dragon-DoL> lol[07:47:23] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has joined #postfix[08:43:22] *** chkbsd <chkbsd!~ucio@bla.mode42.one> has joined #postfix[08:43:22] *** chkbsd <chkbsd!~ucio@bla.mode42.one> has quit IRC (Changing host)[08:43:22] *** chkbsd <chkbsd!~ucio@unaffiliated/ucio> has joined #postfix[09:00:30] *** olegfusion <olegfusion!~olegfusio@mail.mobileforsale.ru> has joined #postfix[09:09:19] *** st1x <st1x!0567890d@gateway/web/freenode/ip.5.103.137.13> has joined #postfix[09:10:30] <st1x> Hi guys. You probably know the alias feature gmail has, where you can receive email on <anything>+<yourrealaddress> at gmail dot com. Has anyone built similar functionality with postfix?[09:34:40] <pj> !tell st1x recipient_delimiter[09:34:40] <knoba> st1x: "recipient_delimiter" : a configuration parameter in the main.cf: The separator between user names and address extensions (user+foo). See canonical(5), local(8), relocated(5) and virtual(5) for the effects this has on aliases, canonical, virtual, relocated and on .forward file lookups. Basically, the software tries user+foo and .forward+foo before trying user and .forward.[09:40:54] <st1x> ah nice :) Thanks for the info[10:03:13] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has quit IRC (Remote host closed the connection)[10:04:25] *** ld50 <ld50!~quassel@2001:41d0:8:baae::bad:deed> has quit IRC (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)[10:07:11] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has joined #postfix[10:13:17] *** st1x <st1x!0567890d@gateway/web/freenode/ip.5.103.137.13> has quit IRC (Ping timeout: 256 seconds)[10:46:28] *** Brilpikk3wyn <Brilpikk3wyn!~Segfault0@unaffiliated/segfault0x40> has joined #postfix[10:55:01] *** ld50 <ld50!~quassel@2001:41d0:8:baae::bad:deed> has joined #postfix[11:01:39] *** DTZUZO <DTZUZO!~DTZUZO@S0106bcd16584b0aa.vs.shawcable.net> has joined #postfix[11:26:11] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has quit IRC (Quit: Leaving)[11:27:11] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has joined #postfix[11:48:58] *** Thom1 <Thom1!~thomas@clancy.halpanet.org> has left #postfix ("WeeChat 2.4")[12:03:36] *** led_dark_1 <led_dark_1!~Thunderbi@217.66.160.14> has joined #postfix[12:26:22] *** Brilpikk3wyn is now known as Pikk3wyn[12:43:17] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[12:55:07] *** ]SiB[1 <]SiB[1!~Thunderbi@unaffiliated/sib/x-9459575> has joined #postfix[12:57:36] *** ]SiB[1 <]SiB[1!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Remote host closed the connection)[12:58:26] *** ]SiB[ <]SiB[!~Thunderbi@unaffiliated/sib/x-9459575> has quit IRC (Ping timeout: 250 seconds)[13:27:42] *** Noti <Noti!~steffan@ip4da40774.direct-adsl.nl> has quit IRC (Quit: Konversation terminated!)[13:34:17] *** olegfusion <olegfusion!~olegfusio@mail.mobileforsale.ru> has quit IRC (Quit: Leaving)[13:51:44] *** Elisha <Elisha!~elisha@188-230-142-97.dynamic.t-2.net> has joined #postfix[13:51:58] *** Elisha <Elisha!~elisha@188-230-142-97.dynamic.t-2.net> has quit IRC (Remote host closed the connection)[13:57:28] *** ddBz <ddBz!~gary@104.156.210.169> has joined #postfix[13:58:51] *** Pikk3wyn <Pikk3wyn!~Segfault0@unaffiliated/segfault0x40> has quit IRC (Remote host closed the connection)[14:07:36] *** JanC <JanC!~janc@lugwv/member/JanC> has quit IRC (Quit: 'k zien d'r mee weh zi)[14:07:50] *** JanC <JanC!~janc@lugwv/member/JanC> has joined #postfix[14:56:46] *** sputnik <sputnik!kli0rf@unaffiliated/kli0rf> has quit IRC (Remote host closed the connection)[15:21:05] *** catern <catern!~catern@catern.com> has joined #postfix[15:24:21] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has quit IRC (Remote host closed the connection)[15:26:32] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has joined #postfix[15:28:13] *** sputnik <sputnik!kli0rf@unaffiliated/kli0rf> has joined #postfix[15:46:03] *** sputnik <sputnik!kli0rf@unaffiliated/kli0rf> has quit IRC (Quit: leaving)[15:51:18] *** sputnik <sputnik!kli0rf@unaffiliated/kli0rf> has joined #postfix[16:07:51] *** sputnik <sputnik!kli0rf@unaffiliated/kli0rf> has quit IRC (Remote host closed the connection)[16:30:36] *** sputnik <sputnik!kli0rf@unaffiliated/kli0rf> has joined #postfix[16:34:24] <catern> hey #postfix, somewhat general question: so for local mail delivery, LMTP exists, and is a theoretical way to do local mail delivery without that component having to run as root (each user would run an LMTP server)[16:34:37] *** magyar <magyar!~magyar@unaffiliated/magyar> has quit IRC (Quit: Riding the split)[16:35:13] <catern> are there any ways one could achieve local mail submission without requiring a set[ug]id-bit executable?[16:36:10] <lunaphyte> what exactly do you mean by "local mail submission"?[16:36:39] <catern> a local user account running "sendmail" or something like that[16:36:51] <lunaphyte> i see[16:37:05] <lunaphyte> i'd be using a null client for that in the first place[16:37:24] <lunaphyte> in which case that changes things a bit[16:39:07] <catern> and force all local mail submission (don't know what's the standard term) to go through SMTP?[16:40:06] <lunaphyte> yeah[16:40:33] <lunaphyte> you get a number of additional benefit in doing that[16:41:34] <lunaphyte> also though, i'm not sure about needing setuid, etc., for using the sendmail command either. are you sure that's needed?[16:42:41] <lunaphyte> my /usr/sbin/sendmail is not setuid[16:47:39] *** Sylhouette <Sylhouette!~johan@62.12.9.66> has quit IRC (Remote host closed the connection)[16:47:40] <catern> lunaphyte: I don't think /usr/sbin/sendmail itself is setuid, but http://www.postfix.org/postdrop.1.html is setgid[16:48:00] *** Sylhouette <Sylhouette!~johan@62.12.9.66> has joined #postfix[16:48:21] <catern> which I believe is exec'd by postfix's sendmail[16:48:28] <catern> (or so http://www.postfix.org/OVERVIEW.html says)[16:50:00] <lunaphyte> i see[16:50:22] <catern> lunaphyte: forcing all local mail submission to go through SMTP sounds like a bit of a hassle for the user though - don't they then have to set up authenticating to SMTP as themselves? which seems unnecessary, because they're already running as that user account[16:50:36] <catern> (and so should be able to send mail as that user account, I guess)[16:50:42] <lunaphyte> yeah, using a null client would alleviate that concern, i would think[16:50:56] <lunaphyte> you could call it a hassle, sure[16:51:07] <lunaphyte> you could also just call it not really a big deal[16:51:26] <lunaphyte> any mail client they use, anywhere, they need to configure authentication[16:52:06] <lunaphyte> i'm not so sure i'd label that as much of a hassle. something you set up once, and then continue doing whatever it is you might be doing[16:52:09] <catern> hmm, I don't quite understand how you'd use a null client here. if the null client is configured system-wide, then to submit to the null client they'd still need to use sendmail/postdrop; do you mean a null client configured by the individual user or something?[16:52:25] <lunaphyte> good null client software can be both[16:52:52] <catern> lunaphyte: they don't need to configure authentication with traditional Unix mail - they just run sendmail and get mail from their spool[16:52:52] <lunaphyte> there can be default configurations, system wide configurations, per user configurations, multiple per user profiles, so on[16:53:10] <catern> what null client software do you have in mind?[16:53:12] <lunaphyte> i'm not sure about "run sendmail and get mail from their spool"[16:53:32] <lunaphyte> running sendmail in the context of a null client does get any mail from anywhere[16:53:37] <lunaphyte> *doesn't get[16:53:56] <lunaphyte> also, tbh, i don't really suggest running the sendmail command, etc all, for "users"[16:54:09] <lunaphyte> it shouldn't really ever be truly necessary[16:54:19] <catern> sure, but a lot of tools know how to run "sendmail" under the hood[16:54:26] <lunaphyte> i know i'm splitting hairs a bit, becuase ^^[16:54:27] <lunaphyte> yes, that[16:55:10] <lunaphyte> but many of those tools aren't typically ones used by people, per se. any many can be changed [and really should have had defaults changed ages ago][16:55:14] <lunaphyte> but that's another conversation[16:55:53] <catern> what should the default be for these tools that want to send mail? that does sound relevant[16:56:47] <lunaphyte> for mail submission? the mail submission protocol, e.g. submission or submissions[16:57:16] <lunaphyte> i'm talking about end user software - mail clients, in essence[16:57:51] <lunaphyte> services software is a little different, arguably, but i'd suggest probably 90% of that should also default the same[16:58:10] <lunaphyte> there are a few things that i believe can "legitimately" default to the sendmail command[16:58:55] <catern> oh, I see - I'm talking about not just dedicated mail clients, but tools in general, like, say, a cron-equivalent, or a build server, which want to send emails to notify users of failure[16:59:17] <lunaphyte> sure[16:59:24] <lunaphyte> cron gets a pass, imho[16:59:32] <lunaphyte> build tools don't[16:59:44] <lunaphyte> it's 2019 - use submission :)[17:00:15] <catern> I see, so you'd say they should have an SMTP library and directly speak SMTP?[17:00:27] <lunaphyte> in short, yeah[17:01:02] <lunaphyte> that's partly why it doesn't bother me to take the time configuring a null client for them to use[17:01:12] <lunaphyte> [it's not very much time though][17:01:15] <lunaphyte> oh, you asked before[17:01:21] <lunaphyte> !tell catern msmtp[17:01:21] <knoba> catern: "msmtp" : a nullclient program which provides a means for a computer to submit mail to an existing msa. see http://msmtp.sourceforge.net/ for more info. also see !nullclient_software, !nullclient and !msa[17:01:27] <lunaphyte> that's my current preference[17:01:29] <catern> ah yeah I use msmtp myself[17:02:00] <lunaphyte> you did prompt a thought[17:02:31] <lunaphyte> it would be useful if a null client could know about and default to using a shell user's current credentials, somehow[17:02:53] <lunaphyte> i bet there is a long path to that with kerberos, etc[17:03:08] <lunaphyte> but that's a little different than traditional credentials[17:03:24] <lunaphyte> i wonder if there is a pam mechanism that might facilitate something like that[17:03:36] <lunaphyte> anyway, it's off topic here[17:04:22] <catern> that's an interesting point about Kerberos[17:05:56] <catern> anyway, I think the position that most things should just speak SMTP directly or go through a nullclient which speaks SMTP to some server, and set up authentication for them, is very defensible and modern - it's a reality that most systems are single-user so that's what you need to do anyway[17:07:19] <catern> but I'm trying to set up mail for a more traditional Unix multi-user system, for fun; where, ideally, I might not even support mail submission from the internet over SMTP[17:07:43] <catern> having a localhost-only SMTP that users have to auth to, I still say, seems a bit of a waste[17:07:49] <lunaphyte> sure, i get it. a null client still fits just fine into that scenario[17:07:54] <lunaphyte> i don't think it's a waste[17:08:23] <lunaphyte> it breeds consistency[17:08:25] <lunaphyte> imo, that[17:08:32] <lunaphyte> imo, that's never a waste[17:08:41] <catern> well - I agree it's not a waste and it's nicely consistent - as long as there's a way that it can be set up so that the user doesn't have to think about any kind of auth stuff[17:09:13] <catern> It's basically just the auth part that I'm concerned about - otherwise I think it would be totally nice to have localhost-only (or Unix socket-only) SMTP as the submission mechanism[17:09:24] <lunaphyte> trying to make things so users don't have to think isn't super helpful in the long run[17:14:43] *** Sylhouet1e <Sylhouet1e!~johan@62.12.9.66> has joined #postfix[17:15:53] *** Sylhouette <Sylhouette!~johan@62.12.9.66> has quit IRC (Ping timeout: 245 seconds)[17:16:07] <catern> how exactly would you set it up? I don't think it's just a matter of users not having to think; if the auth is, say, password or key based, then the user would have to have that key in a file in their homedir - that opens up new possible avenues of attack that are impossible if you don't do auth and instead just check the uid of the submitter[17:17:55] <lunaphyte> well, one option you could consider, is just run the submission service on localhost only, like you mentioned above, and don't require smtp auth[17:18:16] <catern> doesn't that allow any user on the system to impersonate any other user on the system?[17:18:24] <lunaphyte> that would mean no configuration needed on a user's part, and no storage of credentials anywhere[17:18:38] <lunaphyte> catern: no more or less than using the sendmail command[17:19:05] <catern> I don't think the sendmail command allows impersonation? you can only send mail as yourself - or at least that's what I assume :)[17:19:14] <lunaphyte> i wouldn't assume that ;)[17:19:23] <catern> although. hmm. could I run multiple submission services on Unix sockets, one for each user? and use permissions to protect them?[17:19:35] <lunaphyte> you could, but yuck[17:19:56] <catern> that doesn't seem that yuck, it's not like it's a big additional cost to listen on some additional sockets[17:20:15] <lunaphyte> from a postfix configuration perspective, it would be pretty ridiculous[17:20:28] *** ced117 <ced117!~ced117@opensuse/member/ced117> has quit IRC (Quit: leaving)[17:21:03] <catern> why?[17:21:43] <catern> i admit the config file would get ugly since it would need to list each user on the system for which mail is supported, but, shrug, that's not that bad I'd say[17:23:19] <catern> and, ugh, is it really true that the sendmail command lets you impersonate other users?[17:24:43] <catern> I'm sure such a misconfiguration of the sendmail command is possible, but I really want to believe that there are at least some configurations where that's not possible (and that those configurations are normal for a traditional Unix mail setup)[17:25:29] *** ced117 <ced117!~ced117@opensuse/member/ced117> has joined #postfix[17:31:08] <lunaphyte> it seems to me that in the end, you're picking between one of two things. either setuid/setgid, or a password mechanism of some sort[17:31:33] <lunaphyte> i'd agree it could be argued that either is undesirable, but imo, that choice is obvious[17:31:54] <lunaphyte> when it comes to setgid, you pretty much don't have a choice. there is one answer, one approach to "solving"[17:32:18] <lunaphyte> when it comes to a password mechanism of some sort, there are a bunch of different ways that can be solved[17:32:53] <lunaphyte> then, when you include the additional benefits of a modern implementation, as you mentioned earlier, the choice becomes even clearer, to me[17:33:16] <lunaphyte> and that's not even getting into the many benefits you now get from a postfix perspective[17:33:45] <lunaphyte> you can enforce all kinds of things once there is an smtp envelope, and gain much more flexibility[17:33:50] <catern> it seems to me that there's at least a third alternative there: using Unix permissions to control access to the submission socket. you can optimize this alternative further to only have a single submission socket that everyone can access, if you can do a SCM_CREDENTIALS handshake in your protocol[17:34:26] <lunaphyte> with msmtp, there's the passwordeval command, which presents a lot of flexibility[17:35:23] *** ddBz_ <ddBz_!~gary@cpe-67-246-27-81.nycap.res.rr.com> has joined #postfix[17:35:45] <lunaphyte> i'm not familiar with SCM_CREDENTIALS handshake. i'm not sure if that's something the submission protocol supports. i doubt it does[17:35:54] <lunaphyte> anyway, away for a bit. bbl[17:37:03] *** [NoClan]GoAway <[NoClan]GoAway!~NoClan@195.138.249.10> has quit IRC (Ping timeout: 246 seconds)[17:38:11] <catern> SCM_CREDENTIALS is a special control message you can send over a Unix socket in Linux, which is guaranteed by the kernel to contain accurate pid/uid/gid for the other side; so you can do a permission check based on it[17:38:13] *** ddBz <ddBz!~gary@104.156.210.169> has quit IRC (Ping timeout: 268 seconds)[17:38:55] <catern> it's definitely not supported by SMTP, but you could do it with another protocol or just an extension of SMTP[17:40:28] *** xjsx <xjsx!~xjsxxx@S0106105611be31c3.cg.shawcable.net> has joined #postfix[17:45:25] *** xjsx <xjsx!~xjsxxx@S0106105611be31c3.cg.shawcable.net> has quit IRC (Changing host)[17:45:25] *** xjsx <xjsx!~xjsxxx@unaffiliated/pokergod> has joined #postfix[17:47:41] <xjsx> i've got a mailserver that has like 4 small companies on it. Other than DKIM, DMARC and SPF, .. most of the mails are going to spam. What's a service that I can use that people can still relay through me, but my mailserver relays through another service that actually can get the job done?[17:48:27] <thumbs> xjsx: why not have them talk to the other server directly instead?[17:48:44] <xjsx> our ISPs block 25[17:48:59] <thumbs> use submission then.[17:49:11] <thumbs> xjsx: you don't use port 25 to send emails, either way[17:49:45] *** [NoClan]GoAway <[NoClan]GoAway!~NoClan@195.138.249.11> has joined #postfix[17:53:23] <catern> thumbs: when you say "use submission" what do you mean?[17:53:37] <xjsx> i'm trying to figure that out, via google ;)[17:54:02] <thumbs> !tell catern submission[17:54:02] <knoba> catern: "submission" : Port 587 is submission, for user submission of mail, NOT suitable for mail exchange. See the commented example in master.cf. also see !msa, and rfc 6409. Also read http://www.maawg.org/sites/maawg/files/news/MAAWG_Port25rec0511.pdf[17:54:13] <thumbs> !tell xjsx submissions[17:54:13] <knoba> xjsx: "submissions" : RFC 8314 renames the old smtps port, 465/tcp, to submissions, for user submission of mail, NOT suitable for mail exchange, with implicit TLS rather than explicit STARTTLS via a plaintext TCP connection. Postfix can implement submissions with a separate smtpd(8) listener with -o smtpd_tls_wrappermode=yes . See the commented example for smtps in master.cf.[18:09:00] *** Pixelz <Pixelz!pix@pix.pp.se> has quit IRC (Quit: Leaving)[18:14:36] *** Pixelz <Pixelz!pix@pix.pp.se> has joined #postfix[18:20:34] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has joined #postfix[18:23:33] *** eelstrebor <eelstrebor!~eelstrebo@216-75-116-100.static.allophone.net> has quit IRC (Client Quit)[18:25:47] <lunaphyte> catern: oh, ok.[18:26:14] <lunaphyte> yeah, nothing that submission supports, as far as i know, but it's possible your sasl provider might[18:34:55] <catern> interesting thought[18:35:03] <catern> I could implement SCM_CREDENTIALS in SASL[19:07:01] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has quit IRC (Ping timeout: 268 seconds)[19:20:50] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has joined #postfix[19:24:50] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has quit IRC (Excess Flood)[19:25:40] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has joined #postfix[19:31:38] *** _cr_ <_cr_!~quassel@srv.ncxs.de> has joined #postfix[19:32:21] *** rsx <rsx!~rsx@ppp-188-174-145-11.dynamic.mnet-online.de> has quit IRC (Quit: rsx)[19:33:11] *** delacroix <delacroix!~delacroix@ip5f597811.dynamic.kabel-deutschland.de> has quit IRC (Read error: Connection reset by peer)[19:36:46] *** delacroix <delacroix!~delacroix@ip5f597811.dynamic.kabel-deutschland.de> has joined #postfix[19:37:33] *** Non-ICE <Non-ICE!~lisse@c2F31BF51.dhcp.as2116.net> has quit IRC (Ping timeout: 245 seconds)[19:48:22] *** Gaaab <Gaaab!~Gaaab@milik.frozenstar.info> has quit IRC (Ping timeout: 250 seconds)[19:54:42] *** delacroix <delacroix!~delacroix@ip5f597811.dynamic.kabel-deutschland.de> has quit IRC (Quit: ZNC - http://znc.in)[19:56:49] *** delacroix <delacroix!~delacroix@2a02:810c:e3f:e500:381a:b1ff:fe38:b6b8> has joined #postfix[20:00:55] *** Penguin_ <Penguin_!~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net> has quit IRC (Ping timeout: 258 seconds)[20:02:26] *** Blas <Blas!~a@unaffiliated/eth1> has quit IRC (Read error: Connection reset by peer)[20:02:41] *** Penguin_ <Penguin_!~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net> has joined #postfix[20:02:59] *** Blas <Blas!~a@unaffiliated/eth1> has joined #postfix[20:04:12] *** Gaaab <Gaaab!~Gaaab@87.18.34.103> has joined #postfix[20:10:09] <catern> what's the motivation/use case for the "pass" service type?[20:12:37] <lunaphyte> postscreen, mostly[20:14:17] <catern> makes sense, thanks[20:24:13] *** Gaaab <Gaaab!~Gaaab@87.18.34.103> has quit IRC (Ping timeout: 245 seconds)[20:26:27] *** Gaaab <Gaaab!~Gaaab@87.18.34.103> has joined #postfix[20:31:00] *** Gaaab <Gaaab!~Gaaab@87.18.34.103> has quit IRC (Ping timeout: 246 seconds)[20:31:35] *** Penguin_ <Penguin_!~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net> has quit IRC (Ping timeout: 258 seconds)[20:33:37] *** Penguin_ <Penguin_!~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net> has joined #postfix[20:35:17] *** Gaaab <Gaaab!~Gaaab@87.18.34.103> has joined #postfix[20:41:18] *** Gaaab <Gaaab!~Gaaab@87.18.34.103> has quit IRC (Ping timeout: 245 seconds)[20:42:48] *** Gaaab <Gaaab!~Gaaab@87.18.34.103> has joined #postfix[21:18:04] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has quit IRC (Read error: Connection reset by peer)[21:18:59] *** n_1-c_k <n_1-c_k!~nick@2a02:8010:63a6::70> has joined #postfix[21:52:35] <catern> is it possible in any configure of postfix to run it without starting the master as root? for example, if I don't listen on any privileged ports, I shouldn't need root at any point[21:53:25] <catern> I notice when I try to run "postfix", it yells at me: postfix: fatal: the postfix command is reserved for the superuser[21:55:33] <catern> I see from the source code of the "postfix" command that it does a uid check and exits if not uid 0, but I also see that postfix just delegates to running some administrative scripts - perhaps therefore I could just avoid using the "postfix" command?[22:02:45] <lunaphyte> the short answer is no[22:03:11] <lunaphyte> postfix, as designed, starts with the master process, and runs that as root[22:04:41] <lunaphyte> the postfix command is for controlling postfix. it's not the daemon process, and isn't related to providing any services[22:06:28] <catern> I see; then could I start the master process directly instead of using the postfix command?[22:07:01] <lunaphyte> perhaps, although the degree to which that may be supported i'm not sure of[22:07:17] <lunaphyte> some recent stuff done for the purposes of containerization may allude to that possibility though[22:08:17] <catern> is there somewhere I can see that stuff you mention?[22:08:41] <lunaphyte> in the documentation provided with the software[22:09:04] <lunaphyte> see the release notes and the change log[22:09:37] <lunaphyte> also see man 8 master[22:09:51] <lunaphyte> specifically, -i[22:10:42] <catern> ah that's interesting indeed[22:12:32] <catern> I suppose since the command line arguments to the master command are documented, that implies that starting it directly is at least somewhat supported...[22:16:19] <catern> also, (and I expect the answer is no) is there any way to start Postfix in an inetd-like configuration? specifically, I want to pass down already-bound-and-listening sockets to it[22:17:16] <catern> ah. welp: if (getuid() != 0) msg_fatal("the master command is reserved for the superuser");[22:21:45] <catern> now I have to decide whether I want to reimplement the postfix master or not :)[22:31:24] <rob0> It's not as simple as just rewriting master. You'd also have to make sure nothing is going to want privileged ports, change UID/GID, et c.[22:32:16] <rob0> I haven't been keeping up on the list lately, but I know in the past when this has come up as a feature request, the answer was no.[22:34:18] <rob0> It might be worth your time to search the list archives and see what Wietse has said about it.[22:36:34] <thumbs> what problem is this "solution" trying to solve?[22:37:38] <thumbs> other than "A nullclient is too simple, we need a more complicated solution"[22:44:37] *** cryptic <cryptic!~cryptic@142.196.139.17> has quit IRC (Ping timeout: 245 seconds)[22:48:53] <deni> Hey everyone. I gather the latest best practice is to use postscreen to do greylisting instead of postgrey? Right?[22:50:40] <rob0> oh, definitely. On its own greylisting really isn't that effective [for many years now], because most botnets retry their lists.[22:51:03] <rob0> !whatis cheatsheet 2[22:51:04] <knoba> rob0: A postscreen cheatsheet can be seen at http://rob0.nodns4.us/postscreen.html (updated 2017-07-06, now requires Postfix 2.11+)[22:57:45] <deni> rob0: by "greylisting on it's own" you mean I'd need to apply other methods as well? I agree. But to clarify so I'm not confused...it's not greylisting (the idea) that's deprecated it's postgrey (the implementation) right?[22:57:47] *** cryptic <cryptic!~cryptic@142.196.139.17> has joined #postfix[22:57:59] <deni> from what I understand postscreen does a lot of stuff not just graylisting[22:59:05] <rob0> !postscreen[22:59:06] <knoba> rob0: "postscreen" : SMTP triage server available since Postfix 2.8, see http://www.postfix.org/POSTSCREEN_README.html and http://www.postfix.org/postscreen.8.html[23:00:24] <rob0> "greylisting on its own," right, it is lousy if that's your only layer of defense.[23:00:25] <deni> rob0: yeah I'm going through those right now[23:00:37] <deni> rob0: gotcha[23:01:17] <rob0> and stuff that does only greylisting, like postgrey, outmoded[23:01:58] <deni> rob0: my next question was going to be about dnsbls but you're first link kind of covers that already[23:02:01] <deni> so thanks[23:04:02] <deni> rob0: the last question I had was about SPF.... I'm finding various ways to incorporate an SPF check into postfix...and I'm not sure what's the de-facto community agreed best practice. is it libspf2? is is perl/python based milters? policyd?[23:04:16] <rob0> I update that page when my config changes, it hasn't changed in quite some time now.[23:04:31] *** Diemuzi <Diemuzi!~diemuzi@unaffiliated/diemuzi> has joined #postfix[23:05:18] <catern> rob0: hmm, yeah I see some stuff on the list about how master needs root to change UID and drop privs, etc... but if I already know that I don't want postfix to be doing any privileged stuff, I think I should be able to run it as non-root from the start[23:05:35] <catern> thumbs: this is unrelated to my earlier question about nullclient alternatives[23:05:41] <lunaphyte> it's unlikely that that's really going to be practical[23:05:44] <rob0> I don't bother with SPF, but there is no reason for any after-DATA checks like a milter. A policy service would be the way to go.[23:06:27] <rob0> catern, yes, I am sure it is doable, but you'd have to be careful.[23:07:28] <rob0> deni, and my opinion on SPF is just that, "don't bother."[23:09:21] <deni> rob0: I've noticed that it actually takes care of a lot of spam on it's own. ¯\_(ツ)_/¯[23:10:38] <deni> On debian I'm seeing postfix-policyd-spf-python and postfix-policyd-spf-perl. I assume that would be the way to go[23:10:48] <lunaphyte> i wouldn't[23:11:07] <lunaphyte> i'd never use spf data outside of a content filter[23:11:40] <deni> lunaphyte: I don't follow. What would you use instead of the two policyd things that I listed above?[23:11:47] <deni> can you show an example?[23:11:49] <lunaphyte> um[23:11:52] <lunaphyte> a content filter?[23:12:12] <rob0> ^^ good point, although that's not necessary (to do SPF in a content filter), it makes sense in another way:[23:12:44] <deni> an after-queue content filter? http://www.postfix.org/FILTER_README.html ?[23:12:45] <rob0> ... you are scoring in a content filter, and SPF failure can add slightly to your score.[23:12:55] <lunaphyte> yes, an after queue content filter[23:13:01] <lunaphyte> that's another thing[23:13:03] <deni> gotcha[23:13:10] <lunaphyte> i'd never use a content filter that's not after queue[23:13:25] <deni> why would you use that instead of policyd?[23:13:25] <lunaphyte> i understand the impulse, but it's misguided[23:13:39] <lunaphyte> why a content filter instead of policyd?[23:13:42] <deni> yes[23:13:53] <lunaphyte> a policy service is not after queue, for one[23:14:22] <lunaphyte> more importantly, it's a mechanism that rejects mail solely on spf data. that's foolish[23:14:49] <lunaphyte> the reasons why rob0 wouldn't bother with spf are the same reasons i'd never use it as the sole factor for rejecting mail[23:27:09] <deni> lunaphyte: rob0 so the point is to use the SPF check as only part of the score (not a binary check) ... and you're saying I can only do that if I'm using it in after-queue content filters?[23:30:56] <lunaphyte> not quite[23:31:38] <lunaphyte> spf data should only be used as part of a larger scoring system, yes. it should not be used as a stand alone check, yes[23:32:38] <lunaphyte> that generally means as part of a content filter[23:33:11] <lunaphyte> although it's possible there might be [or there could be] a policy service which checks many things, among which could be spf[23:33:40] <lunaphyte> independent of that, imo, things like content filters should be implemented in an after queue manner[23:36:41] <deni> lunaphyte: got it[23:39:40] <deni> another thing I don't quite understand is why is it foolish to discard mail only based on a spf check? isn't setting a SPF record kind of email 101 these days?[23:39:53] <lunaphyte> well, this isn't really on topic here anymore[23:40:02] <lunaphyte> there's ##email though if it's something you wanted to discuss more[23:40:22] <deni> oh...I understand. Thanks[23:41:01] <deni> lunaphyte: is there an example of an content filter spf config somewhere? or will I stumble upon one once I finish reading the docs linked above?[23:49:52] *** Diemuzi <Diemuzi!~diemuzi@unaffiliated/diemuzi> has quit IRC (Quit: See you on the flip side!)