Re: [mailop] Howto be a good mailop (best practice / insights wanted)
Hi Ken, yes - thank you. I will then go with Complaints-To: ab...@address.here - even though havent seen this header in the wild anywhere so far. Stefan -Ursprüngliche Nachricht- Von: Ken O'Driscoll via mailop Gesendet: Freitag 31 Mai 2019 13:55 An: mailop@mailop.org Betreff: Re: [mailop] Howto be a good mailop (best practice / insights wanted) On Fri, 2019-05-31 at 11:03 +, Stefan Bauer via mailop wrote: > Hi Ken, > > thanks again for your input. Regarding > Add a custom header (X-abuse) > > is this really a thing? Could not find many mails in my inbox with that > header present at all nor any official recommendations about that. > Stefan Hi Stefan, Yes, it is fairly popular with ESPs (X-Report-Abuse, X-Complaints-To are fairly common sights). Also web hosting providers and commercial SMTP services (like you) tend to add a few custom headers to identify specific subscribers. It's not universal by any means but I'd recommend it for the service you're offering. And, to to be fair, RFC 6648 (which is a best practice not a standard) depreciates the use of the "X-" prefix in favour of general meaningful custom headers (e.g. Complaints-To) so doing that is probably better. Does that answer your question? Ken. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
On Fri, 2019-05-31 at 11:03 +, Stefan Bauer via mailop wrote: > Hi Ken, > > thanks again for your input. Regarding > Add a custom header (X-abuse) > > is this really a thing? Could not find many mails in my inbox with that > header present at all nor any official recommendations about that. > Stefan Hi Stefan, Yes, it is fairly popular with ESPs (X-Report-Abuse, X-Complaints-To are fairly common sights). Also web hosting providers and commercial SMTP services (like you) tend to add a few custom headers to identify specific subscribers. It's not universal by any means but I'd recommend it for the service you're offering. And, to to be fair, RFC 6648 (which is a best practice not a standard) depreciates the use of the "X-" prefix in favour of general meaningful custom headers (e.g. Complaints-To) so doing that is probably better. Does that answer your question? Ken. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
Hi Ken, thanks again for your input. Regarding Add a custom header (X-abuse) is this really a thing? Could not find many mails in my inbox with that header present at all nor any official recommendations about that. Stefan -Ursprüngliche Nachricht- Von: Ken O'Driscoll via mailop Gesendet: Mittwoch 8 Mai 2019 20:01 An: mailop@mailop.org Betreff: Re: [mailop] Howto be a good mailop (best practice / insights wanted) On Wed, 2019-05-08 at 16:45 +, Stefan Bauer via mailop wrote: > we have in place: > > only allow pre-defined sender-addresses after auth > monitor mail-queues for high connection count > monitor RBLs if we're listed > only allow single mail / 5s to be sent outgoing > anti-virus checking of attachments Hi Stefan, off the top of my head I would add: * Monitor abuse@ and make sure that this address a) exists for your client domains and b) you receive a copy of messages sent to them. * Restrict access to the submission port to either the client IP range. * Lock accounts after X failed logins and get an alert about that. * Have a third (failover/fallback) sending capability with a different data centre. Periodically route enough email though that to ensure that it will not be throttled in case you need it. But, don't use it as a primary. * Understand what your normal usage profile looks like - graph the mail queues. This will help you build policies / tech. around detecting unusual behaviour. E.g. tougher throttling outside of business hours etc. * Add a custom header (X-abuse) to make it clear where the email came from and how to report abuse of your service. * Make it clear on your website how a non-customer can contact you to report abuse. * Run a cut-down spam filter on the outbound mails (look for stuff like freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of that will be false positives so just put it into a holding queue and create a service desk ticket for it to be reviewed. * Have a clear upgrade path if case they wish to send marketing emails. If you don't, they will just try to send them through your platform. * Publish an Acceptable Use Policy (AUP) and make them agree to it as a pre-condition to using your service. Spamhaus have a good template to start from on their website. * Monitor bounces and tie that it with your monitor solution. * Monitor the health of your clients connecting IPs (and possibly website). Any indication of a compromised site is grounds for locking the account until a human can review. There is likely more, above is, as I said, off the top of my head. Good luck. Ken. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
On 2019-05-10 4:21 a.m., Laura Atkins via mailop wrote: You don’t need to separate your transactional and your marketing mail on different IPs because the filters aren’t using IPs as the unique mail identifier. I would suggest that you 'might' have a point when it comes to the bigger players, but most of the rest of the world still relies heavily on IP reputation. We would suggest that transactional email ALWAYS be from different IP(s) than your transactional email.. mixing transactional email with marketing, while on the surface might be attractive to those sending marketing through the same IP(s) to benefit from the favoured status transactional email usually receives, in the end it may affect your ability to deliver transactional email. ALWAYS separating those two types should be a 'best practice' and of course naming the PTR's clearly to show which is transactional and which isn't will help ensure that your transactional mail always gets preferred treatment. -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
> On 10 May 2019, at 14:11, Leo Gaspard via mailop wrote: > > Steve Atkins via mailop writes: >>> On May 10, 2019, at 10:50 AM, Leo Gaspard via mailop >>> wrote: >>> Laura Atkins via mailop writes: For victims of listbombing, COI isn’t an answer. In fact, much of the problem with listbombing is COI mail. How do you propose to address that issue? >>> >>> Captchas are a way to force the malicious subscriber to spend human or >>> computer time breaking it (if captchas can be broken). >>> >>> As a consequence, it might make sense to just accept it is the case and >>> require a javascript-generated proof of work before accepting the >>> subscription. >>> >>> This way the amount of computer time required can be more easily >>> modulated, and the human is not faced with a hard-to-answer captcha -- I >>> don't know how you feel, but as a user I'd much rather have my computer >>> spin for a few tens of seconds before sending the form (especially as it >>> can happen at the same time as I fill it) than have to fill in a >>> captcha. >> >> Bad people have access to much more, and much cheaper, compute resource >> than good people. >> >> There are other things wrong with your suggestion but that's >> a simple thing to think about first. It also generalizes to many other >> poorly thought through "just use proof of work to solve email problems!" >> ramblings. > > I hope you didn't assume I was saying it's a good idea. I was *only* > saying it was a better idea than captchas, as an answer to Laura's > question. You need to work a lot harder than that to convince me that using javascript generated proof of work is a somehow more appealing and effective than captchas. laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
Steve Atkins via mailop writes: >> On May 10, 2019, at 10:50 AM, Leo Gaspard via mailop >> wrote: >> Laura Atkins via mailop writes: >>> For victims of listbombing, COI isn’t an answer. In fact, much of the >>> problem with listbombing is COI mail. >>> >>> How do you propose to address that issue? >> >> Captchas are a way to force the malicious subscriber to spend human or >> computer time breaking it (if captchas can be broken). >> >> As a consequence, it might make sense to just accept it is the case and >> require a javascript-generated proof of work before accepting the >> subscription. >> >> This way the amount of computer time required can be more easily >> modulated, and the human is not faced with a hard-to-answer captcha -- I >> don't know how you feel, but as a user I'd much rather have my computer >> spin for a few tens of seconds before sending the form (especially as it >> can happen at the same time as I fill it) than have to fill in a >> captcha. > > Bad people have access to much more, and much cheaper, compute resource > than good people. > > There are other things wrong with your suggestion but that's > a simple thing to think about first. It also generalizes to many other > poorly thought through "just use proof of work to solve email problems!" > ramblings. I hope you didn't assume I was saying it's a good idea. I was *only* saying it was a better idea than captchas, as an answer to Laura's question. And I stand by this statement: the effect on bad people is approximately the same as the one captchas have (well… maybe a bit less efficient when the captcha is strong enough for requiring a captcha relaying attack? but I'm used to failing answering those captchas as a human too anyway, so might as well have a 10min proof of work…), and the effects on good people are much, much less painful than the ones captcha have. Basically, captchas are a POW for malicious actors, and a dice the user rolls for the normal user. When computers were unable to do basic OCR, they were a good idea. Nowadays, the user gets more pain than the malicious actors, for whom even 1/10 success rate is enough to get lots of forms through without questions. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
> On 10 May 2019, at 11:40, Michael Wise via mailop wrote: > > > The solution ... is to stop thinking that all decisions on the legitimacy of > an email can be resolved at the instant the machine is focusing on that one > email. > > We need to move beyond "Spam" filtering as a one-off, per message task and > start working more actively on techniques of campaign detection, both > outbound, as well as Inbound. And that requires noticing patterns of good > behavior going over a line and becoming abusive. I’ve been thinking about this a lot. All the modern consumer filters (and the business ones) are actually really good at separating out mailstreams. You don’t need to separate your transactional and your marketing mail on different IPs because the filters aren’t using IPs as the unique mail identifier. They can identify streams. Yahoo’s been able to very effectively separate out streams for almost a decade - and everything I’m seeing from the shared Verizon Media infrastructure says that bit of the filters were kept during the rebuild. Google is incredibly good at it as well and even different marketing streams with the same d= will be filtered differently - even if it’s just “updates” vs. “promotions” tab. Microsoft is a bit of an outlier in that they still seem to put a lot of emphasis on IP address reputation more than domain reputation, but even then I think they are more flexible on the back end and look at content (and recipient pools) than some senders believe. I actually wrote about this last month: https://wordtothewise.com/2019/04/gmail-suddenly-puts-mail-in-the-bulk-folder/ “They measure mailstreams over time, they don’t measure individual sends.” The Yahoo evidence was a client was sending content and marketing to the same COI list over the same IP with all the same domain authentication. Yahoo was putting the content (wanted) in the inbox and the marketing (eh… who cares) into bulk. Even Return Path certification of the IP wasn’t enough to get the marketing into the inbox. This was a client from ’11 or ’12? Quite a while ago, anyway. The Google evidence is more recent. I was reviewing google postmaster tools data with a client. This client didn’t include a FBL identifier in their email, but Google “discovered” one anyway - something like v1 or L3 or something. When asked the client says “Oh, that’s the name of the customer segment we’re sending to.” Basically, from the emails coming in, Google was able to discern that this segment was different than other segments and correctly assign a FBL rate to that particular segment. The consumer ISPs can clearly identify mailstreams already. laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
The solution ... is to stop thinking that all decisions on the legitimacy of an email can be resolved at the instant the machine is focusing on that one email. We need to move beyond "Spam" filtering as a one-off, per message task and start working more actively on techniques of campaign detection, both outbound, as well as Inbound. And that requires noticing patterns of good behavior going over a line and becoming abusive. Aloha, Michael. -- Michael J Wise Microsoft Corporation| Spam Analysis "Your Spam Specimen Has Been Processed." Got the Junk Mail Reporting Tool ? -Original Message- From: mailop On Behalf Of Steve Atkins via mailop Sent: Friday, May 10, 2019 3:20 AM To: Chris Adams via mailop Subject: Re: [mailop] Howto be a good mailop (best practice / insights wanted) > On May 10, 2019, at 10:50 AM, Leo Gaspard via mailop > wrote: > > Laura Atkins via mailop writes: >> For victims of listbombing, COI isn’t an answer. In fact, much of the >> problem with listbombing is COI mail. >> >> How do you propose to address that issue? > > Captchas are a way to force the malicious subscriber to spend human or > computer time breaking it (if captchas can be broken). > > As a consequence, it might make sense to just accept it is the case > and require a javascript-generated proof of work before accepting the > subscription. > > This way the amount of computer time required can be more easily > modulated, and the human is not faced with a hard-to-answer captcha -- > I don't know how you feel, but as a user I'd much rather have my > computer spin for a few tens of seconds before sending the form > (especially as it can happen at the same time as I fill it) than have > to fill in a captcha. Bad people have access to much more, and much cheaper, compute resource than good people. There are other things wrong with your suggestion but that's a simple thing to think about first. It also generalizes to many other poorly thought through "just use proof of work to solve email problems!" ramblings. Cheers, Steve ___ mailop mailing list mailop@mailop.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%7C01%7Cmichael.wise%40microsoft.com%7Ca8ed02d09fec4f9fd7de08d6d531f2fd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930807838197968sdata=8fwJY13wy5U0T4nUPRlB%2BuxgPf9G8wITCAzA%2FrI6%2BhE%3Dreserved=0 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
> On May 10, 2019, at 10:50 AM, Leo Gaspard via mailop > wrote: > > Laura Atkins via mailop writes: >> For victims of listbombing, COI isn’t an answer. In fact, much of the >> problem with listbombing is COI mail. >> >> How do you propose to address that issue? > > Captchas are a way to force the malicious subscriber to spend human or > computer time breaking it (if captchas can be broken). > > As a consequence, it might make sense to just accept it is the case and > require a javascript-generated proof of work before accepting the > subscription. > > This way the amount of computer time required can be more easily > modulated, and the human is not faced with a hard-to-answer captcha -- I > don't know how you feel, but as a user I'd much rather have my computer > spin for a few tens of seconds before sending the form (especially as it > can happen at the same time as I fill it) than have to fill in a > captcha. Bad people have access to much more, and much cheaper, compute resource than good people. There are other things wrong with your suggestion but that's a simple thing to think about first. It also generalizes to many other poorly thought through "just use proof of work to solve email problems!" ramblings. Cheers, Steve ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
Laura Atkins via mailop writes: > For victims of listbombing, COI isn’t an answer. In fact, much of the problem > with listbombing is COI mail. > > How do you propose to address that issue? Captchas are a way to force the malicious subscriber to spend human or computer time breaking it (if captchas can be broken). As a consequence, it might make sense to just accept it is the case and require a javascript-generated proof of work before accepting the subscription. This way the amount of computer time required can be more easily modulated, and the human is not faced with a hard-to-answer captcha -- I don't know how you feel, but as a user I'd much rather have my computer spin for a few tens of seconds before sending the form (especially as it can happen at the same time as I fill it) than have to fill in a captcha. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
Captchas aren’t a FUSSUP. They’re meant to address a specific problem - listbombing. COI contributes to the problem of listbombing. SMS challenge is going to make that worse. 1000 SMS messages in an hour is a problem. There are people who’ve been working on this issue for years and I’m sure they’d be very happy to hear your contributions and alternative solutions. In fact, I hear a conference is actively looking for contributors who have experience with listbombing (victim, ESPs, other victim, ISP) to work on the issue. laura > On 9 May 2019, at 23:10, Michael Wise via mailop wrote: > > > My replies keep going to the original author. Grr. > > Anyway, yeah, completely agree. > Y’all who trumpet CAPTCHA as the FUSSP need to know who’s on the opposing > team: > > http://scraping.pro/8-best-captcha-solving-services-and-tools/ > <http://scraping.pro/8-best-captcha-solving-services-and-tools/> > > You’re going to need to think about an SMS challenge as a basic, entry level > requirement. > > Aloha, > Michael. > -- > Michael J Wise > Microsoft Corporation| Spam Analysis > "Your Spam Specimen Has Been Processed." > Got the Junk Mail Reporting Tool > <http://www.microsoft.com/en-us/download/details.aspx?id=18275> ? > > -Original Message- > From: mailop mailto:mailop-boun...@mailop.org>> > On Behalf Of Rich Kulawiec via mailop > Sent: Thursday, May 9, 2019 2:54 PM > To: mailop@mailop.org <mailto:mailop@mailop.org> > Subject: Re: [mailop] Howto be a good mailop (best practice / insights wanted) > > On Thu, May 09, 2019 at 09:26:50AM -0400, Rob McEwen via mailop wrote: > > you should strongly encourage your customers to captcha-protect their > > signup forms to prevent bots from signing up spamtrap addresses. > > No, you shouldn't. I'm going to quote something that I just sent elsewhere, > so my apologies to anyone who's seen it. > > > Captchas are a worst practice. They can be and are defeated at will by any > adversary who can trouble themselves to do so. [1] They're security theater: > think Wile E. Coyote holding an umbrella over his head while a boulder drops > toward him. [2] Worth noting as well are (a) the continued and accelerating > convergence of the trend lines denoting "captcha hard enough to defeat > automation" > and "captcha easy enough to be solvable by humans" and (b) the onerous > additional burden that these often place on people who have diminished > eyesight and hearing, who are part of different cultures, etc. > > There are far better ways to defend resources, and -- judiciously deployed -- > these methods are not nearly as susceptible to adversarial manipulation, nor > do they make life more difficult for people whose lives are arguably > difficult enough already. > > ---rsk > > [1] Here's an example of what I mean by "defeated at will": > Wiseguys Indicted in $25 Million Online Ticket Ring | Threat > Level | Wired.com <http://wired.com/> > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wired.com%2Fthreatlevel%2F2010%2F03%2Fwiseguys-indicted%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=nQA9YpkXlpMYs0d5qI7vvtPMoP%2B%2BUY7xsQuXOiZ7jp8%3Dreserved=0 > > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wired.com%2Fthreatlevel%2F2010%2F03%2Fwiseguys-indicted%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=nQA9YpkXlpMYs0d5qI7vvtPMoP%2B%2BUY7xsQuXOiZ7jp8%3Dreserved=0> > > > [2] A partial list of references follows. Do note that the contemporary > state of the art in captcha-defeating techniques is much more advanced than > any of these suggest. Of course it is: attacks always get better - they > never get worse. (h/t to Bruce Schneier) > > Also, there's plenty of funding -- see footnote [1] above -- available to > support research and development in this area that will NOT be helpfully > published in blogs or journals. So consider what is enumerated below as the > lower bound of what *was* possible and extrapolate markedly upwards to > estimate what *is* currently available. > > Stanford researchers outsmart captcha codes > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.physorg.com%2Fnews%2F2011-11-stanford-outsmart-captcha-codes.htmldata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
> On 9 May 2019, at 22:53, Rich Kulawiec via mailop wrote: > > On Thu, May 09, 2019 at 09:26:50AM -0400, Rob McEwen via mailop wrote: >> you should strongly encourage your customers to >> captcha-protect their signup forms to prevent bots from signing up spamtrap >> addresses. > > No, you shouldn't. I'm going to quote something that I just sent > elsewhere, so my apologies to anyone who's seen it. > > > Captchas are a worst practice. So what is your solution? For victims of listbombing, COI isn’t an answer. In fact, much of the problem with listbombing is COI mail. How do you propose to address that issue? lauar Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
No, you didn’t. Point taken.
But nowadays, CAPTCHAs are pointless.
Find another way.
If only because something ELSE will force them to write custom code.
Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?
From: mailop On Behalf Of Rob McEwen via mailop
Sent: Thursday, May 9, 2019 4:20 PM
To: mailop@mailop.org
Subject: Re: [mailop] Howto be a good mailop (best practice / insights wanted)
I never claimed that CAPTCHA is FUSSP - it isn't. ("strawman's arg") And I
realize that CAPTCHA can be defeated. That part wasn't news to me.
HOWEVER:
(1) never let the quest for perfection get in the way of achievable incremental
improvements (which is EXACTLY what Rich and Michael are doing!)
(2) just because a criminal or spammer *can* do something - doesn't mean that
it is feasible or easy or economical for them to deploy that strategy
EVERYWHERE - which is what their arguments against CAPTCHA-protecting forms
require.
(3) NOT every web form or "lead magnet" page is a big target. For every one
such form on a large Fortune 100 company's site (like what Michael has to deal
with) - for every one such high-profile form - there are literally hundreds of
thousands of web forms on small sole proprietor's web sites and other small and
medium-sized businesses' web sites. In MOST of the instances where a bot does
submissions to their forms, the botmaster is simply not going to consider it
worth the cost/effort to try to defeat CAPTCHA, should that be added.
(4) Many of those SAME organizations are going to find adding CAPTCHA their
webform - to be relatively easy and within their budget or within their
internal technical abilities. SMS... not so much. And many automated SMS
implementation are costly - often costing about 10K/year just to get onboard
("let them eat cake" - is how this is starting to come across... I'm sure that
is chump changes to many of you reading this - but for many "mom and pop"
companies running "lead magnets" web forms for their small-ish ecommerce
business - that is NOT affordable.)
(5) meanwhile, a massive percentage of sites are doing NONE of this. It would
be better for them to do CAPTCHA than nothing. Even though CAPTCHA can be
defeated, most of those sites are visible enough to have their forms attacked
by bots, but likely too small for a spammer or hacker to find it worth their
time to use CAPTCHA-defeating techniques on them.
(Plus - when I brought this up - I was originally referring to signup forms -
not login forms. I think that point got confused, too.)
Rob McEwen
On 5/9/2019 6:10 PM, Michael Wise via mailop wrote:
Y’all who trumpet CAPTCHA as the FUSSP need to know who’s on the opposing team:
http://scraping.pro/8-best-captcha-solving-services-and-tools/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fscraping.pro%2F8-best-captcha-solving-services-and-tools%2F=02%7C01%7Cmichael.wise%40microsoft.com%7C7ab56938eee7459e755908d6d4d62a08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930413629468295=yn6tTXeqQEhCt92AUDWCNPuXTWuKsDhoqpmhf7yTIUQ%3D=0>
You’re going to need to think about an SMS challenge as a basic, entry level
requirement.
-AND-
On 5/9/2019 5:53 PM, Rich Kulawiec via mailop wrote:
No, you shouldn't. I'm going to quote something that I just sent
elsewhere, so my apologies to anyone who's seen it.
Captchas are a worst practice.
--
Rob McEwen
https://www.invaluement.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.invaluement.com=02%7C01%7Cmichael.wise%40microsoft.com%7C7ab56938eee7459e755908d6d4d62a08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930413629478305=ylIWAwjYV52%2Bve%2BKvdWLPsQ2MBEAjzaz4Dq%2BGhoFtuk%3D=0>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
I never claimed that CAPTCHA is FUSSP - it isn't. ("strawman's arg") And
I realize that CAPTCHA can be defeated. That part wasn't news to me.
HOWEVER:
(1) never let the quest for perfection get in the way of achievable
incremental improvements (which is EXACTLY what Rich and Michael are doing!)
(2) just because a criminal or spammer *can* do something - doesn't mean
that it is feasible or easy or economical for them to deploy that
strategy EVERYWHERE - which is what their arguments against
CAPTCHA-protecting forms require.
(3) NOT every web form or "lead magnet" page is a big target. For every
one such form on a large Fortune 100 company's site (like what Michael
has to deal with) - for every one such high-profile form - there are
literally hundreds of thousands of web forms on small sole proprietor's
web sites and other small and medium-sized businesses' web sites. In
MOST of the instances where a bot does submissions to their forms, the
botmaster is simply not going to consider it worth the cost/effort to
try to defeat CAPTCHA, should that be added.
(4) Many of those SAME organizations are going to find adding CAPTCHA
their webform - to be relatively easy and within their budget or within
their internal technical abilities. SMS... not so much. And many
automated SMS implementation are costly - often costing about 10K/year
just to get onboard ("let them eat cake" - is how this is starting to
come across... I'm sure that is chump changes to many of you reading
this - but for many "mom and pop" companies running "lead magnets" web
forms for their small-ish ecommerce business - that is NOT affordable.)
(5) meanwhile, a massive percentage of sites are doing NONE of this. It
would be better for them to do CAPTCHA than nothing. Even though CAPTCHA
can be defeated, most of those sites are visible enough to have their
forms attacked by bots, but likely too small for a spammer or hacker to
find it worth their time to use CAPTCHA-defeating techniques on them.
(Plus - when I brought this up - I was originally referring to signup
forms - not login forms. I think that point got confused, too.)
Rob McEwen
On 5/9/2019 6:10 PM, Michael Wise via mailop wrote:
Y’all who trumpet CAPTCHA as the FUSSP need to know who’s on the
opposing team:
http://scraping.pro/8-best-captcha-solving-services-and-tools/
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
My replies keep going to the original author. Grr. Anyway, yeah, completely agree. Y’all who trumpet CAPTCHA as the FUSSP need to know who’s on the opposing team: http://scraping.pro/8-best-captcha-solving-services-and-tools/ You’re going to need to think about an SMS challenge as a basic, entry level requirement. Aloha, Michael. -- Michael J Wise Microsoft Corporation| Spam Analysis "Your Spam Specimen Has Been Processed." Got the Junk Mail Reporting Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ? -Original Message- From: mailop On Behalf Of Rich Kulawiec via mailop Sent: Thursday, May 9, 2019 2:54 PM To: mailop@mailop.org Subject: Re: [mailop] Howto be a good mailop (best practice / insights wanted) On Thu, May 09, 2019 at 09:26:50AM -0400, Rob McEwen via mailop wrote: > you should strongly encourage your customers to captcha-protect their > signup forms to prevent bots from signing up spamtrap addresses. No, you shouldn't. I'm going to quote something that I just sent elsewhere, so my apologies to anyone who's seen it. Captchas are a worst practice. They can be and are defeated at will by any adversary who can trouble themselves to do so. [1] They're security theater: think Wile E. Coyote holding an umbrella over his head while a boulder drops toward him. [2] Worth noting as well are (a) the continued and accelerating convergence of the trend lines denoting "captcha hard enough to defeat automation" and "captcha easy enough to be solvable by humans" and (b) the onerous additional burden that these often place on people who have diminished eyesight and hearing, who are part of different cultures, etc. There are far better ways to defend resources, and -- judiciously deployed -- these methods are not nearly as susceptible to adversarial manipulation, nor do they make life more difficult for people whose lives are arguably difficult enough already. ---rsk [1] Here's an example of what I mean by "defeated at will": Wiseguys Indicted in $25 Million Online Ticket Ring | Threat Level | Wired.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wired.com%2Fthreatlevel%2F2010%2F03%2Fwiseguys-indicted%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=nQA9YpkXlpMYs0d5qI7vvtPMoP%2B%2BUY7xsQuXOiZ7jp8%3Dreserved=0 [2] A partial list of references follows. Do note that the contemporary state of the art in captcha-defeating techniques is much more advanced than any of these suggest. Of course it is: attacks always get better - they never get worse. (h/t to Bruce Schneier) Also, there's plenty of funding -- see footnote [1] above -- available to support research and development in this area that will NOT be helpfully published in blogs or journals. So consider what is enumerated below as the lower bound of what *was* possible and extrapolate markedly upwards to estimate what *is* currently available. Stanford researchers outsmart captcha codes https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.physorg.com%2Fnews%2F2011-11-stanford-outsmart-captcha-codes.htmldata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=AO%2BhAUVSgXsSsnB%2Bg29mpZB5v0V52YaCIUWolM%2B0x%2B8%3Dreserved=0 CIntruder: pentesting tool to bypass captchas https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcintruder.sourceforge.net%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=PrdAVLPG3OW7hwZsctUKvPTqHevEbT4SM354e5Iif%2Bw%3Dreserved=0 How a trio of hackers brought Google's reCAPTCHA to its knees | Ars Technica https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Farstechnica.com%2Fsecurity%2F2012%2F05%2Fgoogle-recaptcha-brought-to-its-knees%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=etl0tN7yv86ABF1kVR2jITgY%2Fh7neRxTptqzKXQ38Ls%3Dreserved=0 Snapchat Account Registration CAPTCHA Defeated - Slashdot https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fit.slashdot.org%2Fstory%2F14%2F01%2F23%2F2037201%2Fsnapchat-account-registration-captcha-defeateddata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=FtdQqZUTvTohCo5bBdD5n9Wd0BQTtbDCtmK5tOMNp%2Fg%3Dreserved=0 Gone in 60 seconds: Spambot cracks Live Hotmail CAPTCHA https://nam06.safelinks.protection.outlook.com
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
On Thu, May 09, 2019 at 09:26:50AM -0400, Rob McEwen via mailop wrote: > you should strongly encourage your customers to > captcha-protect their signup forms to prevent bots from signing up spamtrap > addresses. No, you shouldn't. I'm going to quote something that I just sent elsewhere, so my apologies to anyone who's seen it. Captchas are a worst practice. They can be and are defeated at will by any adversary who can trouble themselves to do so. [1] They're security theater: think Wile E. Coyote holding an umbrella over his head while a boulder drops toward him. [2] Worth noting as well are (a) the continued and accelerating convergence of the trend lines denoting "captcha hard enough to defeat automation" and "captcha easy enough to be solvable by humans" and (b) the onerous additional burden that these often place on people who have diminished eyesight and hearing, who are part of different cultures, etc. There are far better ways to defend resources, and -- judiciously deployed -- these methods are not nearly as susceptible to adversarial manipulation, nor do they make life more difficult for people whose lives are arguably difficult enough already. ---rsk [1] Here's an example of what I mean by "defeated at will": Wiseguys Indicted in $25 Million Online Ticket Ring | Threat Level | Wired.com http://www.wired.com/threatlevel/2010/03/wiseguys-indicted/ [2] A partial list of references follows. Do note that the contemporary state of the art in captcha-defeating techniques is much more advanced than any of these suggest. Of course it is: attacks always get better - they never get worse. (h/t to Bruce Schneier) Also, there's plenty of funding -- see footnote [1] above -- available to support research and development in this area that will NOT be helpfully published in blogs or journals. So consider what is enumerated below as the lower bound of what *was* possible and extrapolate markedly upwards to estimate what *is* currently available. Stanford researchers outsmart captcha codes http://www.physorg.com/news/2011-11-stanford-outsmart-captcha-codes.html CIntruder: pentesting tool to bypass captchas http://cintruder.sourceforge.net/ How a trio of hackers brought Google's reCAPTCHA to its knees | Ars Technica http://arstechnica.com/security/2012/05/google-recaptcha-brought-to-its-knees/ Snapchat Account Registration CAPTCHA Defeated - Slashdot http://it.slashdot.org/story/14/01/23/2037201/snapchat-account-registration-captcha-defeated Gone in 60 seconds: Spambot cracks Live Hotmail CAPTCHA http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html Troy Hunt: Breaking CAPTCHA with automated humans http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.html Slashdot | Now Even Photo CAPTCHAs Have Been Cracked http://it.slashdot.org/article.pl?sid=08/10/14/1442213 Cheap CAPTCHA Solving Changes the Security Game https://freedom-to-tinker.com/blog/felten/cheap-captcha-solving-changes-security-game/ unCAPTCHA Breaks 450 ReCAPTCHAs in Under 6 Seconds https://www.bleepingcomputer.com/news/technology/uncaptcha-breaks-450-recaptchas-in-under-6-seconds/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
I'll have more to say on this (of course I will ;) ) but I'll mention that I'm attempting to assemble what I'll call, for lack of a better term, a roadmap of RFCs that mail system operators should be familiar with. I'm doing this because I'm trying to (a) train some junior people and (b) fill in gaps in my own knowledge. I'll likely ask ietf-smtp and mailop to both review it because I have no doubt that I'll overlook some that should arguably be included. Once it's put together, perhaps it would be useful to all of us. (Modulo those people who've already read them all and can quote them at length from memory. ;) ) ---rsk ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
On 5/9/2019 9:15 AM, Paul Kincaid-Smith via mailop wrote: If your service will enable customers to collect email addresses via a web form, you can reduce the risk of list bombing: https://www.m3aawg.org/rel-WebFormHeader The documents that Paul referenced in his last message - probably mentioned this somewhere - but I'll add that (in addition to the link above and doing confirmed-opt-in "COI") you should strongly encourage your customers to captcha-protect their signup forms to prevent bots from signing up spamtrap addresses. That has been happening OFTEN in recent years - and those who don't do COI and don't captcha-protect their forms (or some equivalent only-a-human-could-have-done-this protection) - are OFTEN getting blacklisted due to spamtrap addresses sneaking into their distribution lists. -- Rob McEwen https://www.invaluement.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
Hi Stefan, I am encouraged that you're choosing to be proactive and want to configure your platform and processes to reduce the risk of email abuse. M3AAWG, the Messaging, Mobile and Malware Anti-Abuse Working Group has published numerous best practices documents to help senders and ESPs reduce abusive email: https://www.m3aawg.org/published-documents A few that will interest you: https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf https://www.m3aawg.org/sites/default/files/m3aawg-senders-complaint-handling-2017-12.pdf https://www.m3aawg.org/sites/default/files/document/MAAWG_Vetting_BCP_2011-11.pdf https://www.m3aawg.org/sites/default/files/document/CodeofConduct.pdf https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf If your service will enable customers to collect email addresses via a web form, you can reduce the risk of list bombing: https://www.m3aawg.org/rel-WebFormHeader As your email volume grows, you may qualify for a Gmail Postmaster Tools account, which can provide helpful insight: https://www.gmail.com/postmaster/ Regards, Paul Kincaid-Smith EmailGrades On Wed, May 8, 2019 at 10:48 AM Stefan Bauer via mailop wrote: > Hi, > > > we're providing a small smtp sent-service for our customers (via > submission port / auth only - postfix). ~ 7.000 outgoing mails / day (via 2 > hosts in different data centers/ip networks). > > > As the amount of mails increase, we would like to be ready for > > > - stolen auth-data to our service is used for sending spam > > > - broken clients send thousand of mails/minute > > > - one of our pub-ips get blacklisted / rerouting traffic? > > > - ISPs block our complete provider networks (and we are included) > > > - Perm-blocks with 5xx, always return all 5xx to senders? > > > > How do you guys prepare yourself for this? > > > we have in place: > > > only allow pre-defined sender-addresses after auth > > monitor mail-queues for high connection count > > monitor RBLs if we're listed > > only allow single mail / 5s to be sent outgoing > > anti-virus checking of attachments > > > Would be awesome to get some insight how "big sites" handle this and maybe > other cases. > > > Thank you! > > > Stefan > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
On 5/8/19 1:48 PM, Ken O'Driscoll via mailop wrote: > There is likely more, above is, as I said, off the top of my head. Good > luck. > One to add: * Sign up for feedback loops with the major providers. I see a remarkable number of phished-credential bots that are smart enough to send one message every ~five minutes. Our automated defenses miss those, until Comcast or AOL starts sending me complaints. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
> Hi Ken, > > > > awesome. Thats a bunch of helpful steps! Thanks a lot! > I'm a few years removed from directly administering a 'real' mail server (directly, at least) but I have some observations about Ken's list: > > * Monitor abuse@ and make sure that this address a) exists for your > client >domains and b) you receive a copy of messages sent to them. Tough call mandating the existance and handling of abuse@ for client domains, nevermind actually receiving email that belongs to clients! Clients should be advised to run the RFC-specified email addresses, but they're responsible for their conduct. If someone reports to me that one of my customers is engaged in abusive practices (or compromised, perhaps) then i'll take action directly, but they should have the chance to solve their own issue (or identify malicious false-positives, perhaps) before their service provider has to get involved. > * Restrict access to the submission port to either the client IP range. When authenticated SMTP is offered as a service (essentially a must for mobile support), IP address restrictions are counter-productive. The usual 'don't be an open mail relay' rules apply of course. > > * Lock accounts after X failed logins and get an alert about that. I do support this to an extent, but this is also a DoS vector. Alert, yes. Lock? Not necessarily. > * Have a third (failover/fallback) sending capability with a different >data centre. Periodically route enough email though that to ensure that >it will not be throttled in case you need it. But, don't use it as a >primary. I agree with this in principle. Not sure how straightforward it is to do it in practice, but an alternative SMTP option is useful. > * Understand what your normal usage profile looks like - graph the mail > >queues. This will help you build policies / tech. around detecting >unusual behaviour. E.g. tougher throttling outside of business hours >etc. This could have merit, depends on the nature of those using your service. > * Add a custom header (X-abuse) to make it clear where the email came > from >and how to report abuse of your service. Yes, supported. > * Make it clear on your website how a non-customer can contact you to >report abuse. Also supported... consider https://github.com/securitytxt/security-txt as well. > * Run a cut-down spam filter on the outbound mails (look for stuff like > >freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of > >that will be false positives so just put it into a holding queue and >create a service desk ticket for it to be reviewed. Spamfiltering outbound mail is a great idea, as it'll help preserve your reputation, and that of a customer, if they get compromised and someone starts taking advantage.e But putting suspect email in a queue for your own service desk is questionable IMO. Notify, Alert, absolutely, but again, unsure if you should bog your own service desk and essentially tarpit outgoing email,... I'd say refuse outright (5xx error) and let the sender unpick it. No black hole ambiguity. > * Have a clear upgrade path if case they wish to send marketing emails. > If >you don't, they will just try to send them through your platform. > * Publish an Acceptable Use Policy (AUP) and make them agree to it as a > >pre-condition to using your service. Spamhaus have a good template to > >start from on their website. The above kinda relate, the AUP is a given (anyone offering a service should have one, regardless of the service, pretty much!) and that should include the nature of what the threshold for marketing emails might be before an alternative product needs to be considered. > * Monitor bounces and tie that it with your monitor solution. Yes, if you can. > * Monitor the health of your clients connecting IPs (and possibly >website). Any indication of a compromised site is grounds for locking > >the account until a human can review. For suspected compromises, yes this is great... your T needs to permit you to immediately suspend service if you think an account has been compromised, as a risk and damage mitigation factor (your IP's rep on the line, thus, the deliverability of all your other customer's emails). Customers don't tend to think about this until they're blocked, then they get grumpy.. so if they know about it ahead of time, you're covered. GLHF Mark. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
Hi Ken, awesome. Thats a bunch of helpful steps! Thanks a lot! Cheers Stefan -Ursprüngliche Nachricht- Von: Ken O'Driscoll via mailop Gesendet: Mittwoch 8 Mai 2019 20:01 An: mailop@mailop.org Betreff: Re: [mailop] Howto be a good mailop (best practice / insights wanted) On Wed, 2019-05-08 at 16:45 +, Stefan Bauer via mailop wrote: > we have in place: > > only allow pre-defined sender-addresses after auth > monitor mail-queues for high connection count > monitor RBLs if we're listed > only allow single mail / 5s to be sent outgoing > anti-virus checking of attachments Hi Stefan, off the top of my head I would add: * Monitor abuse@ and make sure that this address a) exists for your client domains and b) you receive a copy of messages sent to them. * Restrict access to the submission port to either the client IP range. * Lock accounts after X failed logins and get an alert about that. * Have a third (failover/fallback) sending capability with a different data centre. Periodically route enough email though that to ensure that it will not be throttled in case you need it. But, don't use it as a primary. * Understand what your normal usage profile looks like - graph the mail queues. This will help you build policies / tech. around detecting unusual behaviour. E.g. tougher throttling outside of business hours etc. * Add a custom header (X-abuse) to make it clear where the email came from and how to report abuse of your service. * Make it clear on your website how a non-customer can contact you to report abuse. * Run a cut-down spam filter on the outbound mails (look for stuff like freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of that will be false positives so just put it into a holding queue and create a service desk ticket for it to be reviewed. * Have a clear upgrade path if case they wish to send marketing emails. If you don't, they will just try to send them through your platform. * Publish an Acceptable Use Policy (AUP) and make them agree to it as a pre-condition to using your service. Spamhaus have a good template to start from on their website. * Monitor bounces and tie that it with your monitor solution. * Monitor the health of your clients connecting IPs (and possibly website). Any indication of a compromised site is grounds for locking the account until a human can review. There is likely more, above is, as I said, off the top of my head. Good luck. Ken. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
On Wed, 2019-05-08 at 16:45 +, Stefan Bauer via mailop wrote: > we have in place: > > only allow pre-defined sender-addresses after auth > monitor mail-queues for high connection count > monitor RBLs if we're listed > only allow single mail / 5s to be sent outgoing > anti-virus checking of attachments Hi Stefan, off the top of my head I would add: * Monitor abuse@ and make sure that this address a) exists for your client domains and b) you receive a copy of messages sent to them. * Restrict access to the submission port to either the client IP range. * Lock accounts after X failed logins and get an alert about that. * Have a third (failover/fallback) sending capability with a different data centre. Periodically route enough email though that to ensure that it will not be throttled in case you need it. But, don't use it as a primary. * Understand what your normal usage profile looks like - graph the mail queues. This will help you build policies / tech. around detecting unusual behaviour. E.g. tougher throttling outside of business hours etc. * Add a custom header (X-abuse) to make it clear where the email came from and how to report abuse of your service. * Make it clear on your website how a non-customer can contact you to report abuse. * Run a cut-down spam filter on the outbound mails (look for stuff like freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of that will be false positives so just put it into a holding queue and create a service desk ticket for it to be reviewed. * Have a clear upgrade path if case they wish to send marketing emails. If you don't, they will just try to send them through your platform. * Publish an Acceptable Use Policy (AUP) and make them agree to it as a pre-condition to using your service. Spamhaus have a good template to start from on their website. * Monitor bounces and tie that it with your monitor solution. * Monitor the health of your clients connecting IPs (and possibly website). Any indication of a compromised site is grounds for locking the account until a human can review. There is likely more, above is, as I said, off the top of my head. Good luck. Ken. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
