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 10:09:49 +1000 Message-ID: <87mtffhdqm.fsf@gmail.com> References: <87wnek5d9c.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="14912"; 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 02:44:15 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 1nr7nT-0003e6-Qu for ged-emacs-devel@m.gmane-mx.org; Wed, 18 May 2022 02:44:15 +0200 Original-Received: from localhost ([::1]:50346 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nr7nS-0000lv-JS for ged-emacs-devel@m.gmane-mx.org; Tue, 17 May 2022 20:44:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36598) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nr7mr-0008Vp-6F for emacs-devel@gnu.org; Tue, 17 May 2022 20:43:37 -0400 Original-Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]:44901) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nr7mp-0001ar-Et for emacs-devel@gnu.org; Tue, 17 May 2022 20:43:36 -0400 Original-Received: by mail-pf1-x432.google.com with SMTP id x143so632690pfc.11 for ; Tue, 17 May 2022 17:43:35 -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=2PEdglzq1WWx55I0nw4Cbqdd4Btxv2Z3IIx65HZFU34=; b=Jkp6VMP+nQy7p5OOWvwZhgvFNzr9nj5yEPqU9t6jkN5qadegUd5K0fUuK13jSc7tZC 32VMQ1J6m8wPocTG3P09W4QwGQjlDHWj4HkNdeH6bN+Sf6WR3yN5ixvv+/A73/ckNNAH 8E5JnWjMEiD8YclUXrLA2eUQygfvTS4e8YAnptsz7BCuxH/tIf34odjgQaby0f29mDw9 e/nSoZVcgQLhI1t5jqIfoc58cH6MzJz2I/hR1LhCvJgFTClOUSAHzttIBJnLOtc6CKT4 BFWuMbkEuZu1j9TjdXu6f6TQMMOGXLqwRkOmON33xVQxA2vqHF8JtDZGL/1p8MAp4TS6 KSJg== 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=2PEdglzq1WWx55I0nw4Cbqdd4Btxv2Z3IIx65HZFU34=; b=21N8EuJ11aL9qJveyqOPfY0xwLPfHXqh93BAMA/6q8+j+DdsU7IZCW1qp9PIOD4Ju+ 9sY6bOyTTt1xx3rusTB+be4kAUe8931u0YLm4sdsv9kakpN34Y7pl67qsYnqRfPIis0L Ukc4TLpG4dqBeFmk6fs+LxJVEdc8y9We+ohfVqelmyyzgA12KAtf0KWQTJTbZCsSUoo3 QgSPMJ11lYym5JxuBjybO34z8/6NbBOy1Jz+tgeJH+5PlCPZ68V+Pn7u4xCv4xyjq9+x RHUVBMH++GeNX43QGUyatK8onTn67o+7ETmUqqtHeVh/qcDxxNVOjWb9hTOlARNREWo0 jG2Q== X-Gm-Message-State: AOAM532XYgJq+oEJStP4dgZSzPPX/7D1S/dJCFHSRy5AebYCseIGffVI QmR6I1F5WKDMWiRfRYEYAFtrciTu+80= X-Google-Smtp-Source: ABdhPJzbuBMs+XGpU/5jqVGEGx357imAvUZnJmZE4IrAfmXSHncETN0+kmS7zxj1AKId4mlXeXLj2Q== X-Received: by 2002:a05:6a00:1251:b0:50d:f2c2:7f4e with SMTP id u17-20020a056a00125100b0050df2c27f4emr25131031pfi.72.1652834613709; Tue, 17 May 2022 17:43:33 -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 c13-20020a056a00008d00b0050dc76281a0sm341470pfj.122.2022.05.17.17.43.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 May 2022 17:43:33 -0700 (PDT) In-reply-to: <87wnek5d9c.fsf@mat.ucm.es> Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x432.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:289899 Archived-At: 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. > > 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). > > 2. Or use a SMTP service that allows me to use a different form > field, once the address has been verified. Gmail did this in the > past (and maybe still does it). > Yes, you will need this. You will likely communicate with this server using smtpmail. However, in addition to allowing you to set the from field, you probably also need a service which will handle the SPF and various other anti-spam headers correctly. This can be very complex and few services seem to do this correctly. Creating such setups when you actually own the email domain is somewhat easier. Doing it when you are just a client of that domain (as in your case) is much much more difficult. > In any case I have been warned that my mails could be blacklisted. > Yes, almost certainly will. The real challenge will be in getting the various spam prevention schemes to work correctly. This is very difficult when your using an SMTP server which is not part of the domain your email appears to come from. When you own the domain, there are various things you can do with DNS records to allow messages sent via a different domain, but you don't own the domain and so cannot manage such records. This would have to be done by the University and they almost certainly won't be willing to do that. > Anybody has experience with such a service/setting? I have run into this issue for various clients in the past. It is a pain to get sorted out and you need a really accommodating SMTP service provider (very difficult to find unless you are willing to fork out real cash). I would check with your institution to see if they would be agreeable to having a reply-to: header which points to your institutional address rahter than putting it in the from: header. This would cause less issues and would still ensure the replies to your messages go through the University mail system (which is what I'm assuming is the reason for their request to have their domain as the from line). The downside wiht reply-to: is that it depends on the message recipient's mail client honouring that header. While most clients will, some do not. I would strongly encourage you to try and use the app password solution. The alternative you are proposing is possible, but is not for the faint hearted and requires significant deep understanding of both SMTP and the various evolving spam prevention frameworks as well as an SMTP service partner who actually has the in-house expertise to run a correctly configured and maintained SMTP server. Bottom line: the app passwords solution 'just works'. Just generate the app passwords and use them instead of your normal password for imap and smtp. The altgernative you are proposing will be unlikely to work 100%, will require on-going maintenance and will likely be fragile and result in a higher percentage of your messages being blocked or quarantined.