On 3/12/19 3:57 AM, Aaryan Bhagat wrote:
>> The other kind are DSNs of some type returned to a LIST-bounces address.
>> These are processed by flufl.bounce
>> <https://gitlab.com/warsaw/flufl.bounce/> which determines whether the
>> failure is temporary or permanent and reports that to the bounce runner.
>
> In the end the bounce runner gets all the messages for a particular list and
> ( irrespective of who send them DSN or failure in SMTP).
> So I think dealing with them is our main objective.
The receipt and handling of delivery failures and bounces is already
well handled in Mailman 3 and results in a `bounce event` being stored.
It is what happens after that that is missing.
In Mailman 2.1 this is simpler in a way because addresses are local to a
list. I.e., there is no connection between an address subscribed to one
list and the same address subscribed to another list so the whole
process is compartmentalized by list and controlled by list settings.
These settings are:
The maximum member bounce score before the member's subscription is
disabled. This value can be a floating point number.
(Details for bounce_score_threshold)
The number of days after which a member's bounce information is
discarded, if no new bounces have been received in the interim. This
value must be an integer.
(Edit bounce_info_stale_after)
How many Your Membership Is Disabled warnings a disabled member should
get before their address is removed from the mailing list. Set to 0 to
immediately remove an address from the list once their bounce score
exceeds the threshold. This value must be an integer.
(Edit bounce_you_are_disabled_warnings)
The number of days between sending the Your Membership Is Disabled
warnings. This value must be an integer.
(Edit bounce_you_are_disabled_warnings_interval)
These settings are per list both to give list admins control and because
optimum values depend on list traffic patterns.
Mailman 3 currently does nothing after storing a 'bounce event'. That's
the issue. It's more complex with Mailman 3 because an address is
global, but somehow, it needs to be determined that we are receiving
bounces for a particular address and at some point delivery to that
address needs to be disabled (or a probe sent to the address and
delivery disabled if the probe bounces) and then periodically, notices
need to be sent to the address, and after some time if the user hasn't
responded and re-enabled delivery, perhaps the address should be removed
from the list, although this latter point is not so important in MM 3.
The additional complexity is because an address may be subscribed to
more than one list and optimum values for settings such as
bounce_score_threshold and bounce_info_stale_after depend on list
traffic patterns. Compromises will need to be made.
--
Mark Sapiro <m...@msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
_______________________________________________
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
