sampablokuper (78977fb1) at 14 Feb 00:53
Merge branch 'fix-external-links' into 'master'
... and 2 more commits
sampablokuper (cccafa22) at 13 Feb 21:31
Per mailing list.
sampablokuper (cccafa22) at 13 Feb 21:11
Fix broken link to David T-G's website
... and 1 more commit
sampablokuper (521ae810) at 09 Dec 19:03
Amend orthography. Add link to Wikipedia.
... and 5 more commits
Thinking aloud: can responsibility for saving the message to the sent-folder be delegated to Sendmail? (I.e. does Sendmail support this functionality, if invoked with suitable command line arguments?) If so, then of the available approaches, this would probably be the closest to an atomic one.
Downside: many people use an MTA (or MSA) other than Sendmail itself, and compatibility varies. If a Mutt user's Sendmail clone lacked that functionality, and the user upgraded to a version of Mutt that expected the local Sendmail to possess that functionality, then attempts to send mail might thereafter fail until the user edited their .muttrc
to restore the original behaviour.
Thanks for merging this! Thanks also for committing b6d9c755 to fix my version numbering mistake; apologies about the latter.
I am in favour of this proposal, but only if the change is postponed until the next major version release (i.e. Mutt v2.0.0), per Semantic Versioning 2.0.0 §8:
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.
sampablokuper (8960e637) at 03 Dec 00:12
Deprecate TLS 1.0 and 1.1 by default
Inspired by #101.
Fixes #101.
Minor digit of version number has been bumped per Semantic Versioning 2.0.0 §7:
Minor version Y (x.Y.z | x > 0) MUST be incremented if ... any public API functionality is marked as deprecated.
sampablokuper (79e485bf) at 02 Dec 23:59
Enhance docs re security of SSL/TLS version vars
sampablokuper (05e894c4) at 02 Dec 23:58
Deprecate TLS 1.0 and 1.1 by default
Currently, the www.mutt.org website is not served via HTTPS by default. Although access to it via HTTPS is available, at https://www.mutt.org , this requires the user to bypass an "ERR_CERT_COMMON_NAME_INVALID" warning. Many users are unlikely to bypass such warnings, mistakenly believing that using HTTPS with an invalid certificate is somehow worse than not using HTTPS at all.
Regardless, to reduce the risk of visitors' connections to the www.mutt.org website being man-in-the-middled, and to reduce the risk of the website being down-ranked in search results, please adopt HTTPS with a valid certificate, preferably implemented so as to score at least an "A" grade from SSLLabs.
One possible way to achieve this would be to work with the system administrators of the website's current web host (cass.oregonstate.edu) to provide a suitable HTTPS certificate (e.g. via Let's Encrypt), and to modify the web server's configuration appropriately.
An alternative way to achieve it would be to migrate the web hosting from cass.oregonstate.edu to GitLab Pages.
In my experience, coming from GUI MUAs, when a user tells an MUA to forward (not "bounce", nor "resend") a message, that MUA should, without further prompting, do all of the following:
The divergence between Mutt and more common MUAs, on the last point, currently requires the user to follow a multi-step workaround every time the user wants to forward a message with attachmants:
<view-attachments>
,<tag-prefix>
,<forward-message>
.Unfortunately, this workaround is prone to human error (such as failing to tag all of the attachments) and moreover, it cannot currently be readily automated (e.g. turned into a macro), because <tag-pattern>
does not work in the Attachment Menu.
Mutt's current inability to behave according to the list at the top of this feature request is, unfortunately: an ergonomic annoyance that Mutt users must bear until its behaviour is improved in that respect; a barrier to adoption (a "pain point") for would-be Mutt users who expect GUI MUA-like behaviour; and an impediment to developing useful macros that depend upon being able to tag all of a message's attachments.
So, I humbly ask that Mutt be made capable of being configured to behave as described in the list at the top of this feature request, when the user invokes <forward-message>
. Ideally, as part of that work, <tag-pattern>
should be extended to work in the Attachment Menu. As a possible addition, a new configuration parameter might be introduced, called <forward-all-attachments>
or suchlike, which should probably be a quad-option set to "ask-yes" by default, and which would cause <forward-message>
to behave as though the user had performed the multi-step workaround described above.
P.S. In response to the question of how to forward all of a message's attachments, people on forums or mailing lists sometimes suggest workarounds that are no more appropriate (probably even less so) than the multi-step workaround described above. Here are a few of them, and their shortcomings, to forestall their being raised in response to this feature request:
mime-forward
to "yes" in .muttrc, then invoke <forward-message>
. (Shortcoming: sends original body as an attachment, where it is not immediately available to view, rather than in the body where it is immediately visible. Mainstream GUI clients haven't done this since the 1990s, probably because it was found to be unergonomic.)<resend-message>
. (Likely requires the "From:" and perhaps other headers to be manually adjusted. Does not delimit original message clearly. Does not set Subject correctly. Perhaps does not set References or In-Reply-To correctly.)<bounce-message>
. (Does not provide an opportunity to add any prefatory remarks.)mailbot
and reformail
) that will reformat them appropriately, and then pipe the resulting message into a new Mutt invocation as a draft message. (Overly complex: implementing this is probably beyond the average user. Also prone to break if future versions of the utilities change their invocation syntaxes.)P.P.S. In the list at the top of this feature request, I am somewhat generalising about GUI MUAs. Undoubtedly there have been GUI MUAs that did not act behave as described.
Potentially useful notes:
Based on the link, that was when the wiki was imported into Trac, not when the wiki was first created. [..] Even assuming you get all the information about Trac history, that still won't cover all the edits.
Good catch, thanks! (And yes, you did mention earlier that the wiki predated the Trac instance; mea culpa.)
I don't have information on when the original wiki was created, but it was before 2012, perhaps well before.
You are absolutely right.
A Wikipedia edit from 10 November 2004 indicates that the MuttWiki's home at that time was at http://wiki.mutt.org. Happily, the Wayback Machine has some snapshots and page history captures for that subdomain from at least as early as 2002.
This was indeed a time before StackOverflow existed, before Wikipedia adopted CC BY-SA, before the definition of free cultural works was published, and before conventions around wiki licensing had become established.
If you continue making statements and implications like that, I'm afraid I will close this ticket and ask you nicely to leave. I won't be bullied into this process.
I certainly wasn't trying to ruffle any feathers, and I apologise if I did.
I was provisionally - and hastily - reporting my understanding based upon what I had found so far, with the intention of being constructive. But that provisional understanding of mine was mistaken, and as such my earlier rebuttal about licensing was premature. Please consider it withdrawn. I should probably have worded things better, in any case.
Absolutely no offence was intended.