Re: New syntax and virtual aliases to remote addresses.

2019-09-05 Thread Reio Remma

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.

2019-09-05 Thread Reio Remma

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.

2019-09-05 Thread gilles
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.

2019-09-05 Thread Reio Remma

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.

2019-09-02 Thread Reio Remma

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.

2019-09-02 Thread gilles
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