Hi.
Back on the topic of bogus web signups again. I am dealing with several hundreds of these per month and we're talking a very low traffic system here. I have a cronjob to remove the users from the database.
Right now a concern for me is handling the bounces for the confirmation emails that don't get delivered. These are coming from postorius@lists.hodgsonfamily.org<mailto:postorius@lists.hodgsonfamily.org> which I have redirected to a mailbox so as not to clutter up the mail queue.
What I would ideally like is if we get a bounce from one of these confirmation mails we delete the user from the database but that is probably a future request. We don't get too many of these, around 20-30 a week.
What are other people doing with these messages?
Thanks. Andrew.
On 3/16/22 12:07, Andrew Hodgson wrote:
What I would ideally like is if we get a bounce from one of these confirmation mails we delete the user from the database but that is probably a future request. We don't get too many of these, around 20-30 a week.
Since you are already directing these to a mailbox, you could do a couple of things. You could instead pipe them to a command or via cron run a command which reads the mailbox. In either case, this command could use flufl.bounce <https://pypi.org/project/flufl.bounce/> to extract the bounced address from the email message and then do whatever your current process does to remove the user.
What are other people doing with these messages?
I basically do nothing.
The issue of more concern to me is when the subscription uses a deliverable address. The owner of that address receives this unwanted confirmation email which is bad enough, but then sometimes reports it as spam to her ISP which affects my server's reputation. But, so far, I don't do anything about that either.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Am 17.03.22 um 03:40 schrieb Mark Sapiro:
The issue of more concern to me is when the subscription uses a deliverable address. The owner of that address receives this unwanted confirmation email which is bad enough, but then sometimes reports it as spam to her ISP which affects my server's reputation. But, so far, I don't do anything about that either.
As I'm a mail admin for a server whose users get lots of those misguided mails I'd say that the vast majority of them are not from mailing list signups but from web contact forms which automatically respond to entered contact requests with "Dear Polly liked your profile https://bit.ly/crap". I regularly report these as spam and expect website owners to disable automatic mails from such forms (I also advise our users who have their own websites to disable that, and strictly filter it on outgoing mail).
I would probably also report these as spam when coming from mailing lists subscription requests, and I would likewise advise you to send subscription responses only after a moderator checks and releases the subscription request. It can still happen that you send out somethin to someone who didn't subscribe, but you should be able to reduce the numbers significantly. I know this causes extra moderator work because you don't get the automated pre-filtering for deliverable addresses, so this is something where you need to weigh pros and cons for your particular situation.
Cheers, Hans-Martin
On 3/16/22 23:27, Hans-Martin Mosner via Mailman-users wrote:
I would probably also report these as spam when coming from mailing lists subscription requests, and I would likewise advise you to send subscription responses only after a moderator checks and releases the subscription request.
This would require changes to Mailman in that even with subscription policy confirm and moderate, confirmation comes before moderation.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
This would require changes to Mailman in that even with subscription policy confirm and moderate, confirmation comes before moderation.
I can see that changing this would be unpopular with moderators on very active lists (or with lots of active lists), but maybe we should (a) offer the option to moderate first and (b) make it the default.
Mark, do you have any idea what the numbers are for unconfirmed subscription attempts vs. those that make it to the moderators for python.org and mailman3.org lists?
Steve
participants (4)
-
Andrew Hodgson -
Hans-Martin Mosner -
Mark Sapiro -
Stephen J. Turnbull