Sorry for the delay... Yes, it is certainly possible the follow-up might get thrown in the spam folder.
I would strongly suggest it come from an IP that was pretty much reserved for sign up confirmations, transactional emails and such like so that the traffic would be considered transactional. If there is ever a dispute, that fact will argue strongly in favor of Mitigation. I gather there are things in place to notice that class of mail, but I am not an expert into all the things that HotMail uses to grade mail. Above all else I would say this: If you are sending your recipients invoices and such like, you should say up at the top of the email, in bold letters, "Please add us to your Safe Sender list to ensure uninterrupted delivery." Or words to that effect. If the recipient has the sender in their Safe Sender list, at least in the Hotmail system, it should *NEVER* be going to Junk, and *THAT* builds rep far faster than just about anything else. Good luck! Aloha, Michael. -- Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been Processed." | Got the Junk Mail Reporting Tool ? -----Original Message----- From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of rich...@flowmailer.com Sent: Thursday, July 28, 2016 12:08 AM To: mailop@mailop.org Subject: Re: [mailop] Microsoft Junk Mail Reporting Program Hi Michael, thanks for your input. The challenge our customers face is that it's a really difficult process (and costly) to explain when they need reach out to their recipients by phone about a FBL. Often they have no choice because they really need to get their invoices (or something else that's important) delivered, and we tell them the deliverability trade off is worth the extra effort. Your suggestion opens up the possibility of (in part) automating that process by sending a confirmation message that would allow that customer to regain access some of those recipients. If effective, that would be great! Since, as far as we know, no one is is doing this yet, we do have some doubts that you may be able to help with: - Wouldn't the confirmation/follow-up email just get thrown in the Spam folder, severely reducing effectiveness? - Wouldn't sending another message after getting the FBL negatively impact the senders' reputation? It would be great to hear more of your thoughts on such a process! On 2016-07-27 21:45, Michael Wise via mailop wrote: > My top of mind suggestions on what might be a good idea to avoid > trouble (getting your traffic auto-Junked, or your IPs blocked) might > include the following, for what it's worth: > > If you get a sample from any FBL, for a given recipient, you should > make sure that you can figure out who it is, probably best to use a > token in the body of the message, and ... you should fire off an email > to that customer asking them if they wish to continue receiving > mailings, with a "Yes" button (and some automatic logic to detect some > AI that clicks all buttons), and only if they do in fact click, "Yes" > do you continue to send traffic. > > If they go more than a week without opening an email, switch them to > monthly. > If they go more than a month without opening, send them a, "Do you > want to continue?" email and wait. > And if traffic to a recipient ever bounces (except for 400 or 500 > refusal codes that do NOT implicate IP reputation), queue up a, "Do > you want to continue?" email, but hold it for ... at least a day? And > suspend all other deliveries to that recipient. > > Y'all might want to save up all the 4xx and 5xx codes, and sort 'em > and look over them manually at the end of day, just to be sure > something hasn't gone pear-shaped. I suspect the really big senders do > it in Real Time. As a matter of fact, I know they do. > > ... > > Some of the above is officially, "Hard". > But it would be, IMHO, Best List Management Practices. > > Aloha, > Michael. > -- > Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has > Been Processed." | Got the Junk Mail Reporting Tool ? > > -----Original Message----- > From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of > rich...@flowmailer.com > Sent: Wednesday, July 27, 2016 2:22 AM > To: mailop@mailop.org > Subject: Re: [mailop] Microsoft Junk Mail Reporting Program > > Handling FBL -although we appreciate the effort- has been a pain for > us as well. Our customers and their recipients are also usually > unaware of what's going on when they use the Junk button as a quick > delete option. > We block those FBL reported recipients, but that leads to many > questions, especially with our more diligent customers that actually > give those recipients a call to discuss the matter. > > We send many transactional messages from legitimate companies that end > up not being able to reach those recipients by e-mail because of this. > It would be nice if some large inbox providers could comment on how > they think this should be handled? > > Richard van Looijen > > On 2016-07-27 10:55, Mark Milhollan wrote: >> On Wed, 27 Jul 2016, Craig Marchant wrote: >> >>> I've got no issue with people reporting spam - it just seems like >>> that "this is spam" button makes it a little too easy for end users >>> to take absolutely zero responsibility for legitimate mailing list >>> subscriptions and in the process getting other legitimate senders / >>> mail servers in trouble because of it. It's a hard line to walk >>> either way I realise. >> >> And worse, the button isn't labelled "this is spam" nor even "report >> as spam", merely "Junk" which doesn't seem quite the same in the mind >> of the general public -- they received a message they don't feel they >> needed or are now done reading. Still even where it says SPAM!!! >> people >> seem to use it because often it makes the message go away quickly >> with no confirmation unlike the delete button or from having just >> used it to nuke the 3 previous messages which were (friendly fire, so >> to speak). >> >> >> /mark >> >> _______________________________________________ >> mailop mailing list >> mailop@mailop.org >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchil >> l >> i.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop&data=02%7c01%7 >> c >> michael.wise%40microsoft.com%7c34dec559d87b494a496108d3b6001df0%7c72f >> 9 >> 88bf86f141af91ab2d7cd011db47%7c1%7c0%7c636052084031518845&sdata=nfAeS >> J xWKbo4yUg%2fInNuOjQeSuIoEJQcnwo4lj7g0FY%3d > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchill > i.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop&data=02%7c01%7c > michael.wise%40microsoft.com%7c34dec559d87b494a496108d3b6001df0%7c72f9 > 88bf86f141af91ab2d7cd011db47%7c1%7c0%7c636052084031518845&sdata=nfAeSJ > xWKbo4yUg%2fInNuOjQeSuIoEJQcnwo4lj7g0FY%3d > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchill > i.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop&data=02%7c01%7c > michael.wise%40microsoft.com%7cc675e740bf194e84905708d3b6b76e44%7c72f9 > 88bf86f141af91ab2d7cd011db47%7c1%7c0%7c636052871368310956&sdata=jzAbqH > Mx9bv7cvOaBhXJWq1DHzO9PLVTS44V3Bf2ojU%3d _______________________________________________ mailop mailing list mailop@mailop.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop&data=02%7c01%7cmichael.wise%40microsoft.com%7cc675e740bf194e84905708d3b6b76e44%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636052871368310956&sdata=jzAbqHMx9bv7cvOaBhXJWq1DHzO9PLVTS44V3Bf2ojU%3d _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
