Aaryan Bhagat writes: > >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.
In some sense, yes. Mark's point is that receipt of SMTP failures and DSNs is already recorded as a "bounce event". The classification of the various messages etc into bounce events we use has been working for literally decades; there is no need to revist it now. If you want to understand these well, you should read the RFCs on the mail system, such as RFC 5598 on the Internet Mail Architecture, RFC 5321 on SMTP, RFC 5322 on the Internet Message Format, and RFC 3464 on Delivery Status Notifications (which even today controls only a large fraction of DSNs, so we still receive non-standard DSNs). But all that study is *not* needed to work on Mailman; most of it is already encapsulated in Mailman 3 code. However, with Mailman 3 the interpretation of a bounce event may need to be changed because we now associate addresses and subscriptions with users. A bounce event may be thought of as a (from, to, timestamp) tuple, where "from" is the list, "to" is the subscribed address, and "timestamp" is the datetime of the event. (We only record how many have occurred, and how long since the last one.) In Mailman 2, only one subscriber-list pair is affected by the bounce count. This *may* make sense for Mailman 3 too, because (for example) one list has a lot of commercial traffic that looks spammy and generates "administrative refusal" bounces (perhaps because many users at one domain are receiving it) even though the user really wants it, while another list from the same site may be low-traffic and not generate bounces. Then the traditional Mailman 2 method of keeping bounce counts per subscriber per list makes sense. On the other hand, it might be that bounces for subscriber addresses are highly correlated across lists at the same site (eg, if mostly they are due to storage limitations). Then we want to record bounce counts per address, summing over lists. This is plausible, and some site administrators who are very sensitive to bounces (ie, want to disable or unsubscribe failing addresses quickly) might want this as an option, even if most sites want to use the per subscriber per list style. However, this could also be implemented by keeping per- subscription counts, and adding them up, at the cost of multiple hits to the database to find all subscriptions, then get all the bounce counts. We might even want to record bounce counts per user (ie, adding up counts for all addresses for that user), on the assumption that all addresses forward to the same "real" address, and most bounces are due to problems at that address. I think this is a bad idea, as in some cases automatic forwards are copies, and the user can read them at the subscribed address even though they normally read them at the "real" address. Such users would be really angry if a non-bouncing address got disabled! However, it gives you an idea of the scope of the kinds of issues we want to be considering now. Steve -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN _______________________________________________ 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
