Re: New syntax and virtual aliases to remote addresses.
On 05/09/2019 11:32, gil...@poolp.org wrote: could be interesting to implement a tls builtin filter, so you could: filter check-tls phase mail-from match !tls junk and flag non tls options as spam, without discarding them completely You know, I was hoping you'd say that! :D I would so very much like to run with TLS only, but alas I have people here that need all these plain text private mails from their banks etc. :P I've already started to send out mails to point it out to them (bank, government institutions, etc). Even our old QMail (RIP) had TLSv1 in it. There's just no excuse. And the most absurd fact. Postfix needs a setting to turn on opportunistic TLS on outgoing mail. They default to none. Oh I'm angry today. In a positive way! :) Reio September 5, 2019 8:38 AM, "Reio Remma" wrote: On 02/09/2019 18:37, Reio Remma wrote: On 02/09/2019 18:36, Reio Remma wrote: Now I ended up switcing to tls-require on port 25. I wonder how much >> spam that will take down! :) Well, that's depressing. On the spam front - requiring TLS apparently cuts off about 99% of spam (SpamAssassin is practically out of work), but we do get the occasional legit non-TLS connection and I'm having to switch back to optional TLS. :/ So TLS is 20 years old but they're (banks etc) still sending somewhat private info in plain text. 'twas fun while it lasted. :) I'm going to start schooling them one by one. Reio
Re: New syntax and virtual aliases to remote addresses.
On 05/09/2019 09:38, Reio Remma wrote: On 02/09/2019 18:37, Reio Remma wrote: On 02/09/2019 18:36, Reio Remma wrote: Now I ended up switcing to tls-require on port 25. I wonder how much spam that will take down! :) On the spam front - requiring TLS apparently cuts off about 99% of spam (SpamAssassin is practically out of work), but we do get the occasional legit non-TLS connection and I'm having to switch back to optional TLS. :/ Now I'm thinking I should look into getting SpamAssassin score mails by lacking TLS. Reio
Re: New syntax and virtual aliases to remote addresses.
could be interesting to implement a tls builtin filter, so you could: filter check-tls phase mail-from match !tls junk and flag non tls options as spam, without discarding them completely September 5, 2019 8:38 AM, "Reio Remma" wrote: > On 02/09/2019 18:37, Reio Remma wrote: > >> On 02/09/2019 18:36, Reio Remma wrote: >> >>> Now I ended up switcing to tls-require on port 25. I wonder how much >> >>> spam that will take down! >>> :) > > Well, that's depressing. > > On the spam front - requiring TLS apparently cuts off about 99% of spam > (SpamAssassin is > practically out of work), but we do get the occasional legit non-TLS > connection and I'm having to > switch back to optional TLS. :/ > > So TLS is 20 years old but they're (banks etc) still sending somewhat private > info in plain text. > > 'twas fun while it lasted. :) > > I'm going to start schooling them one by one. > > Reio
Re: New syntax and virtual aliases to remote addresses.
On 02/09/2019 18:37, Reio Remma wrote: On 02/09/2019 18:36, Reio Remma wrote: Now I ended up switcing to tls-require on port 25. I wonder how much spam that will take down! :) Well, that's depressing. On the spam front - requiring TLS apparently cuts off about 99% of spam (SpamAssassin is practically out of work), but we do get the occasional legit non-TLS connection and I'm having to switch back to optional TLS. :/ So TLS is 20 years old but they're (banks etc) still sending somewhat private info in plain text. 'twas fun while it lasted. :) I'm going to start schooling them one by one. Reio
Re: New syntax and virtual aliases to remote addresses.
On 02/09/2019 18:36, Reio Remma wrote: On 02/09/2019 17:05, gil...@poolp.org wrote: September 2, 2019 3:35 PM, "Reio Remma" wrote: Hello! I was able to have virtual aliases pointing to external addresses with the old syntax, but it doesn't seem to work like that with new rules: Not awake enough to process what follows but the new syntax certainly allows this as my whole infrastructure depends on it ;-) I suspect that there's a problem with the ruleset that prevents external addresses from matching a rule themselves. Looking at you config at https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/ Now I ended up switcing to tls-require on port 25. I wonder how much spam that will take down! :) I also notice you're not using match auth anywhere, I think this might make the difference for mails from remote addresses to virtuals aliased to another remote address. I didn't have auth in the old config. Reio action filter_incoming relay host smtp://127.0.0.1:10024 action sign_outgoing relay host smtp://127.0.0.1:10026 action relay_outgoing relay action deliver_lmtp lmtp "/var/run/dovecot/lmtp" rcpt-to virtual userbase match tag FILTERED for domain action deliver_lmtp match tag SIGNED for any action relay_outgoing match auth from any for domain action deliver_lmtp match from any for domain rcpt-to action filter_incoming match auth from any for any action sign_outgoing Old rules were: accept tagged Filtered for domain virtual userbase deliver to lmtp "/var/run/dovecot/lmtp" rcpt-to accept from local for domain virtual userbase deliver to lmtp "/var/run/dovecot/lmtp" rcpt-to accept from !local for domain recipient relay via smtp://127.0.0.1:10024 accept tagged Signed for any relay accept from local for any relay via smtp://127.0.0.1:10026 recipi...@mydomain.com used to be nicely redirected to a remote recipi...@someotherdomain.com, but with the new syntax it doesn't hit any rules. I found that adding "match tag FILTERED for any action relay_outgoing" after "match tag FILTERED for domain action deliver_lmtp" solves the issue. I suspect that the old "accept tagged Filtered" went straight to MTA after expanding the virtual alias? Does it sound right to "match tag FILTERED for any" after dealing with FILTERED for our domains? Can I do anything about DKIM breaking for forwarded mails? Thanks, Reio -- Tervitades Reio Remma MR Stuudio 25 aastat *MR Stuudio OÜ* Tondi 17b, 11316, Tallinn Tel +372 650 4808 Mob +372 56 22 00 33 r...@mrstuudio.ee www.mrstuudio.ee
Re: New syntax and virtual aliases to remote addresses.
September 2, 2019 3:35 PM, "Reio Remma" wrote: > Hello! > > I was able to have virtual aliases pointing to external addresses with the > old syntax, but it > doesn't seem to work like that with new rules: > Not awake enough to process what follows but the new syntax certainly allows this as my whole infrastructure depends on it ;-) I suspect that there's a problem with the ruleset that prevents external addresses from matching a rule themselves. > action filter_incoming relay host smtp://127.0.0.1:10024 > action sign_outgoing relay host smtp://127.0.0.1:10026 > action relay_outgoing relay > action deliver_lmtplmtp "/var/run/dovecot/lmtp" rcpt-to virtual > userbase > > match tag FILTERED for domain action deliver_lmtp > match tag SIGNED for any action relay_outgoing > match auth from anyfor domain action deliver_lmtp > match from any for domain rcpt-to action > filter_incoming > match auth from anyfor any action sign_outgoing > > Old rules were: > > accept tagged Filtered for domain virtual userbase > deliver to lmtp > "/var/run/dovecot/lmtp" rcpt-to > accept from local for domain virtual userbase > deliver to lmtp > "/var/run/dovecot/lmtp" rcpt-to > accept from !local for domain recipient relay via > smtp://127.0.0.1:10024 > accept tagged Signed for any relay > accept from local for any relay via smtp://127.0.0.1:10026 > > recipi...@mydomain.com used to be nicely redirected to a remote > recipi...@someotherdomain.com, but > with the new syntax it doesn't hit any rules. > > I found that adding "match tag FILTERED for any action relay_outgoing" after > "match tag FILTERED > for domain action deliver_lmtp" solves the issue. > > I suspect that the old "accept tagged Filtered" went straight to MTA after > expanding the virtual > alias? > > Does it sound right to "match tag FILTERED for any" after dealing with > FILTERED for our domains? > > Can I do anything about DKIM breaking for forwarded mails? > > Thanks, > Reio
