pattern modifier to select current message in pager?
If I am in a folder and I am currently on some message (eg. #702), I'm looking for a pattern to delete all previous message, up to and including the selected message. I can do this manually by running "D" with the pattern "~m -702" (I had to type in the number of the currently selected message). But if I want to do this for any message I am on (so I can alias this), I didn't see any pattern modifier in the manual that allowed me to do this. Is this possible? thanks, Thomas
Re: New to Mutt, unable to send messages in *any* attempted way
On 06May2022 12:28, x...@trimaso.com.mx wrote: >Thanks again. > >As mentioned in first message, system has Postfix by default, with its >corresponding /usr/sbin/sendmail and /etc/postfix/main.cf . >Since I don't have anything for $sendmail variable, it's defaulting >indeed for Postix sendmail. Probably not? If you've been debugging the $smtp* variables (in particular, having to debug the password) then it sounds like mutt is actually sending directly with SMTP and _not_ using the local postfix. When you send with the local postfix, mutt just hands the message off to the sendmail command and doesn't say anything about delivery - that is sendmail's job. >On Thu, May 05, 2022 at 19:19:45 -0500, Cameron Simpson wrote: >>Might be. It won't be a "real" Message-ID line as it looks like the log >>tries to include the username of the user who sent the email. >> >>However, you're using SMTP to smtp.domain.tld, which means you're not >>using the local mail system, which means that it should not be logging >>locally for email you send using mutt. >> >Sorry... By "log" here I meant the default ~/sent one, default set for >$record variable Ah, do this is a real message-id field then. Message ids are specified here: https://tools.ietf.org/rfcmarkup/5322#section-3.6.4 I'm not sure you can put a second "@" in a message id - my reading of the grammar says it basicly looks like "". >>No, it is just what gets written into the heder line so that people >>know >>what address to use for replies and citations. >> >Then how do I know the email is really being sent from >u...@domain.tld 's account/SMTP? Hahahaha! You don't! There are various headers which _may_ be added to messages and which a receiver _may_ consult to verify identity, but they're not appplied by default. (They inherently require extra setup, as you need to provide the extra identity in your config.) There are headers which confirm that an ISP sent the message - that would tell the receiver that it can from _where_ it says it comes from, but not from _who_. There are DNS records (SPF) which specify where messages for a domain may come _from_. These can be used by receiving systems to reject messages from other sources claiming to be from that domain. These are often loosely defined though, if present at all. Of course, you're then trusting the receiving system on this point when you collect your email. >>Mutt has some debug flags. Try using the "-d 5" option. >> >Got: "DEBUG was not defined during compilation. Ignored." Oh, that is unfortunate. You might need to built it from source unless your vendor provides some kind of "debugging enabled" version of the mutt package. >Any other ways to tell whether email is really being sent with STARTTLS? The Received: headers of the message (when you get it back) record how the message was received (possibly there will be several of these). For example, this message of yours as received by me here has this header for the final hop: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cskk.id.au (Postfix) with ESMTPS id 773F343999 for ; Fri, 6 May 2022 17:35:24 + (UTC) The second line doesn't say that STARTTLS was used, just that TLS was used. That implies either a cleartext connect with a STARTTLS, or a TLS/SSL connection directly. Encrypted either way. Of course, you need to trust the content of those headers. >On Thu, May 05, 2022 at 23:06:15 -0500, Nathan Stratton Treadway wrote: >>Some ISPs specifically block outgoing traffic on TCP port 25 (which is >>the default port for "smtp:" traffic) >> >Which means, if not specifying port then Mutt (or Postfix?) takes port >25 as SMTP default... >Wasn't/shouldn't port 587 the new default for SMTP? >So Heirloom Mailx also takes port 25 as default? Maybe? You could check its docs or help messages. You could get really funky and watch it send your email. here's me testing the "nc" command on a local Ubuntu system: [~]borg*> strace -e trace=network nc 127.0.0.1 25 Also, some more doubts aroused: > >---If adding the "-n" option to whole email sending command, it does >*nothing*, just immediately getting an exit status of '1'. What's >happening with this? "man mutt" says that: -n Do not read the system-wide Muttrc configuration file. If you're getting an exit 1, I'd expect some kind of error message as well. >---Where in the manual can I find the meaning of each of the %Z >letters here http://www.mutt.org/doc/manual/#index-format ? I mean, >the letters norON, DdSPsK... It's right there in the table: %Za three character set of message status flags. the first character is new/read/replied flags (“n”/“o”/“r”/“O”/“N”). the second is deleted or encryption flags (“D”/“d”/“S”/“P”/“s”/“K”).
Re: New to Mutt, unable to send messages in *any* attempted way
Thanks again. As mentioned in first message, system has Postfix by default, with its corresponding /usr/sbin/sendmail and /etc/postfix/main.cf . Since I don't have anything for $sendmail variable, it's defaulting indeed for Postix sendmail. On Thu, May 05, 2022 at 19:19:45 -0500, Cameron Simpson wrote: Might be. It won't be a "real" Message-ID line as it looks like the log tries to include the username of the user who sent the email. However, you're using SMTP to smtp.domain.tld, which means you're not using the local mail system, which means that it should not be logging locally for email you send using mutt. Sorry... By "log" here I meant the default ~/sent one, default set for $record variable No, it is just what gets written into the heder line so that people know what address to use for replies and citations. Then how do I know the email is really being sent from u...@domain.tld 's account/SMTP? Mutt has some debug flags. Try using the "-d 5" option. Got: "DEBUG was not defined during compilation. Ignored." Any other ways to tell whether email is really being sent with STARTTLS? On Thu, May 05, 2022 at 23:06:15 -0500, Nathan Stratton Treadway wrote: Some ISPs specifically block outgoing traffic on TCP port 25 (which is the default port for "smtp:" traffic) Which means, if not specifying port then Mutt (or Postfix?) takes port 25 as SMTP default... Wasn't/shouldn't port 587 the new default for SMTP? So Heirloom Mailx also takes port 25 as default? Also, some more doubts aroused: ---If adding the "-n" option to whole email sending command, it does *nothing*, just immediately getting an exit status of '1'. What's happening with this? ---Where in the manual can I find the meaning of each of the %Z letters here http://www.mutt.org/doc/manual/#index-format ? I mean, the letters norON, DdSPsK... ---When browsing emails in Mutt, why do sizes inside () -for example, (1.1K)- change to something different and smaller -( 6)- when hitting enter to display the message? Thanks again.
Re: Gmail OAuth/OOB deprecation: how to fix?
On Friday, 06.05.2022 at 22:38 +0800, lilydjwg wrote: > On Fri, May 06, 2022 at 03:32:38PM +0100, Dave Ewart wrote: > > [...] > > > > What are the implications of the access code expiring? I don't see any > > symptoms which might be associated with that and the Mutt client is > > running in 'screen' 24/7/365. > > When it expires you need to login via web and copy the code again. You > mean your access code doesn't expire? That's a good thing. Maybe it only > applies to recently created apps (e.g. mine). I don't have to do that, no. I put this: set imap_oauth_refresh_command="~/src/google-oauth-for-mutt/oauth2.py --quiet --user= --client_id=http://twitter.com/DaveEwart All email from me is digitally signed, http://www.sungate.co.uk/ GPG key updated Jan 2013 see http://www.sungate.co.uk/gpg Fingerprint: CF3A 93EF 01E6 16C5 AE7A 1D27 45E1 E473 378B B197
Re: Gmail OAuth/OOB deprecation: how to fix?
On Fri, May 06, 2022 at 03:32:38PM +0100, Dave Ewart wrote: > [...] > > What are the implications of the access code expiring? I don't see any > symptoms which might be associated with that and the Mutt client is > running in 'screen' 24/7/365. When it expires you need to login via web and copy the code again. You mean your access code doesn't expire? That's a good thing. Maybe it only applies to recently created apps (e.g. mine). > Testing with a single 'user' of my 'app' is fine: it's just me talking > to my Gmail :-) -- Best regards, lilydjwg
Re: Gmail OAuth/OOB deprecation: how to fix?
On Friday, 06.05.2022 at 22:23 +0800, lilydjwg wrote: > On Fri, May 06, 2022 at 03:10:37PM +0100, Dave Ewart wrote: > > [...] > > > > Hmm, so "testing mode" is where I did the initial setup to hardcode the > > tokens into my (encrypted) config? > > > > So it sounds like maybe I don't need to do anything, but is there a > > better way that doesn't use 'testing'? [Maybe it's not needed, I've been > > using the single 'testing' setup unmodified since late 2020!] > > AFAICT testing mode isn't affected and can continue to work as before. > That 'testing' means that you can only add limited testers to use your > app (the thing that has a client_id etc). For personal use the only > annoying part I find is that the access code expires every 7 days. What are the implications of the access code expiring? I don't see any symptoms which might be associated with that and the Mutt client is running in 'screen' 24/7/365. Testing with a single 'user' of my 'app' is fine: it's just me talking to my Gmail :-) Cheers, Dave. -- Dave Ewart da...@sungate.co.uk, http://twitter.com/DaveEwart All email from me is digitally signed, http://www.sungate.co.uk/ GPG key updated Jan 2013 see http://www.sungate.co.uk/gpg Fingerprint: CF3A 93EF 01E6 16C5 AE7A 1D27 45E1 E473 378B B197
Re: Gmail OAuth/OOB deprecation: how to fix?
On Fri, May 06, 2022 at 03:10:37PM +0100, Dave Ewart wrote: > [...] > > Hmm, so "testing mode" is where I did the initial setup to hardcode the > tokens into my (encrypted) config? > > So it sounds like maybe I don't need to do anything, but is there a > better way that doesn't use 'testing'? [Maybe it's not needed, I've been > using the single 'testing' setup unmodified since late 2020!] AFAICT testing mode isn't affected and can continue to work as before. That 'testing' means that you can only add limited testers to use your app (the thing that has a client_id etc). For personal use the only annoying part I find is that the access code expires every 7 days. -- Best regards, lilydjwg
Re: Gmail OAuth/OOB deprecation: how to fix?
On Fri, May 06, 2022 at 03:11:54PM +0100, Dave Ewart wrote: > On Thursday, 05.05.2022 at 20:27 -0700, Robin Lee Powell wrote: > > > Try this: > > https://nidkil.me/2018/01/18/setting-up-mutt-to-send-mail-using-gmail-with-2fa-set/ > > Is this something you are using or recommend? I note that the post is > more than four years old and my query relates to a very recent change in > the Google setup. I'm using the script and method from getmail6 [1] but have adapted it to msmtp and offlineimap. > I thought 'app passwords' were considered somewhat deprecated by GMail, > to be honest... ? No. GMail is deprecating login via account passwords, not app passwords. [1] https://github.com/getmail6/getmail6/blob/master/docs/getmailrc-examples -- Best regards, lilydjwg
Re: Gmail OAuth/OOB deprecation: how to fix?
On Thursday, 05.05.2022 at 20:27 -0700, Robin Lee Powell wrote: > Try this: > https://nidkil.me/2018/01/18/setting-up-mutt-to-send-mail-using-gmail-with-2fa-set/ Is this something you are using or recommend? I note that the post is more than four years old and my query relates to a very recent change in the Google setup. I thought 'app passwords' were considered somewhat deprecated by GMail, to be honest... ? Dave. -- Dave Ewart da...@sungate.co.uk, http://twitter.com/DaveEwart All email from me is digitally signed, http://www.sungate.co.uk/ GPG key updated Jan 2013 see http://www.sungate.co.uk/gpg Fingerprint: CF3A 93EF 01E6 16C5 AE7A 1D27 45E1 E473 378B B197
Re: Gmail OAuth/OOB deprecation: how to fix?
On Friday, 06.05.2022 at 11:16 +0800, lilydjwg wrote: > [...] > > If you are using it in testing mode, you don't need to do anything as > they say: > > > No action is required on your part as apps using OOB in testing mode > > will not be affected by this change. > > The OOB refers to you manually copy the access code from your browser to > your application. > > Without OOB, you can run a local web server or register your own > protocol to receive the code. Hmm, so "testing mode" is where I did the initial setup to hardcode the tokens into my (encrypted) config? So it sounds like maybe I don't need to do anything, but is there a better way that doesn't use 'testing'? [Maybe it's not needed, I've been using the single 'testing' setup unmodified since late 2020!] Cheers, Dave. -- Dave Ewart da...@sungate.co.uk, http://twitter.com/DaveEwart
