I'm trying to get PHPList 3.3.1 to process email bounces and to "unconfirm" or delete users based on email bounces to them. I have the following settings in my PHPList config file:
define ("MANUALLY_PROCESS_BOUNCES",1);
define('USE_ADVANCED_BOUNCEHANDLING',0);
$bounce_unsubscribe_threshold = 2;
I have "Processed Bounces" and PHPList dutifully reads the bounced emails, adds them to the database, and deletes the emails.
However, it doesn't seem to mark users as unsubscribed, even after 2 bounces.
Do I need to add advanced bounce rules? If so, can you provide me with a good basic list of rules to use?
I did try the "Generate Bounce Rules" option and it created 1100 rules (yes, one thousand one hundred rules) - yikes! Seems like there should be something like 5 or 10 rules that would cover most bounces.
Little help?
This is still a relatively undocumented part of phplist. We have a sophisticated list of regex expressions we use but currently not public.
I suggest you start here: PHPList Bounce Rules? to find expressions to track the kind of phrases you want to capture and also the doc itself includes some starting rules: https://www.phplist.org/manual/ch040_bounce-management.xhtml
What is not so documented, or I haven't found at least, is the differences between some of the actions you have available but with a bit of work and time you can fine tune based on your traffic and more important... your customers MTAs.
Further to this questions I started a thread on PHPlists forum than might be of help:
https://discuss.phplist.org/t/please-help-clarifying-advance-bounce-processing/4077/4
if you're still having difficulty with the rules. Be sure they are ACTIVE and not in the CANDIDATE section. Sometimes, with so many created rules the system won't let you just tag them all and change to ACTIVE as it freezes.
You can always go to your phplist database and use the following:
UPDATE `TABLEPREFIX_bounceregex` SET `status` = 'active'
Where TABLEPREFIX should be the same as yours. Hope it helps so many years later.
Consider, as well, installing the Housekeeping plugin » https://resources.phplist.com/plugin/housekeeping
Related
I am using MailKit as SMTP client to send emails.
I see there are two properties XMessagePriority and MessagePriority
what is the difference between these two and does one override the other?
One of the things you'll discover in the world of email is that there are legacy bits and pieces here and there.
This is one of those.
The original "email" specification did not specify a header for designating the priority of a message, so some mail clients began using a non-standard header called X-Priority (non-standard headers always start with X-). (Note: Microsoft products began using X-MSMail-Priority instead. There's some info about it here: https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/2bb19f1b-b35e-4966-b1cb-1afd044e83ab)
Later, many X.400 message properties were mapped to message headers, including a Priority header but the values were not the same as the ones used in the X-Priority header.
Once a piece of software begins doing something and users like/demand the feature, other software begins to adopt that way of doing something in order to compete. Then, once a real standard is defined, if it isn't identical the the way it was already being done, there are now 2 ways of doing the same thing and software must do both.
You might be thinking, "but doesn't that mean software has to implement both? And if they implement both, why not drop the old way?"
Because old software still exists out there that can only handle the old way of doing things, so in order to be compatible with that older software that may exist, the legacy way of doing things persists.
(And by "mail software", that includes more than mail clients like Outlook or official mail server software like Exchange - it also includes automated shell scripts that admins wrote decades ago that are probably still running because no one has ever bothered to update them if they even know that anything should be updated).
does one override the other?
Yes. No. It all depends on the implementation of the receiving mail software.
We have a lot of doubts concerning the changes in the Messenger Platform’s policies.
There is HUMAN_AGENT tag (for which we have already asked permission) which seems to be the one that adapts the most to our processes, but 7 days is still insufficient for us. Could we answer with this “message_tag” 20 days after a user message? What can we do in this case? We have to find a way not to leave the user without an answer.
We plan on using one of the above-mentioned CONFIRMED_EVENT_UPDATE to answer all user messages outside of the 24 hour window. Are there any penalties for us doing so? If there are, what are the penalties? Are they applied at the company level or the page level? None of the messages sent by our company contain what you want to avoid (spams, special offers, discounts, etc.) so we don’t think we should recieve any penalty even when using “message_tags”.
We have thought about using the normal answer and, if the “This message is sent outside of the allowed window” error message appears, we will answer using “message_tags”. Is there any problem for using the first call on a recurrent basis giving errors or should we avoid it? Avoiding it might cause to send unnecesary “message_tags”. Could we answer all private messages using HUMAN_AGENT when it is approved (our answers are always given by a customer service agent)?
Best regards
You do not mention your actual use case, so nobody can suggest any message tags that would match that use case.
Without knowing that use case the answer to your questions can only be:
1) There is no way to extend the 7 days window for human agent tag. If you get approved for it you have a 7 days windows, not 8 and not 20. However most user actions reset that window you should follow up within that window and and make sure the user engages with your bot so the window is reset and you have another 7 days for another update.
2) Abusing tags will most likely result in your page being restricted, make sure to only use them for the allowed use cases as listed in the docs: https://developers.facebook.com/docs/messenger-platform/send-messages/message-tags/
Over the past few months random email addresses, some of which are on known spam lists, have been added at the rate of 2 or 3 a day to my website.
I know they aren't real humans - for a start the website is in a very narrow geographical area, and many of these emails are clearly from a different country, others are info# addresses that appear to have been harvested from a website, rather than something a human would use to sign up to a site.
What I can't work out is, what are reasons for somebody doing this? I can't see any benefit to an external party beyond being vaguely destructive. (I don't want to link to the site here, it's just a textbox where you enter email and press join).
These emails are never verified - my question isn't about how to prevent this, but what are some valid reasons why somebody might do this. I think it's important to understand why malicious users do what they do.
This is probably a list bombing attack, which is definitely not valid. The only valid use I can think of is for security research, and that's a corner case.
List bomb
I suspect this is part of a list bombing attack, which is when somebody uses a tool or service to maliciously sign up a victim for as much junk email as possible. I work in anti-spam and have seen victims' perspectives on this: it's nearly all opt-in verifications, meaning the damage is only one per service. It sounds like you're in the Confirmed Opt-In (COI) camp, so congratulations, it could be worse.
We don't have good solutions for list bombing. There are too many problems to entertain a global database of hashed emails that have recently opted into lists (so list maintainers could look up an address, conclude it's being bombed, and refuse to invite). A global database of hashed emails opting out of bulk mail (like the US Do Not Call list or the now-defunct Blue Frog's Do Not Intrude registry but without the controversial DDoS-the-spammers portion) could theoretically work in this capacity, though there'd still be a lot of hurdles to clear.
At the moment, the best thing you can do is to rate-limit (which this attacker is savvy enough to avoid) and use captchas. You can measure your success based on the click rate of the links in your COI emails; if it's still low, you still have a problem.
In your particular case, asking the user to identify a region via drop-down, with no default, may give you an easy way to reject subscriptions or trigger more complex captchas.
If you're interested in a more research-driven approach, you could try to fingerprint the subscription requests and see if you can identify the tool (if it's client-run, and I believe most are) or the service (if it's cloud-run, in which case you can hopefully just blacklist a few CIDR ranges instead). Pay attention to requesters' HTTP headers, especially the referer. Browser fingerprinting it its own arms race; take a gander at the EFF's Panopticlick or Brian Kreb's piece on AntiDetect.
Security research
The only valid case I can consider, whose validity is debatable, is that of security research (which is my field). When I'm given a possible phishing link, I'm going to anonymize it. This means I'll enter fake data rather than reveal my source. I'd never intentionally go after a subscription mechanism (at least with an email I don't control), but I suppose automation could accidentally stumble into such a thing.
You can avoid that by requiring POST requests to subscribe. No (well-designed) subscription mechanism should accept GET requests or action links without parameters (though there are plenty that do). No (well-designed) web crawler, for search or archiving or security, should generate POST requests, at least without several controls to ensure it's acceptable (such as already concluding that it's a bad actor's site). I'm going to be generous and not call out any security vendors that I know do this.
I've got a significantly large mailing list - 50K+ subscribers. To avoid stressing my servers, I would like to avoid sending emails through a components embedded on my website. Sending through here sends the CPU usage through the roof - so I'd like to be able to send emails locally. I can easily send emails through mandrillapp, so sending the emails out is not a problem. However, I've hit a bit of a snag.
Phplist seems to assume it is living on a public site, and inserts tracking info which routes the users to a phplist directory on my site (which obviously) does not exist.
Question 1: First of all, I'd like to avoid embedding this tracking - is this possible? Or else is there someway to include it and avoid the 404 error. Would I have to install phplist anyway on the server?
Question 2: I've already got acymailing to handle unsubscribes, so is it actually possible to keep this in place - just to make sure the acymailing is still my point of reference?
Question 3: How do people handle sending out large mailing lists? I know CampaignMonitor, MailChimp etc, but these get a bit expensive for my situation. I'd like to keep sending "internally" so to speak. Is there an elegant solution which will NOT kill my server but is not too expensive? I know I want to have the cake and eat, but it would be nice to hear what people out there are doing.
TIA
David
Does anyone know a good tool to test whether your emails are going into spam folders?
My web app generates emails to users, and I've been getting a lot of reports back from people saying "hey, no one ever responded to my message".
I have SPF rules in place and functioning correctly (email header shows an spf pass). I've also run my message through spam assassin and it scores very low.
Any other ideas?
To know if your email goes in the inbox, you need to get a metric called "Inbox Placement Rate". This indicator can be provided by Return Path, but it's quite expensive. If you're not sending huge volumes it might not worth it. The only way to measure the IPR is actually to have a certain number of test inboxes... In other words: the only way to chech that your email is not in the spam folder is to make the test and see what happen. There is not other magic solution and that's what Return Path is doing.
This means that when you hear about people claiming they have a 99% deliverability / delivery, it might be true be it just means that the email was "accepted" or "delivered" by the ISP. It's a lot, but it's not everything!
What you should do is the following: use an ESP focusing on deliverability. Personally I work for Mailjet. I believe it's the best value you can get: personalized DKIM and SPF are provided for free, you get the antispam scorings, the analytics, Ip reputation monitoring, throttling, etc. It's an all in one tool to avoid the headaches of optimizing yourself. It's more expensive that Amazon SES because you get a lot of added value services, but it has much lower prices than a lot of traditional ESPs!
Bottom line is: optimizing everything yourself is a full time job. Knowing exactly if an email is in the inbox or not will cost you a lot. The best way to proceed is to:
respect the best practices (opt in, not too much images, no red, etc.)
get some metrics such as open rates, click rates, delivery, etc. and watch their evolution over time. Any change from one sending to the other might be a signal for a problem you want to investigate.
Use a tool that takes care all the deliverability optimizations
Mailjet is cool because no matter which plan you pick, you get to use all the options. But if you want a full overview of what is existing, check out this comparison table:
http://socialcompare.com/en/comparison/transactional-emailing-providers-mailjet-sendgrid-critsend
If you're a perfectionist who wants to finetune the layout, how the emails are displayed etc. Check out Litmus, it's also a quite powerful tool!
http://litmus.com/
Simple answer: Use Mailgun!!!!
http://mailgun.net/
They will do all of your email deliverability and setup for you and give you a powerful API to build on! They are amazing. You'll never have to worry about domain keys or SPAM filtering again!
You should also check that your IP is not on any of major blacklists. dnsbl.info
This will at least give you an idea if you actually are getting flagged as spam.
For the past two years, we've used the service DeliveryMonitor.com. However, they've stopped accepting new applications which is a big red flag...
I'm currently evaluating the service from emailreach.com using their free trial
... We are now using DeliveryWatch.com with pertty good results thus far...