Re: No easy way to join discussion in existing thread when not subscribed

Поиск
Список
Период
Сортировка
От Amir Rohan
Тема Re: No easy way to join discussion in existing thread when not subscribed
Дата
Msg-id 5612BC03.2060403@zoho.com
обсуждение исходный текст
Ответ на Re: No easy way to join discussion in existing thread when not subscribed  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Ответы Re: No easy way to join discussion in existing thread when not subscribed
Список pgsql-www
On 10/02/2015 03:48 PM, Stefan Kaltenbrunner wrote:
> On 10/02/2015 02:45 PM, Stephen Frost wrote:
>> * Amir Rohan (amir.rohan@mail.com) wrote:
>>> 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).
>>
>> Works for me.
> 
> +1

Tosay I sepent some time looking more closely at this. I'd like your
input on a few decisions that needs to be made and some points
that need to be verified if this is to work.

pgarchives and pgweb are separate apps, each using its own db:
- pgweb has the MailQueue model, archives does not.
- pgarchives has the Message model, pgweb does not.

To implement a "mail me this message", one way or another we need
to iinteract with both.

We can either:
1) Upon request, have archives redirect to a new endpoint on pgweb,
which calls the archives "raw" endpoint to fetch the message,
parses it and push a job to the mail queue.
2) Upon request, have archives POST the message (and user email,etc')
to a new endpoint on pgweb. This needs to be inacccesible outside
the LAN, because it's basically a spam service.
3) Add an a Mailqueue model to pgarchives, and have it mail things
independently. This requires another cron job to drain the new queue.

Which do you prefer?

Next point, the Mailqueue is drained send_queued_mail.py,
would sending these messages, with an envelope-to: header
either through the local MTA or the relay be enough to
get it delivered to the user, or will this trigger any
anti-spam mechanisms along the way? If we use the local MTA,
is it setup to rewrite any headers before delivery?

Amir




В списке pgsql-www по дате отправления:

Предыдущее
От: Amir Rohan
Дата:
Сообщение: Re: pgarchives: strip angle brackets when checking for msgid search
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: No easy way to join discussion in existing thread when not subscribed