From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: gmail+SMTP(only) (oauth2) Date: Wed, 18 May 2022 16:35:09 +1000 Message-ID: <87fsl7l3c8.fsf@gmail.com> References: <87fsl75pu4.fsf@mat.ucm.es> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15741"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.21; emacs 28.1.50 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 18 09:17:26 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nrDvw-0003np-7u for ged-emacs-devel@m.gmane-mx.org; Wed, 18 May 2022 09:17:24 +0200 Original-Received: from localhost ([::1]:55128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nrDvu-0007JD-QY for ged-emacs-devel@m.gmane-mx.org; Wed, 18 May 2022 03:17:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60250) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nrDtI-0005ai-67 for emacs-devel@gnu.org; Wed, 18 May 2022 03:14:41 -0400 Original-Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]:38432) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nrDtG-0004TZ-14 for emacs-devel@gnu.org; Wed, 18 May 2022 03:14:39 -0400 Original-Received: by mail-pl1-x633.google.com with SMTP id n18so962188plg.5 for ; Wed, 18 May 2022 00:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=3BAtrKTkgpegYOSMko4GY9fgcsusF0JVb2UUnRJUoes=; b=dRc6mqWQbVsiXdwOJ6aLU/aI/bD0sxp2vsqDv7VWkzZ3Gpxr1I/bddmpn0nEKBtZ2C o5VWi8u2NJNUHQJVSYJvIhtkkACxBIXDBI7MtcYhHpfd3XPMZhaO/ofNBa6xdIUy6kU4 Qh3JHkk08PCwybRDuvoM9mDh5GAeSwmIqKy0/Vpy+ogiGJy/qLWrDoSQdY8vcUh3PHIc 5dLY6Or/0kO7lYOiavElTUR67QRV7erJVE7J7pFNHdz5hULqe4MkVW/VUFoP33EIntLR j9zUudOO5D9Ja6rZ2t8TP8ff2j0H3acAZzAf0znARWcVpZKy9DT23Ljdz4KvAoUPbVeT nZWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version; bh=3BAtrKTkgpegYOSMko4GY9fgcsusF0JVb2UUnRJUoes=; b=fWxXpQOE2KkKKXWuL6OzPUIBkyXDkyTxfHGsPc/+fb+1Rd3SnqNvBmvKXlY3euCUhO qHHocBuwm+3gjOxd4Aycf/FZ70/LrPDbnYukYQeMr62pe9PgmABKKz/mtCF8pI7qTzQF DOm1BkT8Kjog51ErKPGhYe0IP6H46n93VVcnbQkv14cQvsK/lSQl8hTH0wcxuEEO8s69 ZYl5yb40RZHiaQlsRGHlVXBxnHQrUMTOut85fiEU3EMF/nTflmX8RM4Cr33oM4m/y0WE xC7+ylubm9ZUVY7nFSB34aVEpcUmunRbzrz8b2BZ4ejNTbAJIxKGP+MtDvZ0VcwXIIwN v3Bg== X-Gm-Message-State: AOAM531BEBuM/+P43GpL7G+JyEkIIYionGhMUEmG1aOVGME1fnTNZlp8 1EivaArEmH9LNEbz8RPv8OdCMmkJmIQ= X-Google-Smtp-Source: ABdhPJyPBE4wvA6x7JWBuFW30V6GjVuC3EV4oW0lg35G7dU++B1BcSbzXUxgH6IXaSAL/dfriHHG1g== X-Received: by 2002:a17:903:22c6:b0:15f:14e1:1518 with SMTP id y6-20020a17090322c600b0015f14e11518mr25866728plg.116.1652858075787; Wed, 18 May 2022 00:14:35 -0700 (PDT) Original-Received: from dingbat (220-235-29-41.dyn.iinet.net.au. [220.235.29.41]) by smtp.gmail.com with ESMTPSA id v10-20020a62ac0a000000b005182664f64asm996479pfe.140.2022.05.18.00.14.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 00:14:35 -0700 (PDT) In-reply-to: <87fsl75pu4.fsf@mat.ucm.es> Received-SPF: pass client-ip=2607:f8b0:4864:20::633; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x633.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:289910 Archived-At: Uwe Brauer writes: > [[S/MIME Signed Part:Undecided]] >>>> "TC" == Tim Cross writes: > >> Uwe Brauer writes: > >>> Hi >>> >>> Today I got the unofficial approval to forward my email to an account of >>> my choice, if I can't access my mail with TLS (SSL or the gmail app >>> password anymore) > >> So are you saying your institution won't allow you to use app passwords? >> If they do, I would highly recommend going that route as the most >> reliable and easily maintained approach. Note that even with the app >> password solution, you still are using TLS both with imap and smtp. > > > No, I did not say that, but I have seen rumors that google will drop also > the app password approach, in which case this route is not any longer > possible. > > However, I don't remember where I have seen it. > > Do you have information regarding this subject? > My recollection is that when Google originally announced the intended changes (back in 2017 or 2018), they indicated they would be removing app passwords. However, when I go through their current announcements and documentation on their support site, I cannot find any mention of removing them. Furthermore, much of their documentation appears to have been updated to state that app passwords are the preferred solution for clients who cannot do oauth2/2FA. My guess is that there was sufficient push-back after the original announcement that they reviewed their proposal and are going to leave app passwords in place for the time being. Even if they do decide to remove them, I would expect they will give a fairly lengthy notice period (It has been 4+ years since they flagged the removal of being able to use your normal google password). I would just use app passwords and wait to see what happens. A lot can change in a couple of years. >>> >>> However I have been warned that the message should have a from field >>> with a domain of my university. (@mat.ucm.es for example). >>> >>> Now I could either use >>> >>> 1. The smtpmail (or sendmail) program of my linux machine (not sure >>> about MacOS > >> No, at least not on its own. You may well use smtpmail to communicate >> with an SMTP server, but you will need to identify a new smtp server you >> can use which will allow you to use a from header which is not the >> 'standard' for that server. You cannot just use an SMTP server running >> on your local Linux desktop - at least not if you want to ensure >> reliable mail service and avoid having your messages dropped into >> blackholes and anti-spam quarantine systems. Some services might allow >> you to configure your local desktop sendmail (or postfix or whatever) as >> a satelite/smarhost which relays messages to the main SMTP service, but >> your really just adding complexity with little benefit and will likely >> run into all sorts of ISP issues (especially if your system is a laptop >> which connects via different networks). > > I see, I might be able that my machine will be registered in our DNS > databank as > > machine-name.mat.ucm.es That might help if the initial sending SMTP server is on your machine and it is registered in the global DNS (not just an internal only DNS). It means your machine has a real IP address (not a non-routed address like 192.168.*.* or 10.*.*.* etc). This would have a higher likelihood of working if your University still runs its own SMTP server and you are able to relay through it (some institutions do this to support internal applications which need to send mail). However, it is very likely the University will not allow connections out to external SMTP servers (often, spam is generated by a compromised machine connecting to an SMTP server and relaying spam etc, so standard practice is to block those ports). However, it probably won't work if your just connecting to an external SMTP server (using smtpmail or some other user mail agent). > > I am not sure that it will help if I use my Linux SMTP server, [1]. > > Especially if I am using my laptop on any other institutions or at home, > since I then will have an IP address that is not within the range of the > IP addresses my university uses. I could use VPN but that slows down > things and, it also does not allow me to use newservers since that is > blocked when using non static university's IP, sigh. Yes, that is one reason fewer people run their own SMTP server these days. In addition to all the extra hassles associated with spam prevention there is the complexity added by being mobile and connecting via different networks. > > If this approach (registering my machine) does not help, I have to pray > that google will stick to app passwords for the foreseeable future. > One of the reasons this is so hard to work out is because there are just so many different options and moving parts and the constant need to evolve and adapt anti-spam measures as the spammers find new loopholes and ways to circumvent spam prevention. I suspect it is one reason many organisations have decided to adopt an external service provider and drop in-house SMTP services.