Re: [mailop] Roundcube client IPs → dovecot, postfix

[Slavko via mailop]

Ahoj,

Dňa Tue, 28 Dec 2021 18:08:24 +0100 Nicolas JEAN via mailop
 napísal:

> Did you encounter the issue of the first IMAP connection not
> forwarding the actual client IP to dovecot?

OK, i try it, and i see it:

imap-login: Login: user=, method=PLAIN, rip=::1, ...
imap-login: Login: user=, method=PLAIN, rip=2001:...::1:1, ...

I removed timestamps (to short them), but these two lines appears
immediately one after other. And now i refresh my memory, that i saw
this when i installed (and test) that plugin.

I am not sure if that matters. IMO , when dovecot's auth policy will
reject the later (with real RIP), the roundcube's content will be empty
(at least i hope), and client's IP will be blocked by fail2ban soon or
latter. Or i am wrong?

regards

-- 
Slavko
https://www.slavino.sk


pgp0OCwrHe87f.pgp
Description: Digitálny podpis OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Walled gardens

[John Levine via mailop]

It appears that yuv via mailop  said:
>The first thing to make internet email viable for the future is to
>establish a defensible perimeter and keep bad actors out.  Easier said
>than done. ...

Unfortunately, e-mail walled gardens are a Well Known Bad Idea.

The short version is that any collection of people large enough to be
interesting is also large enough to have people you don't want to
hear from.

The slightly longer version is whatever criteria you use to decide whose
mail to accept is unlikely to match the set of people whose mail you
actually do want to accept, and the more hoops you expect people to
jump through, the more likely it is that people will decide they
weren't all that eager to send you that contract proposal.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What a drag it is sending DMARC reports

[John Levine via mailop]

It appears that Hans-Martin Mosner via mailop  said:
>I'm working on a reputation based system which would use a p2p network to 
>transmit reputation opinions very quickly, 
>allowing each node's policy to decide who to trust and what actions to take.

Web of Trust is another WKBI.

I'd suggest looking at all the ways this has failed before before trying again.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Noel Butler via mailop]

On 29/12/2021 03:50, Jaroslaw Rafa via mailop wrote:


It is Roundcube that is actually connecting to Dovecot/Postfix and
receiving/sending mail, not the user's browser, so the connecting IP 
that
Dovecot/Postfix gets is technically correct. No need to change it. On 
the
other hand, user's browser is talking HTTP to Roundcube, and Roundcube 
knows

it's IP address, so Roundcube is the point where restrictions should be
enforced, not Dovecot/Postfix.


Agreed, dovecot doesnt know - nor care - if its kmail, evolution, 
thunderbird, outlook, RC, imapproxy, or some other client, it's not its 
job to care.


RC has rcguard which works well, and as mentioned by another poster 
there is always fail2ban.


Frankly, I don't see any problem that needs addressing, and I guess 
neither do the RC team if this is as is claimed a "long standing" issue 
for a small minority.


As to the anti privacy brigade, suck it up, we are network operators, if 
we want to know who they are, we can, just means we have to multitask 
looking at two logs, i mean FFS, how hard is that, you already do this 
tracking local spammers actions and then looking them up in CRM or 
radius, or some other database.


get over it.
--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail Postmaster Not Showing Domain Reputation

[Jenny Nespola via mailop]

You are not alone. This is a problem being seen by many people. I've been
told Google is aware. So now we need to just give them some time to revive
it.

On Tue, Dec 28, 2021 at 8:10 AM Alson Wong via mailop 
wrote:

> Hello,
>
> Looks like Gmail Postmaster has not been updating its domain reputation
> since last week.
>
> The last domain reputation shown was from 17th of December.
>
> Are you guys having the same situation too or is it just me ?
>
> Thanks.
>
> Alson
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Nicolas JEAN via mailop]

Il 28/12/2021 20:00, Andrew C Aitchison via mailop ha scritto:

On Tue, 28 Dec 2021, Jaroslaw Rafa via mailop wrote:

Can't these restrictions be just moved from Dovecot/Postfix to Roundcube
itself? Roundcube definitely knows the value of the 
$_SERVER["REMOTE_ADDR"]

variable and can make use of it...


If a provider makes both IMAP and Roundcube access available, any 
restrictions implemented on Roundcube would need to be duplicated on 
the IMAP service.


I tend to agree with Andrew here. If I have IP-based policies set up for 
dovecot already, I'd like them to be applicable to IMAP login attempts 
coming from roundcube as well.
(Policies as in collecting the data -- which IPs are making how many 
(failed) logins --, and deciding which of them to block -- brute-force 
and others.)



It is Roundcube that is actually connecting to Dovecot/Postfix and
receiving/sending mail, not the user's browser, so the connecting IP 
that
Dovecot/Postfix gets is technically correct. No need to change it. On 
the
other hand, user's browser is talking HTTP to Roundcube, and 
Roundcube knows

it's IP address, so Roundcube is the point where restrictions should be
enforced, not Dovecot/Postfix.


*If* I understand correctly, Roundcube allows a user to interact with 
multiple mail-boxes, in which case Roundcube may not be under control 
of the same organisation as the IMAP account.


Also a good point.
In that case both organisations may have different policies, which seems 
fine. If I'm the one managing dovecot, I'd still like my security rules 
to be enforceable.


Nico



OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Nicolas JEAN via mailop]

Hi Slavko,

Il 28/12/2021 17:35, Slavko via mailop ha scritto:

Dňa 28. decembra 2021 15:55:57 UTC používateľ Nicolas JEAN via 
mailop  napísal:

At least with dovecot you can 
usehttps://gitlab.com/takerukoushirou/roundcube-dovecot_client_ip
which can add client's IP to login information (via IMAP's ID command).

I use it with my dovecot's auth policy daemon.


Nice!

Did you encounter the issue of the first IMAP connection not forwarding 
the actual client IP to dovecot? (the one sent from roundcube's login page)
This is what pushed me to write the mentioned patch 
.


Cheers,
Nico



OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Andrew C Aitchison via mailop]

On Tue, 28 Dec 2021, Jaroslaw Rafa via mailop wrote:


Dnia 28.12.2021 o godz. 07:17:43 Michael Peddemors via mailop pisze:


For us, the security value of passing the originating IP to the
Dovecot or SMTP layers for auth restrictions is paramount, as well
as other details on the originating sender. (Country AUTH
restrictions, OS Detection, and many more)


Can't these restrictions be just moved from Dovecot/Postfix to Roundcube
itself? Roundcube definitely knows the value of the $_SERVER["REMOTE_ADDR"]
variable and can make use of it...


If a provider makes both IMAP and Roundcube access available, any 
restrictions implemented on Roundcube would need to be duplicated

on the IMAP service.


It is Roundcube that is actually connecting to Dovecot/Postfix and
receiving/sending mail, not the user's browser, so the connecting IP that
Dovecot/Postfix gets is technically correct. No need to change it. On the
other hand, user's browser is talking HTTP to Roundcube, and Roundcube knows
it's IP address, so Roundcube is the point where restrictions should be
enforced, not Dovecot/Postfix.


*If* I understand correctly, Roundcube allows a user to interact with 
multiple mail-boxes, in which case Roundcube may not be under control

of the same organisation as the IMAP account.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Slavko via mailop]

Dňa 28. decembra 2021 17:08:24 UTC používateľ Nicolas JEAN via mailop 
 napísal:

>Did you encounter the issue of the first IMAP connection not forwarding 
>the actual client IP to dovecot? (the one sent from roundcube's login page)

Terrible to tell now, as i didn't care before and i am not at PC to see server's
log now. If i will not forget, i will try tomorrow.

In really nobody uses my roundcube, only as fallback or to edit sieve rules from
time to time...

Slavko
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Nicolas JEAN via mailop]

Bonjour Dominique,
and thanks for your comments!

Il 28/12/2021 17:23, Dominique Rousseau via mailop ha scritto:

Le Tue, Dec 28, 2021 at 04:55:57PM +0100, Nicolas JEAN via mailop 
[mailop@mailop.org] a écrit:
(...)

My conclusion is that today, there's no technical way to forward
client IPs from roundcube to dovecot/postfix.

You mean... without patching ?
( you pointed to an issue on roundcube github which add the proxy of
orignal IP )
With the mentioned plugin & patch, client IPs are always forwarded to 
dovecot, so I believe we're clear on this front (IMAP login attempts).


Which left me thinking: what about SMTP login attempts? (forwarded from 
roundcube to postfix)
Hence this question 
 
on the roundcube's git.


But yes, my feeling is that we're getting closer to that technical 
solution.  ;)



As for limiting bruteforce attacks ( I believe that's one of the aims ),
you could also use somehting like this fail2ban plugin :

https://github.com/mattrude/rc-plugin-fail2ban

True, stumbled upon that one while researching, surely a nice to have!
I'm also looking for ways to detect and block other kinds of attacks, 
for example with dovecot auth policy.


Nico



OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Jay Hennigan via mailop]

On 12/28/21 09:27, Steven Champeon via mailop wrote:


I hope to die before that logic extends to hiding what channel you are
tuned into on a TV or radio for "privacy reasons". Infrastructure is
infrastructure, it's not like every packet you send has a social security
number or bank account routing number in it. Ridiculous.


In the off-the-air and analog cable model that is still the case, and 
IMHO should be when it comes to broadcast media delivered over cable and 
IP.


Do you really want your cable company selling lists of "Fox News 
Viewers" and "MSNBC Viewers" to anyone willing to pay for that data? 
Don't forget that politicians conveniently exempted themselves from TCPA 
and anti-spam laws.


How about content providers selling lists of which households watch 
which adult PPV channels?


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Richard W via mailop]

On 2021-12-28 11:27 a.m., Steven Champeon via mailop wrote:


I hope to die before that logic extends to hiding what channel you are
tuned into on a TV or radio for "privacy reasons". Infrastructure is
infrastructure, it's not like every packet you send has a social security
number or bank account routing number in it. Ridiculous.



Those that advocate IP addresses are PII still drive around with a 
license plate on their car.  That's even more PII out in the open as 
that is a static IP.


Richard
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Steven Champeon via mailop]

on Tue, Dec 28, 2021 at 07:17:43AM -0800, Michael Peddemors via mailop wrote:
> The problem isn't 'technical', but rather political.  There are
> those out there that believe by including the originating IP
> Address, you are exposing PPI (Private Personal Information) by
> including the IP Address.
> 
> Of course, I personally think this is baloney, as the email operator
> can simply tell customers that this information will be disclosed,
> as part of the terms of service.  By including the IP Address, you
> add transparency, security and safety to the communication.

I hope to die before that logic extends to hiding what channel you are
tuned into on a TV or radio for "privacy reasons". Infrastructure is
infrastructure, it's not like every packet you send has a social security
number or bank account routing number in it. Ridiculous.

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/
Internet security and antispam hostname intelligence: http://enemieslist.com/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Jaroslaw Rafa via mailop]

Dnia 28.12.2021 o godz. 07:17:43 Michael Peddemors via mailop pisze:
> 
> For us, the security value of passing the originating IP to the
> Dovecot or SMTP layers for auth restrictions is paramount, as well
> as other details on the originating sender. (Country AUTH
> restrictions, OS Detection, and many more)

Can't these restrictions be just moved from Dovecot/Postfix to Roundcube
itself? Roundcube definitely knows the value of the $_SERVER["REMOTE_ADDR"]
variable and can make use of it...

It is Roundcube that is actually connecting to Dovecot/Postfix and
receiving/sending mail, not the user's browser, so the connecting IP that
Dovecot/Postfix gets is technically correct. No need to change it. On the
other hand, user's browser is talking HTTP to Roundcube, and Roundcube knows
it's IP address, so Roundcube is the point where restrictions should be
enforced, not Dovecot/Postfix.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[G. Miliotis via mailop]

On 2021-12-28 17:55, Nicolas JEAN via mailop wrote:
My conclusion is that today, there's no technical way to forward 
client IPs from roundcube to dovecot/postfix.


Doesn't the XFORWARD feature work for postfix? I thought that's how 
amavis for example talks to postfix. Usually via a dedicated master.cf 
entry.


http://www.postfix.org/XFORWARD_README.html

I would expect an additional issue to be that if one uses an imap proxy, 
the connections can't be "chunked" for all users, as you would need to 
re-auth everytime. So you may get reduced benefit from your proxy.


Best regards,
GM

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail Postmaster Not Showing Domain Reputation

[Allen Kevorkov via mailop]

 Same here.

~ Allen K

On Tuesday, December 28, 2021, 08:09:23 AM EST, Alson Wong via mailop 
 wrote:  
 
 Hello,
Looks like Gmail Postmaster has not been updating its domain reputation since 
last week.
The last domain reputation shown was from 17th of December.
Are you guys having the same situation too or is it just me ?
Thanks.
Alson___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
  ___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Slavko via mailop]

Dňa 28. decembra 2021 15:55:57 UTC používateľ Nicolas JEAN via mailop 
 napísal:

>Still, even if I'm going to have all legalities cleared and my terms of 
>service updated...
>My conclusion is that today, there's no technical way to forward client 
>IPs from roundcube to dovecot/postfix.

At least with dovecot you can use 
https://gitlab.com/takerukoushirou/roundcube-dovecot_client_ip
which can add client's IP to login information (via IMAP's ID command).

I use it with my dovecot's auth policy daemon.

regards

Slavko
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs ??? dovecot, postfix

[Dominique Rousseau via mailop]

Hi,

Le Tue, Dec 28, 2021 at 04:55:57PM +0100, Nicolas JEAN via mailop 
[mailop@mailop.org] a écrit:
(...)
> >Possibly on install, it should ask the email operator for their
> >position, and 'maybe' warning them they should indicate that occurs
> >on their terms of service.  But of course, most operators don't
> >indicate that for instance the customers real name might be exposed
> >under certain circumstances.
> 
> Still, even if I'm going to have all legalities cleared and my terms of
> service updated...
> My conclusion is that today, there's no technical way to forward
> client IPs from roundcube to dovecot/postfix.

You mean... without patching ?
( you pointed to an issue on roundcube github which add the proxy of
orignal IP )


As for limiting bruteforce attacks ( I believe that's one of the aims ),
you could also use somehting like this fail2ban plugin :

https://github.com/mattrude/rc-plugin-fail2ban



-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Nicolas JEAN via mailop]

Hi Michael,

Il 28/12/2021 16:17, Michael Peddemors via mailop ha scritto:
The problem isn't 'technical', but rather political.  There are those 
out there that believe by including the originating IP Address, you 
are exposing PPI (Private Personal Information) by including the IP 
Address.


Thanks for raising the legal issue here, it's valid and I hadn't thought 
of it.


Possibly on install, it should ask the email operator for their 
position, and 'maybe' warning them they should indicate that occurs on 
their terms of service.  But of course, most operators don't indicate 
that for instance the customers real name might be exposed under 
certain circumstances.


Still, even if I'm going to have all legalities cleared and my terms of 
service updated...
My conclusion is that today, there's no technical way to forward client 
IPs from roundcube to dovecot/postfix.


Suggest that you make a RoundCube enhancement with the packagers that 
the option be configured more easy on install.  The secondary issue, 
is to standardize how web mail would pass that information to the mail 
server, so you are not dealing with many different methods. And 
thirdly, in case of 'proxies' to the actual mailservers, how to pass 
that information through the proxy as well.


If the roundcube folks do include an option to enable this, I'll make 
sure to pass the word abut possible legal implications.


I agree with you on the standardised way of course, although my focus is 
on roundcube at the moment.


Nico



OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Michael Peddemors via mailop]

Hi Nicolas,

The problem isn't 'technical', but rather political.  There are those 
out there that believe by including the originating IP Address, you are 
exposing PPI (Private Personal Information) by including the IP Address.


Of course, I personally think this is baloney, as the email operator can 
simply tell customers that this information will be disclosed, as part 
of the terms of service.  By including the IP Address, you add 
transparency, security and safety to the communication.


But it should be easier and claerer for email operators to choose 
whether to include that information, on all web mail platforms.


Possibly on install, it should ask the email operator for their 
position, and 'maybe' warning them they should indicate that occurs on 
their terms of service.  But of course, most operators don't indicate 
that for instance the customers real name might be exposed under certain 
circumstances.


The world has gone far too anal in it's approach to privacy, at the 
expense of security, IMHO.


For us, the security value of passing the originating IP to the Dovecot 
or SMTP layers for auth restrictions is paramount, as well as other 
details on the originating sender. (Country AUTH restrictions, OS 
Detection, and many more)


Suggest that you make a RoundCube enhancement with the packagers that 
the option be configured more easy on install.  The secondary issue, is 
to standardize how web mail would pass that information to the mail 
server, so you are not dealing with many different methods.  And 
thirdly, in case of 'proxies' to the actual mailservers, how to pass 
that information through the proxy as well.


IMHO.

On 2021-12-28 5:55 a.m., Nicolas JEAN via mailop wrote:

Hi everyone,

I'd like to gather some thoughts on the following issue.

*Problem*

By default, roundcube login attempts (imap, smtp) are forwarded to 
dovecot/postfix without the original client IP that makes the request 
(possibly true of other webmail software).


This can't benefit from IP-based policies such as dovecot's auth policy 
: 
dovecot/postfix are always going to see localhost, internal reverse 
proxy's, or roundcube's IP address.


*Possible future solution*

There is a long-standing open issue 
 at roundcube to 
add /proxy protocol/ support.

This would make dovecot and postfix aware of requesting client IPs.

Unfortunately, it doesn't seem like it's going to be merged soon.

*Alternative*

There is a existing roundcube plugin 
 that 
adds client IPs to IMAP login attempts made to dovecot (which I've 
patched 
 
yesterday to send client IP on first IMAP login too).


I've also asked 
 
the roundcube community whether this would suffice; that is, if 
roundcube doesn't have an /unauthenticated/ endpoint for making SMTP 
login attemps (thus blocking IPs for IMAP could be enough).


*Ideas welcome*

Do you use webmails; if so, is this an issue for you as well?
Did you find a way to fix or work around it?
Do you feel like I'm on the right path here, or lost in a dangerous 
spacetime?


Thanks a lot in advance,
Nico


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What a drag it is sending DMARC reports

[Hans-Martin Mosner via mailop]

Am 28.12.21 um 14:31 schrieb yuv via mailop:

On Tue, 2021-12-28 at 12:11 +0100, Hans-Martin Mosner via mailop wrote:


I'm working on a reputation based system which would use a p2p
network to transmit reputation opinions very quickly,

COMPLICATED.


The problem is behavioral, not technological.  More technology is not
the solution.


I'm a software developer, not a lawyer. And as you certainly know, if the only tool you have is a hammer, all things 
tend to look like nails...


Triggering changes in law or pushing contractual agreements between third parties is out of my reach. If you can do it, 
more power to you! I'll resort to things I can do. As a spam recipient (or mail admin of systems with hundreds of 
recipients) my primary goal is to keep as much spam as possible out of my user's mailboxes at as low cost as possible. 
And as a software developer, my way of doing it is to identify spammer resources and block them, regardless of their 
location. I have tried talking to hosting providers and domain registrars, it's not effective. As a single person I have 
absolutely no means to change their mind.


The main aspect of my pipe dream is not the technology, but the social effect - spammers won't be much impressed, but 
agents at the border between spammer services and normal business have a reputation which can suffer if enough 
information about their bad behavior is available.


Reputation is a very powerful lever where laws are not present or effective. When entities engage in unethical yet legal 
behavior, spreading information about them and enabling interested parties to take their own measures (boycott) has 
shown to be effective, and ultimately it may lead to improved laws. One example is the gradual creation of laws to 
improve environmental awareness and animal wellbeing in the production of food. Much of that started by grassroots 
awareness campaigns which made the discount supermarkets look bad when their products were created in ethically 
questionable ways.


I somewhat hope that improved rejection of spam mails and making spam-supporting agents known will gradually make spam 
less effective. I know that this hope may be futile. If it is, I will at least improve the signal-to-noise level for my 
users, which is a good goal anyway.


Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Roundcube client IPs → dovecot, postfix

[Nicolas JEAN via mailop]

Hi everyone,

I'd like to gather some thoughts on the following issue.

*Problem*

By default, roundcube login attempts (imap, smtp) are forwarded to 
dovecot/postfix without the original client IP that makes the request 
(possibly true of other webmail software).


This can't benefit from IP-based policies such as dovecot's auth policy 
: 
dovecot/postfix are always going to see localhost, internal reverse 
proxy's, or roundcube's IP address.


*Possible future solution*

There is a long-standing open issue 
 at roundcube to 
add /proxy protocol/ support.

This would make dovecot and postfix aware of requesting client IPs.

Unfortunately, it doesn't seem like it's going to be merged soon.

*Alternative*

There is a existing roundcube plugin 
 that 
adds client IPs to IMAP login attempts made to dovecot (which I've 
patched 
 
yesterday to send client IP on first IMAP login too).


I've also asked 
 
the roundcube community whether this would suffice; that is, if 
roundcube doesn't have an /unauthenticated/ endpoint for making SMTP 
login attemps (thus blocking IPs for IMAP could be enough).


*Ideas welcome*

Do you use webmails; if so, is this an issue for you as well?
Did you find a way to fix or work around it?
Do you feel like I'm on the right path here, or lost in a dangerous 
spacetime?


Thanks a lot in advance,
Nico



OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What a drag it is sending DMARC reports

[yuv via mailop]

On Tue, 2021-12-28 at 12:11 +0100, Hans-Martin Mosner via mailop wrote:
> Am 28.12.21 um 11:08 schrieb Alessandro Vesely via mailop:
> > OTOH, if it were possible to ascribe each nastiness to its actual
> > culprit

UNNECESSARY AND


> I'm working on a reputation based system which would use a p2p
> network to transmit reputation opinions very quickly,

COMPLICATED.


The problem is behavioral, not technological.  More technology is not
the solution.

There are very simple natural principles of economics and law that have
proven themselves over time:  proximity; the least cost avoider; and
the duty to mitigate.

Proximity is the distance of an actor (or in this case a node) to the
incident.  In the case of spamming or other internet malware, the
incident is the spam reaching the egress node and the distance is
measured in hops across jurisdictions / controlling actors.

The least cost avoider in a system of interrelated actors is the actor
who could prevent the incident at the lowest cost.  At first sight, on
the internet the least cost avoider is the ingress node.

However, the cost for each egress node individually to reach the
ingress node is higher than the cost for the next upstream node to do
so; and often, the ingress node is out of reach because off-shore or
unknown.  Therefore, it makes economic sense to fix the problem at the
next upstream node and the solution is a legal one, not a technical
one:  impose the duty to mitigate on the upstream node.  Even if the
upstream node is not the culprit, it is in the best position to prevent
further harm and must do so.

The duty to mitigate can be imposed as contractual liability (terms of
service) or as statutory liability (a law enacted by a progressive
jurisdiction).  It would take the form of a penalty that is painful
enough to motivate the upstream node to fix the problem.  In an ideal
world, the penalty would escalate progressively, starting with a
warning on first incident, then increasingly higher fines for further
incidents; and ultimately puling the plug and cutting off access to the
node that does not fix the problem.

What and how can be imposed depends on who is in a position of
authority.  A closed system operated by a single authority can afford a
finer approach than a federated system spanning multiple sovereign
jurisdictions and a miriad of participants that may have to resort to a
blunter approach: cut them off at the inter-jurisdictional border until
they get it and join progress on the other side.  A large operator can
afford cutting others off, and if a large, benign email operator would
start to seriously cut off sources of spam, it would be beneficial for
smaller operators to follow its lead and join a closed but clean
federated system that would eventually grow to be open to actors that
abide by the simple rule of policing their immediate upstream.  I am
not holding my breath for this to happen when the two largest operators
are at the same time also the two largest enablers of spam.  As long as
they maintain that split personality, internet email is doomed to be a
dungeon of horrors.

--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Gmail Postmaster Not Showing Domain Reputation

[Alson Wong via mailop]

Hello,

Looks like Gmail Postmaster has not been updating its domain reputation
since last week.

The last domain reputation shown was from 17th of December.

Are you guys having the same situation too or is it just me ?

Thanks.

Alson
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What a drag it is sending DMARC reports

[Hans-Martin Mosner via mailop]

Am 28.12.21 um 11:08 schrieb Alessandro Vesely via mailop:



Yeah, we inevitably fall back to IP address lists.  Perhaps not so much because it's easier to outline a perimeter 
using numbers than names, but because it's rather immediate to operate on the former.  A set of good names would sound 
like a meaningful friendly region, immune from changes of ISP.


OTOH, if it were possible to ascribe each nastiness to its actual culprit, we'd still need a policy to treat them 
effectively.  IME, banning for a period, à la fail2ban, requires too much looking after exceptions.  But allowing to 
each individual to run a million-email spam act even just once in a lifetime is obviously too much.  I don't think a 
military approach would do much better. 


I'm working on a reputation based system which would use a p2p network to transmit reputation opinions very quickly, 
allowing each node's policy to decide who to trust and what actions to take.


Transmitted information would consist of "statements" stating something that may or may not be true, and "opinions" 
signed (pseudonymously) by participants expressing agreement or disagreement with statements (using a range of -3..3). 
The subjects of statements may be IP ranges (special case is single IP address), AS numbers, domain names, e-mail 
addresses, URLs, or hashes of such subjects (mostly to protect privacy for exploited e-mail addresses).


Some examples:

 * Statement "spammer(frauds...@gmail.com)", opinion "certainty=3, 
valid_from=2021-12-28, valid_for=30, signature=xyz"
 o This expresses that "xyz" firmly believes that frauds...@gmail.com is a 
spammer. The opinion should be
   considered valid for 30 days starting today.
 * Statement "spammer(tana.it)", opinion "certainty=-3, valid_from=2021-12-28, 
valid_for=365, signature=vesely"
 o This expresses that tana.it is certainly not a spammer
 * Statement "spammer_friendly(AS202306)", opinion "certainty=2, 
valid_from=2021-12-28, valid_for=30, signature=xyz"
 o xyz is fairly sure that the operators of AS202306 don't give a flying 
f*k about spammers on their network
 * Statement "exploited(#Tu6sYF3pYtQFIrKr3Sktx4innT47Jk7jMAHHhsg5ZGU=)", 
opinion="certainty=3, valid_from=2021-12-28,
   valid_for=7, signature=xyz"
 o The resource which hashes to this value is believed to be exploited by 
spammers. The signer assumes that this
   would be fixed within a week.
 * Additional statement types would be more database-like, to help in 
implementing policies and to report abuse:
 o "dynamic()" to maintain a list of dynamic IP address ranges and domains,
 o "asn(IP,AS)" to express that a given IP range belongs to some autonomous 
system,
 o "abuse(IP|Domain,EMail|URL)" to express that abuse complaints for a 
given IP range or domain can be sent to some
   e-mail address or entered into a web form. Negative opinions about such 
"abuse()" statements would state that
   these abuse contacts seem to be non-functional.
 o "signer()" makes it possible to publicly express a network of trust, so if I sign 
a statement "signer(vesely)"
   with a certainty of 2 I state that I consider Alessandro's opinions 
valuable. He may sign the same statement
   with a certainty of 3 unless he doesn't trust his own opinions, which 
would be a bit strange.
 * It should be possible to store private opinions (for example to whitelist 
certain resources) that are meant to
   determine local policy decisions but should not be shared with the network.

Nodes may reject e-mails matching "spammer()" or "exploited()" statements signed by trusted peers, and may temp reject 
mails matching a "spammer_friendly()" statement or one where there's a majority of bad opinions but not sufficient trust 
in the signer of these opinions. Temp rejection may be enough to curb a wave of spam emanating from one resource, 
reducing that million-email spam run to hopefully a few hundred or thousand delivered mails.


This is all at a very early stage, I'm working on the P2P aspect right now, will integrate a milter and/or postfix 
policy daemon interface next year, and deploy to the systems under my control for testing in a friendly environment. 
Later on I'll need to harden the P2P network against malicious actors (as the system is intended to be publicly 
joinable, spammers might want to disrupt its organization) and integrate user friendly management interfaces (a command 
line interface plus some web stuff).


A spam reporting helper may be a later add-on application. This would utilize the database aspects to decide who to send 
abuse reports to, and what mechanisms to choose. Think distributed spamcop.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What a drag it is sending DMARC reports

[Alessandro Vesely via mailop]

On Mon 27/Dec/2021 17:50:11 +0100 yuv wrote:

The first thing to make internet email viable for the future is to
establish a defensible perimeter and keep bad actors out.  Easier said
than done.  The problem does not affect email only.  It affects
anything internet.  Lacking a proper perimeter, my network is my
perimeter and the default rule at my router is nothing in, nothing out,
until an exception is added.  I am not there yet, but nearly.
Maintaining lists of allowed IP addresses is not as difficult as it
sounds.  There will be pain along the way, but if service providers are
not able to federate around clear rules to establish a defensible
perimeter and keep out the bad actors, I have no other choices.  Enough
is enough.  It is time to make operators liable for what emanates from
their IP addresses, and until that liability is in place, filter them
out, cost what it cost.



Yeah, we inevitably fall back to IP address lists.  Perhaps not so much because 
it's easier to outline a perimeter using numbers than names, but because it's 
rather immediate to operate on the former.  A set of good names would sound 
like a meaningful friendly region, immune from changes of ISP.


OTOH, if it were possible to ascribe each nastiness to its actual culprit, we'd 
still need a policy to treat them effectively.  IME, banning for a period, à la 
fail2ban, requires too much looking after exceptions.  But allowing to each 
individual to run a million-email spam act even just once in a lifetime is 
obviously too much.  I don't think a military approach would do much better.



Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop