We didn't release any, since we changed focus. The simple answer is, instead of PLAIN which has a sasl format of (taking the abnf from RFC 4616): message = [authzid] UTF8NUL authcid UTF8NUL passwd it includes a client-token: message = [authzid] UTF8NUL authcid UTF8NUL passwd UTF8NUL client-token
I also wouldn't recommend using the MAC address as in Michael's proposal, as that as privacy implications. It should either use a device specific API to request a unique id and store it in the client, or just have the client create one and keep it. The point is, that always a user to wipe a device and give it to someone else, or even just wipe and replace, without being able to track the user in other ways. The benefits are the same, if you've never seen a client-token before, you need to be more careful with it, but if you have seen it before, then it's less likely that the login attempt is a hijacking or dictionary attack. It can also aid in using say geohop stats. Ie, one easy way to try to detect hijacking is to geoloc the accessing IP, and see how close it was to the last access, or keep track of where the user is accessing from. This has obvious issues if your users travel. If a user with a phone that supports it goes somewhere else, chances are they'll access from the phone first, even if their desktop client doesn't support client-token, so you have a strong signal that they traveled somewhere else. All of this requires per-user login permission systems, nothing as simple as say banning AWS or China, its' knowing whether a given user ever uses your service from those locations. A first access from that location may be blocked, requiring the user to go to a web page and verify the access attempt (web access gives you a lot more signals, so doing login permission detection there is often easier). Anyways, the massive service providers have been having to do this stuff for almost a decade, it's always been a matter of time til it filters down to the larger or medium size providers. Anyways, that's the reason we moved to requiring OAUTH by default, and requiring users to jump through hoops to enable "less secure apps" (ie, password based auth). Brandon On Fri, Oct 6, 2017 at 11:57 AM, <andris.rein...@gmail.com> wrote: > Is there any documentation available about PLAIN-CLIENTTOKEN? All I can > find are SMTP transcripts about connecting to Gmail. > > Best regards, > Andris Reinman > > On 6 Oct 2017, at 21:24, Brandon Long via mailop <mailop@mailop.org> > wrote: > > I still prefer our sasl extension, PLAIN-CLIENTTOKEN instead, since you > can then use it for imap/pop/smtp simply. > > Or focus on oauth... > > On Oct 6, 2017 7:57 AM, "Michael Peddemors" <mich...@linuxmagic.com> > wrote: > > SMTP Auth Scanners are easier to stop, which is why there are more IMAP > scanners being seen in the wild. > > But that is why we are pushing forward on our CID implementations.. > > https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/ > > Can't really block AUTH attempts strictly by 'firewall' or IP rules, as a > bot could be operating out of shared or dynamic space, which would mean > that you effectively block legitimate users from accessing email. > > We actually have a RATS-AUTH list designed to report on IP(s) used for > AUTH attacks, the broken bots are easier to pick up. > > But this isn't a 'Chinese' thing only, we see lot's of these attacks > coming from everywhere, including Amazon AWS etc.. > > > On 17-10-06 05:30 AM, Tim Bray wrote: > >> On 06/10/17 10:51, Otto J. Makela wrote: >> >>> Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP >>> scans, >>> using scraped email addresses and apparently going through whole >>> dictionaries? >>> >> >> I haven't seen them. But we are getting a lot more SMTP auth scanners >> than we used to. >> >> We just drop them in the firewall for a bit. We've dropped about 300 >> IPv4 addresses in the last 6 hours. >> >> >> Tim >> >> _______________________________________________ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> > > > -- > "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 > > > _______________________________________________ > 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
