Re: No easy way to join discussion in existing thread when not subscribed - Mailing list pgsql-www

From Amir Rohan
Subject Re: No easy way to join discussion in existing thread when not subscribed
Date
Msg-id trinity-f3af28cb-6fc7-4930-a623-d6092fd4542d-1443757305383@3capp-mailcom-lxa02
Whole thread Raw
Responses Re: No easy way to join discussion in existing thread when not subscribed
Re: No easy way to join discussion in existing thread when not subscribed
List pgsql-www
On 10/01/2015 04:29 PM, Stephen Frost wrote:
> * Amir Rohan (amir.rohan@mail.com) wrote:
>> I added a blurb to the wiki about this. What about the "Mail me this
>> message" proposed earlier? I'd be glad to help make that happen.
> 
> I don't think anyone's really against that idea, except perhaps that we
> need to try and avoid letting it be abused.
> 
> Of course, someone needs to implement it.


On 10/01/2015 09:18 PM, Stefan Kaltenbrunner wrote:
>
> yeah - as Stephen said upthread I think that would be a very useful
> feature...
>

Great, here's a spec:

1) If the user is not logged in, error as the mbox downloads does.
2) If the user is logged in, retrieve the raw message from the db (like
the "raw" link) does and send it via email (the system is already setup
to do this) to the registered email address for the logged-in user.

Threats:
a1) Abusing the system to send lots of email to one victim.
a2) Abusing the system to send one email to lots of victims.
a3) DOS on the server through overuse by legitimate users.
a4) DOS on the server through overuse by malicious users, possibly
involving many accounts.

To mitigate these, we:
b1) Require a community login which involves an email verification step.
mitigates (a1) and (a2).

If a3 and a4 are concerns in practice:

b2) Implement per-user rate limits.
b3) Implement a global rate limit, to cap the size of mailqueue and
reduce the damage which can be done by registering many accounts.

If there's a kv store available (redis/memcached), we'll use that.
Otherwise,

CREATE TABLE rate_limit_mail_per_user( userid integer PRIMARY KEY, cnt integer NOTNULL, last_request_date timestamp NOT
NULL
);

CREATE INDEX on rate_limit_1(userid);

Saturate cnt on settings.RATE_LIMIT_THRESHOLD, and reset cnt when a
request comes in that is at least settings.RATE_LIMIT_DELAY seconds
after the last one.
The table size is bounded by the number of registered users, and it can
be truncated daily.

Comments?
Amir




pgsql-www by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: No easy way to join discussion in existing thread when not subscribed
Next
From: "Amir Rohan"
Date:
Subject: Re: No easy way to join discussion in existing thread when not subscribed