Re: Problems sending mail

[Dan Ciprus (dciprus) via Mutt-users]

You'll need to set up the authentication for msmtp. Snippet from msmtprc:

defaults

account david-email
host mx1.dreamhost.com
port 25
protocol smtp
auth on
user youru...@fake.domain.com
password yoursecretpassword


On Mon, Sep 05, 2022 at 03:49:59PM -0500, David Bryant wrote:

Hi. I'm new to this group. I'm looking for some help.

I recently built a Linux from Scratch system. I don't have any kind of
graphical interface set up there yet. I would like to use mutt to send and
receive email using a tty terminal. Mainyly for educational purposes. I'm
composing this message with KMail2, on a Gentoo system.

I have built mutt from the tarball, and I've done some configuration stuff. In
particular, I set up msmtp as my SMTP server locally. That looked like it's
easier to configure than sendmail is. I believe I got all the necessary
configuration variables set correctly. But I can't send email.

Everything goes fine until I'm ready to send an email message. I say "y" to
send the message, and mutt replies

"Error sending message, child exited 65 (Data format error)"

msmtp issues three error messages:

msmtp: recipient address da...@davidcbryant.net not accepted by the server
msmtp: server message 554 5.7.1  Recipient address
rejected. Access denied.
msmtp could not send mail (account default from /home/dbryant/.msmtprc)

Any idea how I can get around this? I tried sending messages without going
through an external server, and that didn't seem to work either. Oh -- here's
the message from the "postponed" file.
=
Date: Mon, 5 Sep 2022 18:26:53 +
From: David Bryant 
To: da...@davidcbryant.net
Cc: davidbry...@gvtc.com
Subject: This is a test
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Mutt-Fcc: ~/sent

This is a test. This is only a test.
=

Any and all suggestions will be accepted gladly. Thanks!
--
David Bryant
Canyon Lake, Texas
https://davidcbryant.net




--
Dan Ciprus

[ curl -L http://git.io/unix ]


signature.asc
Description: PGP signature

Problems sending mail

[David Bryant]

Hi. I'm new to this group. I'm looking for some help.

I recently built a Linux from Scratch system. I don't have any kind of 
graphical interface set up there yet. I would like to use mutt to send and 
receive email using a tty terminal. Mainyly for educational purposes. I'm 
composing this message with KMail2, on a Gentoo system.

I have built mutt from the tarball, and I've done some configuration stuff. In 
particular, I set up msmtp as my SMTP server locally. That looked like it's 
easier to configure than sendmail is. I believe I got all the necessary 
configuration variables set correctly. But I can't send email.

Everything goes fine until I'm ready to send an email message. I say "y" to 
send the message, and mutt replies

"Error sending message, child exited 65 (Data format error)"

msmtp issues three error messages:

msmtp: recipient address da...@davidcbryant.net not accepted by the server
msmtp: server message 554 5.7.1  Recipient address 
rejected. Access denied.
msmtp could not send mail (account default from /home/dbryant/.msmtprc)

Any idea how I can get around this? I tried sending messages without going 
through an external server, and that didn't seem to work either. Oh -- here's 
the message from the "postponed" file.
=
Date: Mon, 5 Sep 2022 18:26:53 +
From: David Bryant 
To: da...@davidcbryant.net
Cc: davidbry...@gvtc.com
Subject: This is a test
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Mutt-Fcc: ~/sent

This is a test. This is only a test.
=

Any and all suggestions will be accepted gladly. Thanks!
-- 
David Bryant
Canyon Lake, Texas
https://davidcbryant.net

signature.asc
Description: This is a digitally signed message part.

Re: order of sending mail and saving to fcc

[Derek Martin]

[Sent before I intended to.]

On Sat, Jun 15, 2019 at 01:53:18AM +0200, Nicolas Rachinsky wrote:
> @Derek: I've read your mails in this thread, and I'm in no way
> convinced.

I'd love for you to explain why.  Note that Kevin confirmed that my
arguments are technically correct.  So despite that I techncially,
accurately described how the current solution results in you having a
local copy of the message, which was the only thing you (incorrectly)
said the current behavior was lacking, you find this to be inadequate.
I'd like to understand in what way it does not meet your needs.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgps4Oz3PKc8Z.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Derek Martin]

On Sat, Jun 15, 2019 at 01:53:18AM +0200, Nicolas Rachinsky wrote:
> I can only say, Erik wrote the answer I wanted to write.
> 
> @Kevin: The new change sounds very promising. Thank you for that
> and all your work!
> 
> @Derek: I've read your mails in this thread, and I'm in no way
> convinced.

I'd love for you to explain why.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpgFaMb4Ahl8.pgp
Description: PGP signature

Re: Making attachments [Was: Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Sun, Jun 16, 2019 at 03:34:00PM +1000, Erik Christiansen wrote:

That looks quite useful. There's also the CheckAttach vim plugin, by
Christian Brabandt.


Starting in 1.10, there is also $abort_noattach in Mutt.  It's not quite 
as useful, because it waits until you hit send and then scans the text. 
But it's also configurable via $abort_noattach_regexp.  1.11 "fixed" the 
scanner to not scan quoted text too.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Making attachments [Was: Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 16.06.19 09:48, Cameron Simpson wrote:
> I compose with edit_headers=yes, so recipients and subject are part of the
> temporary file.
> 
> Also, I attach using the Attach: pseudo header, so the attachment filename
> is also part of the temp file. Provided I haven't exited the compose mode
> (when the Attach: headers turn into actual mutt attachments) I don't lose
> that state either. (I've also got fcc_attach=yes, might be handy too.)
> 
> And to ease using the Attach: header I have this vi macro:
> 
>  map ^A 1G}-:.r!exec /dev/tty; readline -B 'Attach: '^MIAttach: ^[
> 
> Those are literal ctrl-A, ctrl-M, ctrl-[ (escape) in the macro. This means
> that I just type ctrl-A to commence an attachment and I get a file competion
> capable prompt to fill out the filename.

That looks quite useful. There's also the CheckAttach vim plugin, by
Christian Brabandt. It detects words such as "attached" in the
email body, then prompts on exit to mutt, repeating until no further
attachment paths are provided - thereby doing the remembering too. It
doesn't trigger on quoted text. The set of trigger words is
configurable. It also uses an "Attach:" header.

You'd think that someone who rereads before sending wouldn't forget that
an attachment was intended, but I have found its memory useful on more
than one occasion, especially on longish emails.

Erik

Re: order of sending mail and saving to fcc

[Cameron Simpson]

On 11Jun2019 20:21, Nicolas Rachinsky  
wrote:

* Derek Martin  [2019-06-11 12:47 -0500]:

Not only that, but I neglected the fact that if the send fails, the
file your editor produced in order for it to be passed to Mutt will
still be on disk, so you do IN FACT still have a copy of the message.


I did just (using my old mutt) set sendmail to killall -9 mutt. The
temporay file that stayed on my disk did contain my text. But there
was no other information (recipients, subject, attachments).

So if the tmpdir survives, not everything is lost. But the mail as
such is lost.


Just to this.

I compose with edit_headers=yes, so recipients and subject are part of 
the temporary file.


Also, I attach using the Attach: pseudo header, so the attachment 
filename is also part of the temp file. Provided I haven't exited the 
compose mode (when the Attach: headers turn into actual mutt 
attachments) I don't lose that state either. (I've also got 
fcc_attach=yes, might be handy too.)


And to ease using the Attach: header I have this vi macro:

 map ^A 1G}-:.r!exec /dev/tty; readline -B 'Attach: '^MIAttach: ^[

Those are literal ctrl-A, ctrl-M, ctrl-[ (escape) in the macro. This 
means that I just type ctrl-A to commence an attachment and I get a file 
competion capable prompt to fill out the filename.


Oh yes, readline itself is a little shell script to invoke bash to use 
its GNU readline mode:


 https://bitbucket.org/cameron_simpson/css/src/tip/bin/readline

because it is so useful.

Hoping this improves your compose environment,
Cameron Simpson 

Re: order of sending mail and saving to fcc

[Cameron Simpson]

On 10Jun2019 11:56, Ben Boeckel  wrote:

On Mon, Jun 10, 2019 at 08:40:30 -0700, Felix Finch wrote:

[...slightly extreme failure modes elided...]
For me, the difference is that having extra Fcc copies is nowhere 
near

as bad as not having any.


If you're this paranoid, the only real fix is to have your editor save a
backup somewhere before handing it off to mutt in the first place
anyways. After all, mutt could segfault and lose it before the Fcc!


Hmm, that's already what I do.

As I've mentioned in the past my mutt compose mode actually fires off a 
distinct instance of my muttedit script, which uses mutt to compose and 
send in its own tmux session. With a distinctively named template file.


The innermost mutt invocation goes:

 rmafter "$filename" \
 mutt -e "set editor=$editor" -e 'unset signature' -H "$filename"

The rmafter script removes $filename after the subcommand finishes, but 
only if the subcommand succeeds. So a machine crash (or other lesser 
failure) leaves the filename around.


My boot stuff fires up individual tmux sessions with compose-and-send 
mutts in them for all of these distinctive files if they're lying 
around, providing a seamless resume mode post crash.


All this stuff is readily available in my code repo or for individual 
discussion here.


For interest, here's a section of my ps output for this very email 
message:


 cameron 52210   890 2444652   752   \_ /bin/sh ~/bin/rmafter 
~/tmp/muttedit.52169 mutt -e set editor=vim-flowed -e unset signature -H 
~/tmp/muttedit.52169
 cameron 52214 52210 2491372  4344 \_ mutt -e set editor=vim-flowed -e 
unset signature -H ~/tmp/muttedit.52169
 cameron 52396 52214 2504796 10808   \_ vim -c silent 1,/^$/s/ *$// -c set 
filetype=mail -c set formatoptions=waqj 
~/var/mutt/mutt-fleet-wk-wifi-501-52214-12499587601088287517
 cameron 52235   890 2449288   624   \_ tmux attach-session -t 
mutt-16jun2019-09_27-Re__order_of_sending_mail_and_saving_to_fcc

That's 4 lines commencing with "cameron", in case of folding.

Cheers,
Cameron Simpson 

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

I can only say, Erik wrote the answer I wanted to write.

@Kevin: The new change sounds very promising. Thank you for that
and all your work!

@Derek: I've read your mails in this thread, and I'm in no way
convinced.

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Derek Martin]

On Wed, Jun 12, 2019 at 09:31:53AM -0700, Kevin J. McCarthy wrote:
> On Tue, Jun 11, 2019 at 05:28:26PM -0500, Derek Martin wrote:
> >Obviously you don't need to listen to me
> 
> I do listen to you, Derek.  The whole buffer pool migration is a
> result of your recurring prods, and I will continue to work on that,
> likely through the next couple major releases.

:) [If I'm being honest, while that may be true, I don't actually
remember what you're talking about...]

[...]
> It's easy to conclude that objections to the change are overly
> paranoid or irrational,

That's not quite what I'm saying (see below)...

> but Mutt users in general *really* *care* about email.

Of course, I realize that, I'm one of them. :)

[...]
> It's evident, to me, that this change is extremely distressing to at
> least a subset of our users, who really care about having the
> message in their Fcc box before it gets sent out, regardless of the
> issues.

I think that's a mischaracterization.  Based on what people said when
they explained *why* they objected to the change, I think it's
actually the case that they just did not realize we accounted for
their concerns when we designed this change, and that in fact they
already can get exactly the end result they wanted from Fcc-first with
the current behavior (their e-mail is fully recoverable, save the case
of catastrophic system failure).  I think there was not much
opportunity for them to correct that misunderstanding until late in
the thread when I posted my detailed, hopefully succinct explanation
(and I also suspect at least some people who don't like this change
never read the explanation).

I think before you commit this, you should ask that anyone who still
objects go read my explanation if they have not, and then explain how
that does not cover their concerns.  My suspicion is that after doing
so, if there still are any objectors, their explanations will reveal
that they still don't actually understand how this works, and that
their understanding is the problem, not the actual behavior...  Unless
their objection is simply, "but I still want it to be written to Fcc
first for no particluar justifiable reason," because we clearly
decided that is not the right behavior. :)

[I also think if they still don't see that, you, as maintainer, should
know better and stick to the decision we made, but that is clearly a
more controvercial judgement. =8^)]

I think you could make the argument that this disruption is mutt-dev's
fault for not making an effort to communicate this change--one we knew
was contentious at the time we were discussing it--in advance to
mutt-users, so that people could get used to the idea before it hit,
or get involved in the discussion while it was happening, to their
satisfaction.  Perhaps we should do that more in the future...
Regardless, I still maintain we made the right decision here and the
alternative behavior provides nothing good that the current one does
not, but does indeed detract, and should be avoided.

I've said my piece.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpiEY94NQfAo.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Tue, Jun 11, 2019 at 05:28:26PM -0500, Derek Martin wrote:

Obviously you don't need to listen to me


I do listen to you, Derek.  The whole buffer pool migration is a result 
of your recurring prods, and I will continue to work on that, likely 
through the next couple major releases.


I also pay attention to other people's viewpoints, especially long time 
users.


Technically, the arguments for post-send fcc are fine.  I believe that, 
barring the most extreme cases, the pieces are there to prevent major 
loss (albeit sometimes with $tmpdir diving if mutt was killed).  It's 
now the default, and I don't have an intention of changing that.


It's easy to conclude that objections to the change are overly paranoid 
or irrational, but Mutt users in general *really* *care* about email. 
My interest is in empowering them, to the best of my ability.  I didn't 
make the change out of a desire to ruin their workflow, but moreso due 
to the technical problems of manipulating the message prior to sending.


It's evident, to me, that this change is extremely distressing to at 
least a subset of our users, who really care about having the message in 
their Fcc box before it gets sent out, regardless of the issues.


I can't give them exactly the old behavior, but I can _easily_ give them 
something approaching it.


Mutt already has tons of config vars, and Mutt is already a beast to 
learn how to configure


I agree.  However, to counter that I've tried to use and extend existing 
prefix namespaces, and more descriptive (if sometimes verbose) names. 
$forward_attachments for a forwarding option; $crypt_ and 
$crypt_protected_headers_ prefixes for the new Protected Headers; 
$imap_qresync; $history_remove_dups, etc.  The list grows longer, but in 
this way is (I hope) still possible to browse and understand what is 
changeable for a certain aspect of Mutt.


Regarding code complexity, the send code has already been simplified 
this release, partly because of the refactorings for the fcc-after 
change and Protected Headers introduction.  I would even say it's 
starting to approach readability ;-).  So, while I'm watchful for the 
proverbial straw on the camel's back, I'm still quite happy with the 
direction of the code and I'm not concerned about the impact of adding 
$fcc_before_send.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: order of sending mail and saving to fcc

[Derek Martin]

On Wed, Jun 12, 2019 at 05:20:02PM +1000, Erik Christiansen wrote:
> On 11.06.19 12:36, Derek Martin wrote:
> > I hesitate to go far as to say that if you think saving the message
> > first is the right behavior, you are simply wrong... but I'm
> > definitely thinking it. =8^)
> 
> I like your style, Derek. And respect that your use case works for you.
> What surprises me is the surplus of certitude which refuses to countenance
> a legitimate use case at variance with yours.

It's because it isn't, as I believe I've satisfactorily demonstrated.
The current behavior actually gets you literally everything you want.
It just does it differently than you expected... but it still does it.
There's no need for the Fcc first-behavior, and it is demonstrably
worse for more than one reason.  As such it should be excluded.  I can
not see how you could make any good argument to the contrary.

This is why mutt-dev rather quickly (by our standards regarding
contentious changes) agreed that the current behavior is the right
one.  We discussed it, came to a good conclusion about the solution,
it got implemented, and I think we should stick to that.  I am certain
that those who are objectiing are simply reacting negatively to
change, not realizing that it very clearly is a change for the better
which still gets them exactly what they wanted with Fcc-first
behavior, as the desire to do that went into that decision. That should
be clear to anyone who carefully read the discussion.

More code, more config variables, are inherently bad.  They increase
the burden of management of the code and the probgram, and increase
the learning curve for developers and for users.  A single variable is
obviously only a tiny marginal burden, but when the development
community does not actively resist the urge to add one for every
little triviality, you end up with hundreds of unnecessary such
things increasing complexity, the maintenance burden, the learning
curve, etc..  We have seen over the years that they can cause bugs
where they can interact in unexpected ways, breaking things.

TBH I think (and have long thought) Mutt already has way, way too many
config variables, probably a significant portion of which really don't
provide that much value and should really be removed.

So yes, I will continue to apply some resistance to adding new ones,
as Thomas used to do, for all the same reasons he did.  There should
be a significant positive change in Mutt that is provided by a new
config variable, to counteract that inherent negative, before adding
it is even considered, and in my estimation this one provides only
negative.  But I am (sadly) just rehashing the conversation that went
into the original decision to implement the current behavior in the
first place. :(

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpN7n_ZBZN_z.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 11.06.19 12:36, Derek Martin wrote:
> I hesitate to go far as to say that if you think saving the message
> first is the right behavior, you are simply wrong... but I'm
> definitely thinking it. =8^)

I like your style, Derek. And respect that your use case works for you.
What surprises me is the surplus of certitude which refuses to countenance
a legitimate use case at variance with yours.

If a new feature had been requested, then a higher bar to adding a
config option would have more merit. But where previously supported
behaviour had been removed, then it is only fair to other users for the
replacement behaviour to be optional only. Making the new behaviour the
default is in fact an (entirely acceptable) indulgence, I submit.

Erik

Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 11.06.19 13:45, Kevin J. McCarthy wrote:
> On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote:
> > Something like $fcc_order or $fcc_before_send is possible,
> 
> I've pushed a branch up to gitlab, kevin/fcc-before-send.  It adds
> $fcc_before_send, default unset.

Many grateful thanks, Kevin. That leaves Derek unimpacted, while
restoration of what we had protects older use cases. Nicolas' case of a
recipient having a copy of an email, but the sender not, can be a
serious problem. For the last half year I have been exchanging
(approval) stamped plans with authorities, consultants, engineers, and
now building contractors. As I've made design changes along the way, it
is very import to know which version of the plans has been received by
which recipient - and that a quote received here applies to a specific
plans version.

> The caveats to enabling are as mentioned: message manipulation is turned
> off, so $fcc_clear and $fcc_attach are ignored.  Another change (from before
> 1.12.0) is if the Fcc fails, you are prompted to retry or save to another
> mailbox, rather than returned to the compose menu.

The caveats are just fine in my use case. I had to look up $fcc_clear,
as I've never figured out any use for message signing. (The framing
carpenters would doubtless look at me oddly if I sent such stuff.)
And, oh goody!, $fcc_attach defaults to yes, so the plans and other attachments
will be saved.

Prompting for an Fcc retry seems ideal to me. To regain that, in place of
being dumped elsewhere, is another improvement. Mission accomplished -
Mutt much improved.

> The branch is off of stable, and is fairly minimal.  I planned on releasing
> 1.12.1 this weekend with some important fixes.  If those opposed to the new
> Fcc behavior think this is an acceptable alternative, I'll be glad to
> include it in that release.

That would be brilliant, Kevin. I'll look for it next week, then.
Many thanks, again, for the effort you're putting in to make mutt the
ideal MUA - despite a variety of use cases in the wild.

Erik

Re: order of sending mail and saving to fcc

[mutt]

Derek Martin wrote:

> On Tue, Jun 11, 2019 at 01:45:18PM -0700, Kevin J. McCarthy wrote:
> > On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote:
> > I've pushed a branch up to gitlab, kevin/fcc-before-send.  It adds
> > $fcc_before_send, default unset.
> 
> Obviously you don't need to listen to me, but I do want to state for
> the record that I'm opposed to this change going in.  I'm sure a lot
> of people will say, "Oh, it's just a config variable."  Those
> who've been paying attention will realize I've consistently argued
> against new config variables by default, over the last 20+ years, and
> I'll restate my unwavering reasoning for that here:
> 
> Mutt already has tons of config vars, and Mutt is already a beast to
> learn how to configure--I think it takes years for people to even
> realize all the features Mutt has that are configurable, nevermind
> getting a config that does all they want.  As such, (I believe) adding
> a new config variable is inherently bad, and should only be done when
> the good of having the alternative behaviors outweighs that bad.  Such
> cases clearly exist, and in those cases I don't argue against them.
> 
> This is not such a case.  I believe I have demonstrated in my last
> post in this thread, using sound logic, that the alternative behavior
> is not only never an improvement for any of the stated concerns, but
> inarguably worse for some of the relevant concerns, and as such clearly
> does not outweigh the bad of making Mutt that much more unweildy to
> understand and configre.  Therefore, the change should not be
> committed.
> 
> -- 
> Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02

I could be wrong (and I haven't read the patch so apologies if
I'm being silly) but I think that this patch might be too simple.
If all it does is perform the fcc before sending rather than
after sending, then the message that it saves isn't the message
that is subsequently sent (as explained earlier).

While I personally think that the copy in the /tmp directory
suffices in times of trouble (so far anyway), clearly not
everyone agrees. However, I would expect such people to still
want the actual message that is saved to be a true record of the
message that was sent (taking into account the other fcc-related
config options). At least, once it is successfully sent.

So, if something like this config option were to go ahead, it
should probably save the pre-sending version before sending and,
when the sending succeeds, replace the pre-sending version of the
message with the final version that was actually sent. Otherwise,
the saved message is only appropriate for re-sending but not
appropriate as a permanent record of what was sent. At least,
that's the impression I get from reading this thread.

But that sounds like messy behaviour if the pre-sending copy and
the post-sending copy are in the same file. If the patch is as I
imagine, the documentation should make it clear that turning the
new config option on means that the messages that are saved are
not identical to the messages as they were sent.

Having the pre-sending copy in a separate file would help keep
the code change simple but of course that will bring about yet
another config option to supply the name of the additional file
(like postponed). Another advantage of a separate file for
messages-that-are-in-the-process-of-being-sent is that the
presence of the file on disk is an indication of a failure to
send since the file would be deleted or emptied when the
post-sending copy is saved.

Note that I'm not recommending these changes, just pointing out
that using the new fcc_before_send shouldn't necessarily mean
that the sent box is no longer a true record of what was sent.

Again, apologies for wasting time if I've misunderstood things.
I've used mutt for decades but I'm no expert on its internals.

cheers,
raf

Re: order of sending mail and saving to fcc

[Derek Martin]

On Tue, Jun 11, 2019 at 01:45:18PM -0700, Kevin J. McCarthy wrote:
> On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote:
> I've pushed a branch up to gitlab, kevin/fcc-before-send.  It adds
> $fcc_before_send, default unset.

Obviously you don't need to listen to me, but I do want to state for
the record that I'm opposed to this change going in.  I'm sure a lot
of people will say, "Oh, it's just a config variable."  Those
who've been paying attention will realize I've consistently argued
against new config variables by default, over the last 20+ years, and
I'll restate my unwavering reasoning for that here:

Mutt already has tons of config vars, and Mutt is already a beast to
learn how to configure--I think it takes years for people to even
realize all the features Mutt has that are configurable, nevermind
getting a config that does all they want.  As such, (I believe) adding
a new config variable is inherently bad, and should only be done when
the good of having the alternative behaviors outweighs that bad.  Such
cases clearly exist, and in those cases I don't argue against them.

This is not such a case.  I believe I have demonstrated in my last
post in this thread, using sound logic, that the alternative behavior
is not only never an improvement for any of the stated concerns, but
inarguably worse for some of the relevant concerns, and as such clearly
does not outweigh the bad of making Mutt that much more unweildy to
understand and configre.  Therefore, the change should not be
committed.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpkyRaySVW0q.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote:

Something like $fcc_order or $fcc_before_send is possible,


I've pushed a branch up to gitlab, kevin/fcc-before-send.  It adds 
$fcc_before_send, default unset.


The caveats to enabling are as mentioned: message manipulation is turned 
off, so $fcc_clear and $fcc_attach are ignored.  Another change (from 
before 1.12.0) is if the Fcc fails, you are prompted to retry or save to 
another mailbox, rather than returned to the compose menu.


The branch is off of stable, and is fairly minimal.  I planned on 
releasing 1.12.1 this weekend with some important fixes.  If those 
opposed to the new Fcc behavior think this is an acceptable alternative, 
I'll be glad to include it in that release.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: order of sending mail and saving to fcc

[Derek Martin]

On Tue, Jun 11, 2019 at 08:11:33PM +0200, Nicolas Rachinsky wrote:
> > I hesitate to go far as to say that if you think saving the message
> > first is the right behavior, you are simply wrong... but I'm
> > definitely thinking it. =8^)
> 
> You might consider it wrong but I do not seem to be the only one
> thinking the old order is the correct one.

The argument is really simple.  The current solution solves your
problem, and mine.  Your solution solves only your problem.

> Considering how often I heard other people swear because they lost
> some sent mail, because their MUA crashed after sending and before
> storing it, this does just seem to be the wrong order.

I've been on this list since ~1995, and I've certainly heard people
express concern about the possibility of this, I can't say that
complaints about it actually happening have been particiluarly common.

To avoid going back and forth responding to quoted comments, I'll
instead summarize the concerns.  As best I can recall, there are 3:

1. If you DON'T save the message first, it is impossible to resend
   the message if sending fails.

2. If you DO save the message first, it can lead to misleading the
   user into thinking messages were sent, when they never were.

3. If you DO save the message first, it has negative repercussions in
   terms of cryptography, certain headers, etc. which will not be
   "correct" in the saved copy.

Ignoring the fact that #1 is hogwash anyway, because you certainly can
recreate a message that captures the sense of what you wrote the first
time, even if it is not word-for-word identical, the current solution
solves ALL of those concerns:

1. If sending fails, you are left at the compose menu, with a copy of
   your original message at the ready.  This is already a rare
   occurence for most people.  The most likely reason for sending to
   fail is you used an invalid address.  Every mail client has means
   to prevent that from happening if you are sending to someone you've
   already interacted with (address book, Mutt aliases, LDAP lookup,
   etc.), excepting the case where a previously valid address suddenly
   is not.

2. In the extraordinarily unlikely event that sending fails, AND you
   have a power outage while you are sitting at the compose menu, you
   still have a copy of at the very least your message text, sitting
   in the temporary file Mutt was going to use to send the message.
   And let's be extremely clear: THIS IS UNBELIEVABLY UNLIKELY. But it
   can happen.

3. In the equally extraordinarily unlikely event you can not remember
   who you were going to send the message to, you can set
   edit_headers=yes and Mutt will copy the headers into the temporary
   file, so you will not lose those either.  The notion is completely
   asinine, but it was raised as a concern, so, there you go.

4. Mutt will update encryption and any heaers added or changed by
   sending before it is copied to Fcc, so the file on disk will be as
   accurate a copy of your message as possible.

5. The Fcc copy will be created only once the message is actually
   sent, so there is no misleading of the user to think the message
   was sent when in fact it was not.

6. In the event creating the Fcc copy fails, Mutt will prompt you what
   to do, giving you the opportunity to deal with it however you like.
   In the mean time, the temporary copy still exists on disk, in the
   event of non-catastrophic system failure at this point.

7. In the event of actual catastrophic system failure, none of these
   things will save you.  Everyone appears to agree Mutt should not
   try to solve for this.

So, all of your concerns are addressed by the current behavior.  None
of the concerns that brougnt this behavior into being are addressed by
the behavior you want.  The only logical conclusion then, which I now
feel completely justified in saying, is that if you still want that
behavior, YOU ARE SIMPLY WRONG.


-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpwITz4RVDLQ.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[John Long]

Hi Mutters,

I haven't been following the thread but just to reply to a few points
with the names of the posters removed in order to focus on content
rather than who said what:

> >  It's not your
> > mail client's job to protect you from every conceibable system
> > failure which might cause data loss, nor should it be.  

If the issue is whether saving a copy or sending a copy happens first,
it seems obvious to me in most cases it doesn't matter.

But, as long as it is not any more difficult to do it correctly, maybe
we can use a journaling file system as a very rough analog. We expect
that any update gets committed to the journal before it gets committed
to the real file. If the lights go out, we replay the journal and the
file (depending on some minor details like what was journaled blah blah
blah) gets restored to a coherent state.

So it seems pretty clear that, if there are no overriding
considerations the first thing that ought to happen is that a local
copy of the email is saved to disk before the email is sent. Then the
email is sent, the the saved copy is marked sent. So in those rare
cases, there is a consistency mechanism that leaves things in a known
state.

> >  And for every other
> > case, the current behavior is the far superior one because it can
> > not mislead you into thinking you sent a message you did not,

The flagging operation of a saved message is much faster than saving
the whole message. So while it's true having a saved copy with no
status information attached to it could lead to this case you mention-
which is certainly bad, it seems to me that designing things so that
the saved email is created with an unsent flag and after the email is
sent the flag on the sent copy is set to sent is easy and make sense.

> It is quite easy to have a setup, where I can verify if the mail was
> sent if there is any doubt.

Yes, and the above paragraph would seem to be one way.

> I'm relying on my mail client, that it safely stores a message of
> every message sent.  

This seems reasonable to me. I understand that means nothing here on
the list and probably not much elsewhere ;) but at the same time, free
speech is good and no electrons were harmed in creating this email.

> > I hesitate to go far as to say that if you think saving the message
> > first is the right behavior, you are simply wrong... but I'm
> > definitely thinking it. =8^)  

I go with the opposite opinion. I think there is an obvious precedent
here in journaling filesystems, which are vitally concerned with data
and/or metadata consistency. It does not necessarily mean that an email
client has to be coded the same way or that the same level of rigor is
appropriate, but in the absence of compelling reasons to the contrary
the question arises, why not then?

> You might consider it wrong but I do not seem to be the only one
> thinking the old order is the correct one.

Old stuff is usually better in my opinion. The problem is that most
people seem to think you have to keep throwing features out there when
what they had was perfectly fine at some point. And most Linux distros
make it very hard never to update some app or middleware.

When I ran Slackware I got around this by building everything from
source and then never updating apps I was happy with. But there is a
lot of home sysadm work involved with that and of course some risk of
losing out on security updates for various and never-ending screwups.
In the end, package-managed distros make it very easy to get the
latest, but not necessarily the best.

/jl

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Derek Martin  [2019-06-11 12:47 -0500]:
> Not only that, but I neglected the fact that if the send fails, the
> file your editor produced in order for it to be passed to Mutt will
> still be on disk, so you do IN FACT still have a copy of the message.

I did just (using my old mutt) set sendmail to killall -9 mutt. The
temporay file that stayed on my disk did contain my text. But there
was no other information (recipients, subject, attachments).

So if the tmpdir survives, not everything is lost. But the mail as
such is lost.

> That is, barring catastrophic system failure, which no mail client
> will ever save you from.

Data loss in case of a catastrophic system failure is not the thing
to argue about. The thing to argue about is, which case of events
is made catastrophic by mutt.

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Derek Martin  [2019-06-11 12:36 -0500]:
> On Tue, Jun 11, 2019 at 10:04:25PM +1000, Erik Christiansen wrote:
> > In the event that send fails, the local copy is essential for a resend
> > attempt. No ifs, no buts, no maybes. I'm at a loss to imagine any
> > scenario in which mutt should risk inability to write that Fcc, through a
> > hang-up or conniption during sending.
> 
> This argument seems like complete nonsense to me...  if the send
> fails, you're left back at the compose screen.  If by some
> unbelievable coincidence the send fails AND you lose power before you
> can do something about it, this is NO DIFFERENT than if the power went
> out just before you finished composing the message.

It is different. In one case nobody has my mail. In the other case
the recipient might have it, but the sender does not.

>  It's not your
> mail client's job to protect you from every conceibable system failure
> which might cause data loss, nor should it be.

Of course it is not its job. If my computer melts to a blob of
something, that is not mutt's problem.

But it is mutt's job to make it easier (or even possible without
arcane workarounds) to avoid more or less simple problems. Diskless
workstations loosing their connectivity at the worst moment. Crashing
systems. ...

>  And for every other
> case, the current behavior is the far superior one because it can not
> mislead you into thinking you sent a message you did not, and does not
> lead to the various encoding issues Kevin mentioned separately. 

It is quite easy to have a setup, where I can verify if the mail was
sent if there is any doubt.

The new behavior does create a situation that makes it much more
likely to create a situation where I have to ask e.g. a client for
a mail I sent to him. That would be quite embarrasing without some
good explanation (like a major event, like a house which burned
down).

> But also, just because the message failed to send, your ideas and the
> impetus for writing them down didn't vanish.  Your brain is the
> back-up.

Ahm. No. Any temporary information copied into the mail is just not in
my brain.

Anything where the exact wording is important cannot be reproduced
(so the recipient gets two mails that are different, and the sender
only knows one of them).

>  In the event that the message in question is the unusual
> combination of lengthy, complex, and important enough that the pain of
> re-composing it from scratch is somehow prohibitive, then you damn
> well better be composing it using a word processor that takes frequent
> snapshots of your document as you compose, and then sending it as an
> attachment (or as a link, or by doing a text conversion, or...
> whatever)--not relying on your mail client to preserve it.

I'm relying on my mail client, that it safely stores a message of
every message sent.  

> And by the
> way even then, you can't guarantee 100% that you won't lose the data.
> Your hard disk could explode, say due to a lightning strike.  No
> software can't protect you from that.  At a certain point such
> considerations become completely ridiculous.

Yeah. But that is no reason to not protect from things it can protect
me easily from by just storing the message before sending it.

I do not want to protect mutt my mail from a supernova in my hard
disk. 

I consider it quite absurd to use such an argument:
"Why should I ever call fsync? The computer may be struck by lightning
and might get lost completely."


> I hesitate to go far as to say that if you think saving the message
> first is the right behavior, you are simply wrong... but I'm
> definitely thinking it. =8^)

You might consider it wrong but I do not seem to be the only one
thinking the old order is the correct one.

Considering how often I heard other people swear because they lost
some sent mail, because their MUA crashed after sending and before
storing it, this does just seem to be the wrong order.


Nicolas

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Derek Martin  [2019-06-11 12:16 -0500]:
> On Mon, Jun 10, 2019 at 11:24:11AM +0200, Nicolas Rachinsky wrote:
> > * Jack M  [2019-06-04 10:20 -0500]:
> > > On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote:
> > > > The other one (mail sent, but no local copy)
> > > 
> > > Why would this situation would ever occur?
> > 
> > A power failure at the wrong moment. A crash at the wrong moment. ...
> > 
> > These things tend to happen only at wrong moments.
> 
> But the failure mode of the current behavior is superior:  With the
> old way, you look in Fcc and see the message was sent, so you don't
> send it again (unless you're unusually paranoid, maybe).

But I cannot create the same message again. 

> With the current way, you see there's no message in Fcc, and you send
> it again.

If I do not have the message, how do I send it again?

> And by the way, changes like this one don't happen in a vaccuum.  The
> change was discussed on mutt-dev at some length when it happened, and
> it was eventually agreed that the new behavior is the right one.


Thanks to Kevin J. McCarthy who referred me to it. I habe read it, but
I did not find any convincing argument. 

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Derek Martin]

On Tue, Jun 11, 2019 at 12:36:00PM -0500, Derek Martin wrote:
> But also, just because the message failed to send, your ideas and the
> impetus for writing them down didn't vanish.  Your brain is the
> back-up.

Not only that, but I neglected the fact that if the send fails, the
file your editor produced in order for it to be passed to Mutt will
still be on disk, so you do IN FACT still have a copy of the message.
That is, barring catastrophic system failure, which no mail client
will ever save you from.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpScU1faFRBm.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Derek Martin]

On Tue, Jun 11, 2019 at 10:04:25PM +1000, Erik Christiansen wrote:
> In the event that send fails, the local copy is essential for a resend
> attempt. No ifs, no buts, no maybes. I'm at a loss to imagine any
> scenario in which mutt should risk inability to write that Fcc, through a
> hang-up or conniption during sending.

This argument seems like complete nonsense to me...  if the send
fails, you're left back at the compose screen.  If by some
unbelievable coincidence the send fails AND you lose power before you
can do something about it, this is NO DIFFERENT than if the power went
out just before you finished composing the message.  It's not your
mail client's job to protect you from every conceibable system failure
which might cause data loss, nor should it be.  And for every other
case, the current behavior is the far superior one because it can not
mislead you into thinking you sent a message you did not, and does not
lead to the various encoding issues Kevin mentioned separately. 

But also, just because the message failed to send, your ideas and the
impetus for writing them down didn't vanish.  Your brain is the
back-up.  In the event that the message in question is the unusual
combination of lengthy, complex, and important enough that the pain of
re-composing it from scratch is somehow prohibitive, then you damn
well better be composing it using a word processor that takes frequent
snapshots of your document as you compose, and then sending it as an
attachment (or as a link, or by doing a text conversion, or...
whatever)--not relying on your mail client to preserve it.  And by the
way even then, you can't guarantee 100% that you won't lose the data.
Your hard disk could explode, say due to a lightning strike.  No
software can't protect you from that.  At a certain point such
considerations become completely ridiculous.

I hesitate to go far as to say that if you think saving the message
first is the right behavior, you are simply wrong... but I'm
definitely thinking it. =8^)

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpa9q0F0H3H8.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Derek Martin]

On Mon, Jun 10, 2019 at 11:24:11AM +0200, Nicolas Rachinsky wrote:
> * Jack M  [2019-06-04 10:20 -0500]:
> > On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote:
> > > The other one (mail sent, but no local copy)
> > 
> > Why would this situation would ever occur?
> 
> A power failure at the wrong moment. A crash at the wrong moment. ...
> 
> These things tend to happen only at wrong moments.

But the failure mode of the current behavior is superior:  With the
old way, you look in Fcc and see the message was sent, so you don't
send it again (unless you're unusually paranoid, maybe).

With the current way, you see there's no message in Fcc, and you send
it again.

It's better to receive the same e-mail twice, than to never receive it
at all, if it contains important content.

And by the way, changes like this one don't happen in a vaccuum.  The
change was discussed on mutt-dev at some length when it happened, and
it was eventually agreed that the new behavior is the right one.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpJPD9wD7jeR.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Tue, Jun 11, 2019 at 10:04:25PM +1000, Erik Christiansen wrote:
If developers insist on the backwards method for themselves, then is an 
fcc_order config option possible for the benefit of users seeking the 
old reliability?


Something like $fcc_order or $fcc_before_send is possible, but with the 
caveat that, pre-send, the message would be saved exactly as sent.  That 
is, $fcc_clear and $fcc_attach would be ignored.


Mutt now defaults $pgp_self_encrypt, so if $pgp_default_key is set an 
encrypted message would still be readable.


Would that be an acceptable alternative?

--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 10.06.19 11:20, Nicolas Rachinsky wrote:
> * "Kevin J. McCarthy"  [2019-06-04 09:44 -0700]:
> > On Tue, Jun 04, 2019 at 12:30:59PM +0200, Nicolas Rachinsky wrote:
> > > Does anybody know the reason of this change?
> > 
> > The most recent discussion on mutt-dev was
> > .  The issue is
> > contentious, and there are arguments on both sides.
> 
> Thank you for the reference.
> 
> > In this case, the comments by active developers seemed to be in consensus
> > that prompting if Fcc fails afterwards is a reasonable compromise.
> 
> Ok, so I will replace $sendmail by something that saves the mail
> first, since not having a local copy of a sent mail (for an easily
> avoidable reason) is just not acceptable here. :(

In the event that send fails, the local copy is essential for a resend
attempt. No ifs, no buts, no maybes. I'm at a loss to imagine any
scenario in which mutt should risk inability to write that Fcc, through a
hang-up or conniption during sending.

We have backups for our files for a reason - recovery is impossible
without them. To deliberately create a potentially irrecoverable
situation in mutt is incomprehensible. If developers insist on the
backwards method for themselves, then is an fcc_order config option
possible for the benefit of users seeking the old reliability?

Mind you, I can avoid the problem by remaining on my old mutt, and never
updating.

Erik

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Ben Boeckel  [2019-06-10 11:56 -0400]:
> If you're this paranoid, the only real fix is to have your editor save a
> backup somewhere before handing it off to mutt in the first place
> anyways. After all, mutt could segfault and lose it before the Fcc!

There is one big difference. If mutt crashes before saving the mail to
fcc, nobody has one. So this avoids the problem with sent mail without
any local copy.


I have a related question: When does mutt unlink attached files (with
unlink set)? Before sending, between sending and fccing or after
fccing?


Nicolas

Re: order of sending mail and saving to fcc

[Felix Finch]

On 20190610, Ben Boeckel wrote:

On Mon, Jun 10, 2019 at 08:40:30 -0700, Felix Finch wrote:

As other(s) have mentioned, power failure, cat jumping on keyboard.  I
have also had sends hang seemingly forever, and the only way forward
is tokill the tmux session.  Then I have no Fcc copy.  I can root
around /tmp to find the message, but I shouldn''t have to.


Doe mutt do the right fsync dance for power failure anyways? How would a
cat jumping on the keyboard possibly a failure mode *anyone* can *plan*
for? (I've had mine swat the power strip switch before which is at least
intersecting with other failure modes.)


Cat could hit 'q' and then you will have neither Fcc nor send copy.


Killing the tmux session seems overkill. You couldn't kill just the
pane holding mutt? Tmux being completely unresponsive sounds like either
a sendmail or tmux bug.


Of course this is what I meant.  And when ^C and ^\ do nothing, I consider it
time to kill the tmux session / pane.  I suppose I could open a new terminal
session, in tmux (because tmux is still responding), and killall mutt, but the
distinction is insignificant.


For me, the difference is that having extra Fcc copies is nowhere near
as bad as not having any.



If you're this paranoid, the only real fix is to have your editor save a
backup somewhere before handing it off to mutt in the first place
anyways. After all, mutt could segfault and lose it before the Fcc!


If it is paranoid to consider the ramifications of a change, then the
implementors of said change were also paranoid.

Please be less snarky and more serious.  You do your arguments no favors.

--
   ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
 GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

Re: order of sending mail and saving to fcc

[Ben Boeckel]

On Mon, Jun 10, 2019 at 08:40:30 -0700, Felix Finch wrote:
> As other(s) have mentioned, power failure, cat jumping on keyboard.  I
> have also had sends hang seemingly forever, and the only way forward
> is tokill the tmux session.  Then I have no Fcc copy.  I can root
> around /tmp to find the message, but I shouldn''t have to.

Doe mutt do the right fsync dance for power failure anyways? How would a
cat jumping on the keyboard possibly a failure mode *anyone* can *plan*
for? (I've had mine swat the power strip switch before which is at least
intersecting with other failure modes.)

Killing the tmux session seems overkill. You couldn't kill just the
pane holding mutt? Tmux being completely unresponsive sounds like either
a sendmail or tmux bug.

> For me, the difference is that having extra Fcc copies is nowhere near
> as bad as not having any.

If you're this paranoid, the only real fix is to have your editor save a
backup somewhere before handing it off to mutt in the first place
anyways. After all, mutt could segfault and lose it before the Fcc!

--Ben

Re: order of sending mail and saving to fcc

[Felix Finch]

On 20190610, Felix Finch wrote:

Perhaps a compromise is to Fcc as a draft file first, then send, then move the 
draft Fcc file to its permanent location.


Not so clever with IMAP draft files.  It would have to be a special local file, 
and mutt would have to look for it on start.

--
   ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
 GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

Re: order of sending mail and saving to fcc

[Felix Finch]

On 20190604, Jack M wrote:

The other one (mail sent, but no local copy)


Why would this situation would ever occur?


As other(s) have mentioned, power failure, cat jumping on keyboard.  I have 
also had sends hang seemingly forever, and the only way forward is tokill the 
tmux session.  Then I have no Fcc copy.  I can root around /tmp to find the 
message, but I shouldn''t have to.

For me, the difference is that having extra Fcc copies is nowhere near as bad 
as not having any.

Another factor is that the Fcc is much less likely to fail than the send.

Perhaps a compromise is to Fcc as a draft file first, then send, then move the 
draft Fcc file to its permanent location.

--
   ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
 GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Francesco Ariis  [2019-06-04 19:52 +0200]:
> Hello Grant,
> 
> On Tue, Jun 04, 2019 at 04:46:50PM -, Grant Edwards wrote:
> > On 2019-06-04, Jack M  wrote:
> > 
> > > The reason (or *a* reason) is that the old way led to the following
> > > situation: Fcc first, then try to send, something weird happens, but
> > > the user has no idea whether the mail was actually sent or not
> > 
> > How could the user not know? If the send fails, mutt prints an error
> > message and stays on the message compose screen.  It's pretty
> > obvious...
> 
> I have the bad habit of pressing 'q' (exit to menu) after sending.
> Also terminal corruption or similar events: you can't be sure whether
> the message was actually sent.

With the new order this behaviour might lead to a sent mail without
a local copy. If you miss the failure to send, you might as well
miss the failure to fcc.

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Jack M  [2019-06-04 10:20 -0500]:
> On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote:
> > The other one (mail sent, but no local copy)
> 
> Why would this situation would ever occur?

A power failure at the wrong moment. A crash at the wrong moment. ...

These things tend to happen only at wrong moments.

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* "Kevin J. McCarthy"  [2019-06-04 09:44 -0700]:
> On Tue, Jun 04, 2019 at 12:30:59PM +0200, Nicolas Rachinsky wrote:
> > Does anybody know the reason of this change?
> 
> The most recent discussion on mutt-dev was
> .  The issue is
> contentious, and there are arguments on both sides.

Thank you for the reference.

> In this case, the comments by active developers seemed to be in consensus
> that prompting if Fcc fails afterwards is a reasonable compromise.

Ok, so I will replace $sendmail by something that saves the mail
first, since not having a local copy of a sent mail (for an easily
avoidable reason) is just not acceptable here. :(

have a nice day
Nicolas

Re: order of sending mail and saving to fcc

[Grant Edwards]

On 2019-06-04, Jack M  wrote:
> On Tue, June 4, 2019 10:46 am, Grant Edwards wrote:
>> On 2019-06-04, Jack M  wrote:
>>
>>
>>> The reason (or *a* reason) is that the old way led to the following
>>> situation: Fcc first, then try to send, something weird happens, but
>>> the user has no idea whether the mail was actually sent or not
>>
>> How could the user not know?
>
> Very easily.
>
>> If the send fails, mutt prints an error message and stays on the message
>> compose screen.
>
> The part starting with "and" is not always true, though.  I've been bitten
> several times by mutt flashing an error message so quickly that I can't
> read it, and then immediately showing an empty inbox with a completely
> different error message about a lost connection to the IMAP server.

Then that's a bug, and it needs to be fixed.  If you try to send a
message and it fails, there's no way you should leave the message
compose screen.  Changing the order of the send/fcc operations to try
to hide problems like that seems odd.

--
Grant

Re: order of sending mail and saving to fcc

[Jack M]

On Tue, June 4, 2019 10:46 am, Grant Edwards wrote:
> On 2019-06-04, Jack M  wrote:
>
>
>> The reason (or *a* reason) is that the old way led to the following
>> situation: Fcc first, then try to send, something weird happens, but
>> the user has no idea whether the mail was actually sent or not
>
> How could the user not know?

Very easily.

> If the send fails, mutt prints an error message and stays on the message
compose screen.

The part starting with "and" is not always true, though.  I've been bitten
several times by mutt flashing an error message so quickly that I can't
read it, and then immediately showing an empty inbox with a completely
different error message about a lost connection to the IMAP server.

-jack

Re: order of sending mail and saving to fcc

[Francesco Ariis]

Hello Grant,

On Tue, Jun 04, 2019 at 04:46:50PM -, Grant Edwards wrote:
> On 2019-06-04, Jack M  wrote:
> 
> > The reason (or *a* reason) is that the old way led to the following
> > situation: Fcc first, then try to send, something weird happens, but
> > the user has no idea whether the mail was actually sent or not
> 
> How could the user not know? If the send fails, mutt prints an error
> message and stays on the message compose screen.  It's pretty
> obvious...

I have the bad habit of pressing 'q' (exit to menu) after sending.
Also terminal corruption or similar events: you can't be sure whether
the message was actually sent.

I see the points made by Nicolas Rachinsky too.

Re: order of sending mail and saving to fcc

[Grant Edwards]

On 2019-06-04, Jack M  wrote:

> The reason (or *a* reason) is that the old way led to the following
> situation: Fcc first, then try to send, something weird happens, but
> the user has no idea whether the mail was actually sent or not

How could the user not know? If the send fails, mutt prints an error
message and stays on the message compose screen.  It's pretty
obvious...

> and so has to contact the recipient.  (The Fcc'd copy contains no
> information to tell the user whether the mail was sent.)  This was
> not a rare occurrence.

-- 
Grant Edwards   grant.b.edwardsYow! I have many CHARTS
  at   and DIAGRAMS..
  gmail.com

Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Tue, Jun 04, 2019 at 12:30:59PM +0200, Nicolas Rachinsky wrote:

Does anybody know the reason of this change?


The most recent discussion on mutt-dev was 
.  The issue is 
contentious, and there are arguments on both sides.


In this case, the comments by active developers seemed to be in 
consensus that prompting if Fcc fails afterwards is a reasonable 
compromise.


Another reason was the implementation of Protected Headers.  The current 
mechanism supporting $fcc_attach and $fcc_clear already went through 
gymnastics to transform the message, save to Fcc, and back out those 
changes for sending.  The introduction of Protected Headers made backing 
out changes substantially more difficult without breaking cryptographic 
signatures.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: order of sending mail and saving to fcc

[Jack M]

On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote:
> Hallo,
>
>
> I just noted the entry in UPDATING:
> ! Fcc now occurs after sending a message.  If the fcc fails, mutt will
> prompt to try again, or to try another mailbox.
>
> This seems to be:
> https://gitlab.com/muttmua/mutt/commit/e106487b1f4ebe7128982486accec11ac6f
> 54b5c
>
>
> Does anybody know the reason of this change?

The reason (or *a* reason) is that the old way led to the following
situation: Fcc first, then try to send, something weird happens, but the
user has no idea whether the mail was actually sent or not and so has to
contact the recipient.  (The Fcc'd copy contains no information to tell
the user whether the mail was sent.)  This was not a rare occurrence.

The new way is a million times better.  If something weird happens during
the sending attempt, the user now is aware of this and can decide what to
do.  No misleading Fcc copy is put in a mailbox.  The user can give up,
save a copy of the message to a local folder, etc.

> The other one (mail sent, but no local copy)

Why would this situation would ever occur?

-jack

Re: order of sending mail and saving to fcc

[Ben Boeckel]

On Tue, Jun 04, 2019 at 12:30:59 +0200, Nicolas Rachinsky wrote:
> I considered the previous order (save to fcc, then send the mail)
> always the correct one. If anything bad happens (network connectivity
> failing (in case of imap), computer crashing,...), it seems to
> produce the better outcome.

I'm in favor of the change. If sending does fail, mutt leaves you at the
composition window (attach?) to do a postponement, try sending again,
etc. The problem I'd see is that if sending failed due to some network
error, I'd have 3 or 4 copies of the email by the time it finally gets
fixed in the relevant mailbox that I had to delete manually.

> The situation where I have the mail locally, but it was not sent can
> easily recovered on my side. The other one (mail sent, but no local
> copy) cannot be always recovered without contacting the recipient.

You still have the copy, but it is just saved after sending. Or are you
worried about Fcc failing after being sent?

--Ben

order of sending mail and saving to fcc

[Nicolas Rachinsky]

Hallo,

I just noted the entry in UPDATING:
  ! Fcc now occurs after sending a message.  If the fcc fails, mutt will prompt
to try again, or to try another mailbox.

This seems to be:
https://gitlab.com/muttmua/mutt/commit/e106487b1f4ebe7128982486accec11ac6f54b5c

Does anybody know the reason of this change?

I considered the previous order (save to fcc, then send the mail)
always the correct one. If anything bad happens (network connectivity
failing (in case of imap), computer crashing,...), it seems to
produce the better outcome.

The situation where I have the mail locally, but it was not sent can
easily recovered on my side. The other one (mail sent, but no local
copy) cannot be always recovered without contacting the recipient.

Thank you in advance.

Nicolas

Help with mutt - sending mail with body as html with attachments

[Cary Lewis]

I am trying to use mutt to send emails with the following characteristics:

1. Mail whose content is html - I can do this by specify -e my_hdr
Content-Type: text/html, and formatting the message as a pure html
file, e.g. no extra headers.

2.  Mail whose content is html, but must all support attachments.

I also need be able to send emails from the command line.

There is a further constraint that I have to use mull v. 1.2.5.1i

It does not seem possible to use mutt to achieve this. If I specify
the -e my_hdr ... and the -a option within the same email, the
ultimate header received in the email at the recipient contains

Content-Type: text/html

which isn't correct, mutt should have used:

Content-Type: multipart/mixed; boundary=45Z9DzgjV8m4Oswq

If I don't specify the -e, then the section with the message, which is
html, is formatted as this:

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

If I try to invoke mutt like this:

-e my_hdr Content-Type: text/html \
-e my_hdr Mime-Version: 1.0 \
-e my_hdr Content-Type: multipart/mixed; boundary=\IS0zKkzwUGydFO0o\ \
-e my_hdr Content-Disposition: inline \

mutt throws an error

Error in command line: boundary=IS0zKkzwUGydFO0o: unknown commandS

If I try formatting a complete email and use the -H option with mutt,
mutt strips out the multipart/mixed boundary line. Why?

So, is it possible to specify the Content-Type: header inside a
multipart mime email with mutt?

Thanks for any help.

Re: Help with mutt - sending mail with body as html with attachments

[P. Mazart]

Hello Cary,

 1. Mail whose content is html - I can do this by specify -e my_hdr
 Content-Type: text/html, and formatting the message as a pure html
 file, e.g. no extra headers.

I’m not entirely sure but I feel that it’s not too ideal 
to set the Content-Type via a my_hdr setting.

Maybe you can set a custom header like “x-change-to-html”, and apply a
hook running an edit-type macro if this header is present?
Sounds more native to me. 

Regards,
P.M.

Re: Help with mutt - sending mail with body as html with attachments

[P. Mazart]

Hello again,

 Maybe you can set a custom header like “x-change-to-html”, and apply a
 hook running an edit-type macro if this header is present?
 Sounds more native to me. 

Maybe this is even easier:
mutt -e 'set content_type=text/html' -s 'Subject of your msg' 
spamreceipi...@server.gov -a attachment.pdf  message.html

Regards,
P.M.

Sending mail to mutt-users from gmail ?

[Max Rydahl Andersen]

Hey,

I got all html stuff disabled on gmail webui but when I try post here
via gmail my emails are being rejected as being html mail.

Anyone know how to avoid that for the times where I don't have access to mutt ?

/max

Re: Sending mail foreach

[Christian Ebert]

* Dmitry Bogatov on Friday, March 01, 2013 at 16:04:26 +0400
 Is it any convient way or macro to send a bunch of emails 
 to a list or recepients without letting them know each other?
 
 Of course, I can leave out To: field and put them all in BCC(to
 get filtered) or use mutt from bash script, but it is not too
 convient.

You can send with a To: field without address:

To: All-my-friends: ;

Works like To: undisclosed-recipients: ;

-- 
So dacht ich. Nächstens mehr.
_HÖLDERLIN:  HYPERION_  --- http://www.blacktrash.org/hyperion

Sending mail foreach

[Dmitry Bogatov]

Is it any convient way or macro to send a bunch of emails 
to a list or recepients without letting them know each other?

Of course, I can leave out To: field and put them all in BCC(to
get filtered) or use mutt from bash script, but it is not too
convient.

-- 
Best regards, Dmitry Bogatov kact...@gnu.org,
Free Software supporter and netiquette guardian.
Html mail and proprietary format attachments are forwarded to /dev/null.

Re: Sending mail foreach

[Marco]

On 2013–03–01 Dmitry Bogatov wrote:

Sorry, I don't have an answer, but an additional question.

 Is it any convient way or macro to send a bunch of emails 
 to a list or recepients without letting them know each other?
 
 Of course, I can leave out To: field and put them all in BCC(to
 get filtered)

Is it possible to leave the To: field empty and only use Bcc? In the
former mail client I used this failed, so I had to place my own
address in the To: field and the group addresses in the Bcc: field.
I never tried to use an empty To: with mutt.

Marco


signature.asc
Description: Digital signature

Re: Sending mail foreach

[Patrick Shanahan]

* Dmitry Bogatov kact...@gnu.org [03-01-13 07:06]:
 Is it any convient way or macro to send a bunch of emails 
 to a list or recepients without letting them know each other?
 
 Of course, I can leave out To: field and put them all in BCC(to
 get filtered) or use mutt from bash script, but it is not too
 convient.

use aliases, make the list in your alias file and assign them all to as a
group to a single alias.

then bcc to the alias you have chosen.

read about aliases in the man file, man mutt
-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  HOG # US1244711
http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2
http://en.opensuse.org   openSUSE Community Member
Registered Linux User #207535@ http://linuxcounter.net

Re: Sending mail foreach

[Jeremy Kitchen]

On Fri, Mar 01, 2013 at 04:04:26PM +0400, Dmitry Bogatov wrote:
 Is it any convient way or macro to send a bunch of emails 
 to a list or recepients without letting them know each other?
 
 Of course, I can leave out To: field and put them all in BCC(to
 get filtered)

Lack of the recipient in the headers is not a case for dropping mail.
Maybe some spam filters will score it a bit higher, but if it were to
simply reject all mail because of that, then no mailing list would work.

Just use BCC.

-Jeremy


pgpIQKaMyFrRr.pgp
Description: PGP signature

Re: Sending Mail to the IMAP Sent Folder

[Ian Barton]

On 28/06/12 01:53, William Yardley wrote:

On Wed, Jun 27, 2012 at 06:46:21PM +0100, Ian Barton wrote:

imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX
set copy = yes
set record = imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX.Sent

I have also tried the following:

set record = +Sent
set record = Sent
set record = INBOX.Sent


Have you tried something like:
## May need to adjust this depending on your Dovecot settings and how
## you have your prefix defined.
set folder = imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX
set record = +Sent



No that doesn't work either:) My folders are all nested under INBOX and 
I don't have prefix defined. I have several IMAP accounts, so the 
settings are defined in folder-hook. Here is what I have at the moment 
for the folder-hook


mailboxes imaps://i...@wilkesley.net@mail2.wilkesley.net:993

account-hook imaps://i...@wilkesley.net@mail2.wilkesley.net:993 'set
imap_user=username'

account-hook imaps://i...@wilkesley.net@mail2.wilkesley.net:993 'set

imap_pass=password'

folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set 
from=i...@manor-farm.org'


folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set
folder=imaps://i...@wilkesley.net@mail2.wilkesley.net:993/INBOX'

account-hook imaps://i...@wilkesley.net@mail2.wilkesley.net:993 'set copy 
= yes'


folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set 
spoolfile=+INBOX'


folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set 
record = +INBOX.Sent'


Note I have tried both +Sent and +INBOX.Sent

Ian.

Re: [Solved] Sending Mail to the IMAP Sent Folder

[Ian Barton]

On 28/06/12 08:13, Ian Barton wrote:

On 28/06/12 01:53, William Yardley wrote:

On Wed, Jun 27, 2012 at 06:46:21PM +0100, Ian Barton wrote:

imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX
set copy = yes
set record = imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX.Sent

I have also tried the following:

set record = +Sent
set record = Sent
set record = INBOX.Sent


Have you tried something like:
## May need to adjust this depending on your Dovecot settings and how
## you have your prefix defined.
set folder = imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX
set record = +Sent



No that doesn't work either:) My folders are all nested under INBOX and
I don't have prefix defined. I have several IMAP accounts, so the
settings are defined in folder-hook. Here is what I have at the moment
for the folder-hook

mailboxes imaps://i...@wilkesley.net@mail2.wilkesley.net:993

account-hook imaps://i...@wilkesley.net@mail2.wilkesley.net:993 'set
imap_user=username'

account-hook imaps://i...@wilkesley.net@mail2.wilkesley.net:993 'set

imap_pass=password'

folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set
from=i...@manor-farm.org'

folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set
folder=imaps://i...@wilkesley.net@mail2.wilkesley.net:993/INBOX'

account-hook imaps://i...@wilkesley.net@mail2.wilkesley.net:993 'set copy
= yes'

folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set
spoolfile=+INBOX'

folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set
record = +INBOX.Sent'

Note I have tried both +Sent and +INBOX.Sent

Ian.


Finally found the problem. I had an unset record that was causing the 
problem. For Google the following works for me:


folder-hook imaps://i...@wilkesley.net@mail2.wilkesley.net:993 'set copy 
= yes'


folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set 
spoolfile=+INBOX'


folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set 
folder = imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX/'


folder-hook 'imaps://i...@wilkesley.net@mail2.wilkesley.net:993.*' 'set 
record = +Sent'



Ian.

Sending Mail to the IMAP Sent Folder

[Ian Barton]

I am using Dovecot and am having trouble sending copies of sent mail to 
my Sent folder. Relevant bits of my .muttrc:


imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX
set copy = yes
set record = imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX.Sent

I have also tried the following:

set record = +Sent
set record = Sent
set record = INBOX.Sent

So what obvious thing am I missing?

Ian.

Re: Sending Mail to the IMAP Sent Folder

[William Yardley]

On Wed, Jun 27, 2012 at 06:46:21PM +0100, Ian Barton wrote:
 imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX
 set copy = yes
 set record = imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX.Sent
 
 I have also tried the following:
 
 set record = +Sent
 set record = Sent
 set record = INBOX.Sent

Have you tried something like:
## May need to adjust this depending on your Dovecot settings and how
## you have your prefix defined.
set folder = imaps://i...@wilkesley.net@mail2.wilkesley.net/INBOX
set record = +Sent

w

Re: sending mail directly to MX based on To: addr

[Matthias Apitz]

El día Friday, September 17, 2010 a las 04:44:46PM +0200, Luciano Rocha 
escribió:

  which put the mail to the local queue and the sendmail queue runner
  later to the SMTP smarterhost (of my ISP). So far so good. In some cases
  I would send the mail directly with SMTP to the destination, based on
  the To: addr. Any idea how I could configure this in mutt? Thanks in
  advance
 
 I use a send-hook:
 send-hook . unset smtp_url
 send-hook @example.com set smtp_url=smtp://example.com/

Luciano,

Do you know if mutt logs somewhere the SMTP dialog with the remote
server? I found nothing in the docs about...

Thx

matthias

-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e g...@unixarea.de - w http://www.unixarea.de/

Re: sending mail directly to MX based on To: addr

[Michael Williams]

On 20 Sep 2010, at 16:36, Matthias Apitz wrote:
 Do you know if mutt logs somewhere the SMTP dialog with the remote
 server? I found nothing in the docs about...

Run mutt -d2. Server chat is then logged in ~/.muttdebug*. Increase the 
number 2 to larger numbers for more detail.

(This assumes mutt was compiled with --enable-debug, i.e. mutt -v includes 
+DEBUG.)

Re: sending mail directly to MX based on To: addr

[Luciano Rocha]

On Fri, Sep 17, 2010 at 04:07:42PM +0200, Matthias Apitz wrote:
 
 Hello,
 
 I have configured in ~/.muttrc:
 
 set sendmail=/usr/sbin/sendmail -oi -oem -f g...@unixarea.de -t
 
 which put the mail to the local queue and the sendmail queue runner
 later to the SMTP smarterhost (of my ISP). So far so good. In some cases
 I would send the mail directly with SMTP to the destination, based on
 the To: addr. Any idea how I could configure this in mutt? Thanks in
 advance

I use a send-hook:
send-hook . unset smtp_url
send-hook @example.com set smtp_url=smtp://example.com/

-- 
0/0


pgpjUHZDq4EP7.pgp
Description: PGP signature

Sending mail from the command line

[steve]

Hi list,

I'm trying:

mutt -s test m...@example.com  my_file.txt


But the message is not sent:

0 (null)
m...@example.com: 0 (null)
Error sending message, child exited 70 (internal error).
Could not send the message


Sending messages works fine from within mutt.

I guess it's because my linux username is not converted to a correct From: 
header.

How can one tell mutt to use m...@example.com as the sender? Didn't find
it in the man page.


Thanks,
steve

Re: Sending mail from the command line

[Tim Tebbit]

steve wrote:

Hi list,

I'm trying:

mutt -s test m...@example.com  my_file.txt


But the message is not sent:

0 (null)
m...@example.com: 0 (null)
Error sending message, child exited 70 (internal error).
Could not send the message


Sending messages works fine from within mutt.

I guess it's because my linux username is not converted to a correct From: 
header.

How can one tell mutt to use m...@example.com as the sender? Didn't find
it in the man page.


Thanks,
steve



cat myfile.txt | mail -s 'test' m...@example.com

Re: Sending mail from the command line

[Andreas Kneib]

* Tim Tebbit 

 cat myfile.txt | mail -s 'test' m...@example.com

Useless Use of Cat Award? :)

Andreas

Re: Sending mail from the command line

[Tim Tebbit]

Andreas Kneib wrote:

Useless Use of Cat Award? :)

Andreas



Or of a reply?

To the OP I only glanced at your attempt without reading the rest of 
your message. Having just previously been reading the ubuntu-user slop I 
also mistakenly assumed I was still reading that list.  Looking at it 
again, I think you need to look at the -a option.


mutt -s 'test' -a myfile.txt -- some...@gmail.com

As for configuring what address will be sending the mail.  That is on 
the .muttrc file.  You can setup a second .muttrc_work or whatever and 
use -F .muttrc_work to use the new configuration.

Re: Sending mail from the command line

[Ionel Mugurel Ciobica]

On 21-07-2009, at 11h 41'44, steve wrote about Sending mail from the command 
line
 Hi list,
 
 I'm trying:
 
 mutt -s test m...@example.com  my_file.txt
 
 
 But the message is not sent:
 
 0 (null)
 m...@example.com: 0 (null)
 Error sending message, child exited 70 (internal error).
 Could not send the message
 


Try some of those:

 echo | mutt -s test -a my_file.txt m...@example.com 
 cat my_file.txt | mutt -s test m...@example.com
 echo -e text text text\nmore text | mutt -s test m...@example.com
 ...  etc.

Ionel

Re: Sending mail from the command line

[Andreas Kneib]

* steve

 But the message is not sent:

 0 (null)
 m...@example.com: 0 (null)
 Error sending message, child exited 70 (internal error).
 Could not send the message

Which MTA?

Andreas

Re: Sending mail from the command line

[steve]

 I'm trying:

 mutt -s test m...@example.com  my_file.txt


 But the message is not sent:

 0 (null)
 m...@example.com: 0 (null)
 Error sending message, child exited 70 (internal error).
 Could not send the message


 Sending messages works fine from within mutt.

 I guess it's because my linux username is not converted to a correct From: 
 header.

 How can one tell mutt to use m...@example.com as the sender? Didn't find
 it in the man page.


 Thanks,
 steve


 cat myfile.txt | mail -s 'test' m...@example.com


No. This will send a mail to m...@example.com (which is alright) but I
want to send a mail to m...@example.com from account t...@example.com (I'm
sorry I mixed things up in my previous message). The question is how can
I specify t...@example.com on the command line?

Re: Sending mail from the command line

[steve]

  But the message is not sent:
 
  0 (null)
  m...@example.com: 0 (null)
  Error sending message, child exited 70 (internal error).
  Could not send the message
 
 Which MTA?
 
esmtp 

Re: Sending mail from the command line

[steve]

 To the OP I only glanced at your attempt without reading the rest of  
 your message. Having just previously been reading the ubuntu-user slop I  
 also mistakenly assumed I was still reading that list.  Looking at it  
 again, I think you need to look at the -a option.

 mutt -s 'test' -a myfile.txt -- some...@gmail.com

No, -a option is to attach a file to the message, I don't want that. I
want to specify the sender on the command line.

 As for configuring what address will be sending the mail.  That is on  
 the .muttrc file.  You can setup a second .muttrc_work or whatever and  
 use -F .muttrc_work to use the new configuration.


This is a good idea I think. Thank you.

Steve

[SOLVED] Sending mail from the command line

[steve]

Le 21-07-2009, à 13:37:50 +0200, steve (dl...@bluewin.ch) a écrit :

 Lignes : 19
 
  To the OP I only glanced at your attempt without reading the rest of  
  your message. Having just previously been reading the ubuntu-user slop I  
  also mistakenly assumed I was still reading that list.  Looking at it  
  again, I think you need to look at the -a option.
 
  mutt -s 'test' -a myfile.txt -- some...@gmail.com
 
 No, -a option is to attach a file to the message, I don't want that. I
 want to specify the sender on the command line.
 
  As for configuring what address will be sending the mail.  That is on  
  the .muttrc file.  You can setup a second .muttrc_work or whatever and  
  use -F .muttrc_work to use the new configuration.
 
 
 This is a good idea I think. Thank you.

Following this idea, this worked for me :

$ cat mutt-work

set sendmail=/usr/sbin/sendmail -v -X /tmp/esmtp.log
set hostname=example.com
set use_domain
set use_envelope_from

Then

mutt -s test -F /path/to/mutt-work -- to_some...@example  myfile.txt


Have a nice day,
Steve

Re: Sending mail from the command line

[Ionel Mugurel Ciobica]

On 21-07-2009, at 13h 27'04, steve wrote about Re: Sending mail from the 
command line
 
  cat myfile.txt | mail -s 'test' m...@example.com
 
 
 No. This will send a mail to m...@example.com (which is alright) but I
 want to send a mail to m...@example.com from account t...@example.com (I'm
 sorry I mixed things up in my previous message). The question is how can
 I specify t...@example.com on the command line?


cat myfile.txt | mail -s test -F /tmp/.muttrc m...@example.com

where /tmp/.muttrc contains:

send-hook . 'my_hdr From: Alternative user t...@example.com'

Or a smarter way is to add a formula to send always to m...@example.com
as from t...@example.com something like this (in your regular .muttrc
file):

send-hook '~C ^...@example.com$' 'my_hdr From: Alternative user name 
t...@example.com'

and then use mutt as usual (without -F).


I suggest also to read about use_envelope_from variable from mutt.
Also about the option -f of sendmail or similar MTA.



Ionel

Re: How can I know if error happens when sending mail?

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wednesday, June  3 at 05:20 PM, quoth Chengqi(Lars) Song:
-code
lars:~$ less .bin/msmtp-wrap
#! /bin/bash

msmtp $*
if [ $? != 0 ]
then
  gxmessage -wrap -fg red -bg black -default okay -center MSMTP: `tail -1 
 ~/.getmail/msmtp.log`
fi
--

I have a few minor suggestions.

First, you probably don't want to use $*, but you probably want to use 
$@ instead, to preserve any arguments that might have spaces in 
them.

Secondly, you don't have to use the $? variable, you can simply do 
this:

 #!/bin/bash

 if ! msmtp $@ ; then
 gxmessage -wrap -fg red -bg black -default okay -center \
 MSMTP: `tail -1 ~/.getmail/msmtp.log`
 fi

~Kyle
- -- 
No nation is permitted to live in ignorance with impunity.
-- Thomas Jefferson
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKJpNwAAoJECuveozR/AWe81oP/iZrn4ytub1+DXDtAhM93jLh
ZWOEK2wNZpAOSscM+C3VjwlnQaQHPRCpYHBIVTZz8I0QUqZaKOYoNMMfCP03r5Ao
DAb3tShzoFkB9mXYCepzPdrI6sbyozdj/gkRGDyZjEe9MzDVp6KJo3iuYJXbP4Q4
UNN533HoiI/mXLNxV2x5NVFmqCn8t+kwdV2WqM0Le0+IDgVpVom0F0ZNu2F8dKAY
ncizdYFsBeVjgBuDVjzo6X6OD+uPGyYNZzW6UpiSL9iqEmkrJ40pa0fjC5uv3VvV
SRyh8vfdkGXjMfF4iASnDUxXMBpdLCAVw1F3kn9nviudauyVbor2ythDY8armrNG
v4wtb+TF5FhYaLUC95UpCdUSNX5Q+I+OUmq5UtyLHTx612vw0W9ZsfTci/7+du4t
lHgujaHElAIy2SGMyp6PP1KoSrLp+znTVJBAvW5hv8pV/J0PfaRbV8UZwPNwdWHU
Q3/TsKuApwxi9jPoWTAdyKyd1cYy7aJhpHvSrM2WELURuzQmwyNNpVFgKjB50iWz
RPiFhknBZXvvrPWEmBAQS2XJbjmwGNIak4queg601UsIn+Trgot9gt94hbSFtdlU
DlUWlzUazN7FA4MgYjdZUSd8DXwGUVUR428pFlSF1/ccYkblZp1Z2UXeA59KpdPc
ZDFrJ/3aihKnkX7CBt4h
=Q2YN
-END PGP SIGNATURE-

Re: How can I know if error happens when sending mail?

[Chengqi(Lars) Song]

thanks, your suggestion is applied :)
On Wed, 03 Jun 2009, Kyle Wheeler wrote:

 On Wednesday, June  3 at 05:20 PM, quoth Chengqi(Lars) Song:
 -code
 lars:~$ less .bin/msmtp-wrap
 #! /bin/bash
 
 msmtp $*
 if [ $? != 0 ]
 then
   gxmessage -wrap -fg red -bg black -default okay -center MSMTP: `tail -1 
  ~/.getmail/msmtp.log`
 fi
 --
 
 I have a few minor suggestions.
 
 First, you probably don't want to use $*, but you probably want to use 
 $@ instead, to preserve any arguments that might have spaces in 
 them.
 
 Secondly, you don't have to use the $? variable, you can simply do 
 this:
 
  #!/bin/bash
 
  if ! msmtp $@ ; then
  gxmessage -wrap -fg red -bg black -default okay -center \
  MSMTP: `tail -1 ~/.getmail/msmtp.log`
  fi
 
 ~Kyle
 -- 
 No nation is permitted to live in ignorance with impunity.
 -- Thomas Jefferson

Re: sending mail via exchange

[Chris]

On Tue, Jun 2, 2009 at 3:55 PM, Matthias Apitz g...@unixarea.de wrote:
 El día Tuesday, June 02, 2009 a las 03:45:14PM +1000, Chris escribió:

 I have configured Mutt 1.5.16 to check mail via MS Exchange (IMAP). I
 can see all my mail boxes, query for email addresses from Exchange
 etc. However, I cannot send mail from mutt via Exchange.

 Do I need to use external program like msmtp or is there any
 configuration I can do in .muttrc to send mails as well.

 Thanks.

 Can you talk SMTP to the Exchange at all? What does give you the
 following command:

 $ telnet brain.dead.exchange.no 25

 (substitute brain.dead.exchange.no by the DNS or IP addr of the server).

telnet to port 25 works. It's open.

Re: How can I know if error happens when sending mail?

[JP Bruns]

Kyle [02.Jun.2009 04:42]:


On Tuesday, June  2 at 10:09 AM, quoth Chengqi(Lars) Song:

indeed can not interrupt mutt, but can send a local mail to myself instead i 
think ...


Actually, now that I think about it... you might be able to use 
xdialog (or something similar) to display an alert message, rather 
than send another email.


Is there anything for console-only systems? Mutt is a great piece of software, 
but - in my eyes - is lacking this important feature. Would it be possible to 
take the return-code/-message of the *smtp program and display that on the 
status-line (or the message(?)-line)? What about creating a mail-reply to that 
message on its own with the sending-error as body and mark that as new mail?

How do other people deal with this issue?


JP

Re: sending mail via exchange

[Rocco Rutte]

Hi,

* Chris wrote:

 Do I need to use external program like msmtp or is there any
 configuration I can do in .muttrc to send mails as well.

With 1.5.16 you have the choice. For using built-in SMTP support:

 http://dev.mutt.org/doc/manual.html#smtp

Rocco


pgpnxkaZz3zGu.pgp
Description: PGP signature

Re: How can I know if error happens when sending mail?

[Nicolas Rachinsky]

* JP Bruns emailj...@gmx.de [2009-06-02 10:37 +0200]:
 Is there anything for console-only systems? Mutt is a great piece of 
 software, but - in my eyes - is lacking this important feature. Would it be 
 possible to take the return-code/-message of the *smtp program and display 
 that on the status-line (or the message(?)-line)? What about creating a 
 mail-reply to that message on its own with the sending-error as body and mark 
 that as new mail?

Please wrap your lines.

The manual says about sendmail_wait:
   Note that if you specify a value other than 0, the output of the child
   process will be put in a temporary file. If there is some error, you
   will be informed as to where to find the output.

So it seems, the feature you want is already there.

Nicolas
-- 
http://www.rachinsky.de/nicolas

Re: How can I know if error happens when sending mail?

[Chengqi(Lars) Song]

yeah, the manual says we will be informed, but in fact i tested and didnt see 
any information about
the error.

lars

On Tue, 02 Jun 2009, Nicolas Rachinsky wrote:

 * JP Bruns emailj...@gmx.de [2009-06-02 10:37 +0200]:  Is there anything 
 for console-only
 systems? Mutt is a great piece of software, but - in my eyes - is lacking 
 this important
 feature. Would it be possible to take the return-code/-message of the *smtp 
 program and display
 that on the status-line (or the message(?)-line)? What about creating a 
 mail-reply to that message
 on its own with the sending-error as body and mark that as new mail?  

Please wrap your lines.  The manual says about sendmail_wait: Note that if you 
specify a value other
than 0, the output of the child process will be put in a temporary file. If 
there is some error, you
will be informed as to where to find the output.  So it seems, the feature you 
want is already
there.  Nicolas -- http://www.rachinsky.de/nicolas

Re: How can I know if error happens when sending mail?

[JP Bruns]

Nicolas [02.Jun.2009 16:09]:


* JP Bruns emailj...@gmx.de [2009-06-02 10:37 +0200]:

Is there anything for console-only systems? Mutt is a great piece of software, 
but - in my eyes - is lacking this important feature. Would it be possible to 
take the return-code/-message of the *smtp program and display that on the 
status-line (or the message(?)-line)? What about creating a mail-reply to that 
message on its own with the sending-error as body and mark that as new mail?


Please wrap your lines.


Oh, I am sorry, I forgot to change it back after sending some
config-files some time ago. Mutt was still wrapping it for me, so I
didn't think about it :( My bad.


The manual says about sendmail_wait:
  Note that if you specify a value other than 0, the output of the child
  process will be put in a temporary file. If there is some error, you
  will be informed as to where to find the output.


That is strange because I have it set to -1 and do not see any message
as to where the output is. Might it be that this messages is only shown
for a short time or that it will be clicked away while I continue using
mutt? I will try changing it to a positive value, waiting one second is
still acceptable compared to the time a 3MB email takes.


JP

How can I know if error happens when sending mail?

[Chengqi(Lars) Song]

Hi,

I'm using msmtp to send mail. I've set sendmail_wait=-1 in .muttrc to make 
sending mail not blocking. But there comes a problem. If any error happens when 
sending mail, I will not aware about it. And sometimes it cause trouble to my 
work. How can I solve this problem? I need to be told if error happens in 
sending mail. 

Thanks
Lars

Re: How can I know if error happens when sending mail?

[Markus Maria Miedaner]

 Hi,
 
 I'm using msmtp to send mail. I've set sendmail_wait=-1 in .muttrc to make 
 sending mail not blocking. But there comes a problem. If any error happens 
 when sending mail, I will not aware about it. And sometimes it cause trouble 
 to my work. How can I solve this problem? I need to be told if error happens 
 in sending mail. 
 
 Thanks
 Lars
 
Ciao Lars,

you can specify a log_file for msmtp by adding the following to each 
account_setting in your .msmtprc

logfile ~/msmtp.log

all you need to do then is to watch the file after sending an email. it may 
take a few seconds before the logentries are written for each mail.
for notification you could add a logwatcher to automate this process.

cheers,
markus

___
Nur bis 31.05.: WEB.DE FreeDSL Komplettanschluss mit DSL 6.000 Flatrate
und Telefonanschluss für 17,95 Euro/mtl.! http://produkte.web.de/go/02/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: How can I know if error happens when sending mail?

[Chengqi(Lars) Song]

Hi Markus,

Thanks for the method you provided. In fact I thought of that too. But still 
it's not efficient to watch that log file everytime after sending a mail. 
Logwatch should work but still I wonder if there is any easier way to do this 
job. Could we possible wrap msmtp in a shell script, and in the script call 
pass all parameters to msmtp and watch consequential results? Have anybody done 
that?

Thanks
Lars

On Mon, 01 Jun 2009, Markus Maria Miedaner wrote:

 
  Hi,
  
  I'm using msmtp to send mail. I've set sendmail_wait=-1 in .muttrc to make 
  sending mail not blocking. But there comes a problem. If any error happens 
  when sending mail, I will not aware about it. And sometimes it cause 
  trouble to my work. How can I solve this problem? I need to be told if 
  error happens in sending mail. 
  
  Thanks
  Lars
  
 Ciao Lars,
 
 you can specify a log_file for msmtp by adding the following to each 
 account_setting in your .msmtprc
 
 logfile ~/msmtp.log
 
 all you need to do then is to watch the file after sending an email. it may 
 take a few seconds before the logentries are written for each mail.
 for notification you could add a logwatcher to automate this process.
 
 cheers,
 markus
 
 ___
 Nur bis 31.05.: WEB.DE FreeDSL Komplettanschluss mit DSL 6.000 Flatrate
 und Telefonanschluss f?r 17,95 Euro/mtl.! http://produkte.web.de/go/02/
 



- End forwarded message -

Re: How can I know if error happens when sending mail?

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tuesday, June  2 at 12:08 AM, quoth Chengqi(Lars) Song:
 Thanks for the method you provided. In fact I thought of that too. 
 But still it's not efficient to watch that log file everytime after 
 sending a mail. Logwatch should work but still I wonder if there is 
 any easier way to do this job. Could we possible wrap msmtp in a 
 shell script, and in the script call pass all parameters to msmtp 
 and watch consequential results? Have anybody done that?

Sure, you could do that, but what then? What should the shell script 
do if sending the message fails? It can't interrupt your mutt 
session...

~Kyle
- -- 
The government of the United States is not in any sense founded on the 
Christian Religion.
   -- US Treaty with Tripoly, 1797
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIVAwUBSiQDbCuveozR/AWeAQgFlBAAq4E2F77muy+XnqnwEzCTcJ1UYAGjmV33
S5jT0LYfPLHo2OZs/GGhe9Om9H7gsSaqw4tCN/12TF9vD2AX8kl4p6UekrN8ZgWq
lihZrACoMK2lOsFhbaPxZQfwe3nulKti03U8ojgDjKPUsfajf7Ai9Yjp2EbiNTpN
1aSpvARGlsUXdqfwKjGfKmCV5cqGRVn/eIJ+Lo9FTCfI90TRgAdMmpIsir9QgHmf
9WUbhEUdyAcVCCEE+hcoJT0n3qR2AT8cn4h7WQZQQZb6C+BUQaiBwD+nS6+wBqz/
rqLEzITfcQbuNtsL4jgVJW7rhzP6dEsUonTsJblzjIQmotWGLEyWMH5cpgpuQXXw
8faosqwhQpYqMqT0jZV2Mov181aHmZ450MuLVh+Big7qAq/6hBnu3umM9kjWUzyI
Hs+RZFRh7LVX9qGvVCF1ENBSix+RdbncZEtsalDXT8AbG3a25CJgpFgyyXFtNGeQ
yWA1CNBWfBWSo53Rhle14PPrFRJcrdCwWZWbuampNvDxEW479PPRikZM7XBd5Z1Y
9zMnmymgDTeAV94FD1GHruu4DtdgG6iLIJRISP+ou91L/NArrgU5uaS4xJrDGdcp
4qPGZi8nLfJs+KhsfN551qI19faErDzP1IgxSvI4VyViu20q6s60WySx7aw1zmDs
ob8lOvnEMTA=
=MNds
-END PGP SIGNATURE-

Re: How can I know if error happens when sending mail?

[Chengqi(Lars) Song]

indeed can not interrupt mutt, but can send a local mail to myself instead i 
think ...

lars

On Mon, 01 Jun 2009, Kyle Wheeler wrote:

 On Tuesday, June  2 at 12:08 AM, quoth Chengqi(Lars) Song:
  Thanks for the method you provided. In fact I thought of that too. 
  But still it's not efficient to watch that log file everytime after 
  sending a mail. Logwatch should work but still I wonder if there is 
  any easier way to do this job. Could we possible wrap msmtp in a 
  shell script, and in the script call pass all parameters to msmtp 
  and watch consequential results? Have anybody done that?
 
 Sure, you could do that, but what then? What should the shell script 
 do if sending the message fails? It can't interrupt your mutt 
 session...
 
 ~Kyle
 -- 
 The government of the United States is not in any sense founded on the 
 Christian Religion.
-- US Treaty with Tripoly, 1797

Re: How can I know if error happens when sending mail?

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tuesday, June  2 at 10:09 AM, quoth Chengqi(Lars) Song:
indeed can not interrupt mutt, but can send a local mail to myself instead i 
think ...

Actually, now that I think about it... you might be able to use 
xdialog (or something similar) to display an alert message, rather 
than send another email.

~Kyle
- -- 
If I had only known, I would have been a locksmith.
-- Albert Einstein
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIVAwUBSiSReiuveozR/AWeAQiHIw//SKb7daI7zOn95WikrVm2zelzvzAlb/A/
xTw2SgxmJvP8xQ833U4NgbY+x7llAuIOZB4NZYRaepgTUvNUG5PRLxzTqr+XG0Aj
sr3jlO+inDsjPPRZzuIdrXBlyndaEU2jGuPQwXUfAo2h7/EwucIhQ295I/lswcE0
SzCjJ/qO1XolDc+B9GvF9rM2g2vaznIA8/CO3kRSYBq7zvA3X/aW3CNwEQpQ50CQ
JMDLSxUv7veYjIwLJuYYXT7Ed9d7KkNBnwlHf9xcLByxmElFyuqbUGYM5mbj3YA7
Y8zgaR+Wu15sx0vjw7PAima9OM+7OJhJzu4kTUx2gLkwlPgVu3ikH+5kgVXyGBUs
flRRcbAvOrX8NfAgnWkp5nlF2OTQloE58gg7MMvjabjqeuwHlmqf7q4hKSQzRz2C
33mHQ9fCArQB1M8Ac2lCs2DRwXQurjk8HOLWTHR9YgApYVoJapwUf+gNklWbvKGc
rFeCpZKz8EmNI6Qx9rg30w+dRSkrBBZoUXyXcejFiJ6S4OZKdHEB+zot4hoHvZmu
ENIKtQSXo5bCQOLZc+7IdOtXI4gtnvg7Uk8CNsnEAV4UVSUR8ypjq/kGpApOhxMe
OvjTvmZHZuJm2eQtu8Agw/zSgDlNzP+31Y8Ort24LlbGRMk9VBheNT484aB+6QtQ
WQmQ4xbTkRA=
=vlFF
-END PGP SIGNATURE-

sending mail via exchange

[Chris]

I have configured Mutt 1.5.16 to check mail via MS Exchange (IMAP). I
can see all my mail boxes, query for email addresses from Exchange
etc. However, I cannot send mail from mutt via Exchange.

Do I need to use external program like msmtp or is there any
configuration I can do in .muttrc to send mails as well.

Thanks.

Re: sending mail via exchange

[Matthias Apitz]

El día Tuesday, June 02, 2009 a las 03:45:14PM +1000, Chris escribió:

 I have configured Mutt 1.5.16 to check mail via MS Exchange (IMAP). I
 can see all my mail boxes, query for email addresses from Exchange
 etc. However, I cannot send mail from mutt via Exchange.
 
 Do I need to use external program like msmtp or is there any
 configuration I can do in .muttrc to send mails as well.
 
 Thanks.

Can you talk SMTP to the Exchange at all? What does give you the
following command:

$ telnet brain.dead.exchange.no 25

(substitute brain.dead.exchange.no by the DNS or IP addr of the server).

matthias

-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e g...@unixarea.de - w http://www.unixarea.de/
People who hate Microsoft Windows use Linux but people who love UNIX use 
FreeBSD.

error about TLS when sending mail

[Chengqi(Lars) Song]

Hi,

I always get this message when sending mail:

  Apr 30 20:24:19 host=smtp.abc.com tls=on auth=on user=lars from=l...@abc.com 
recipients=larsgg.tosp...@abc.com errormsg='TLS handshake failed: The Diffie 
Hellman prime sent by the server is not acceptable (not long enough).' 
exitcode=EX_PROTOCOL

the domain name is substituded to abc.com for privacy.

When I use other msmtp servers there is nothing wrong. only the 'abc.om' has 
this problem. How can I fix it?

lars

Re: error about TLS when sending mail

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday, April 30 at 09:12 PM, quoth Chengqi(Lars) Song:
Hi,

I always get this message when sending mail:

  Apr 30 20:24:19 host=smtp.abc.com tls=on auth=on user=lars from=l...@abc.com 
 recipients=larsgg.tosp...@abc.com errormsg='TLS handshake failed: The Diffie 
 Hellman prime sent by the server is not acceptable (not long enough).' 
 exitcode=EX_PROTOCOL

the domain name is substituded to abc.com for privacy.

When I use other msmtp servers there is nothing wrong. only the 'abc.om' has 
this problem. How can I fix it?

Sounds like it's their problem, not yours. If you can force your mail 
server to avoid using TLS when talking to them, then you can probably 
send mail, but ... their TLS setup is basically broken. Not much you 
can do other than avoid it.

~Kyle
- -- 
The optimist thinks this is the best of all possible worlds. The 
pessimist fears it is true.
   -- J. Robert Oppenheimer
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkn5tKgACgkQBkIOoMqOI14SdQCeIiwJXfdW16T6JMft9FiBG++o
76oAoISCYGJqMUel7jooDlaS5HhWvJ4d
=tGUj
-END PGP SIGNATURE-

Re: error about TLS when sending mail

[Christian Ebert]

* Chengqi(Lars) Song on Thursday, April 30, 2009 at 21:12:12 +0800
 I always get this message when sending mail:
 
  Apr 30 20:24:19 host=smtp.abc.com tls=on auth=on user=lars from=l...@abc.com 
 recipients=larsgg.tosp...@abc.com errormsg='TLS handshake failed: The Diffie 
 Hellman prime sent by the server is not acceptable (not long enough).' 
 exitcode=EX_PROTOCOL
 
 the domain name is substituded to abc.com for privacy.
 
 When I use other msmtp servers there is nothing wrong. only the 'abc.om' has 
 this problem. How can I fix it?
   ^
In case this means that you're using msmtp, this is an msmtp and
not a mutt question ;-) I seem to remember encountering something
similar when using msmtp though.

From man msmtp:

--tls-min-dh-prime-bits=[bits]
 Set or unset minimum bit size of the Diffie-Hellman (DH) prime. See the
 tls_min_dh_prime_bits command below.

[...]


tls_min_dh_prime_bits [bits]
 Set or unset the minimum number of Diffie-Hellman (DH) prime bits that 
msmtp will accept for
 TLS sessions. The default is set by the TLS library and can be selected by 
using an empty
 argument to this command. Only lower the default (for example to 512 bits) 
if there is no
 other way to make TLS work with the remote server.


Setting

tls_min_dh_prime_bits 512

in my msmtprc helped me overcome the problem, perhaps the same
holds true for you.

c
-- 
  Was heißt hier Dogma, ich bin Underdogma!
[ What the hell do you mean dogma, I am underdogma. ]
_F R E E_  _V I D E O S_  http://www.blacktrash.org/underdogma/
  http://www.blacktrash.org/underdogma/index-en.html

Re: error about TLS when sending mail

[Chengqi(Lars) Song]

but Outlook works well with that server... can mutt ignores that error msg?

lars
On Thu, 30 Apr 2009, Kyle Wheeler wrote:

 On Thursday, April 30 at 09:12 PM, quoth Chengqi(Lars) Song:
 Hi,
 
 I always get this message when sending mail:
 
   Apr 30 20:24:19 host=smtp.abc.com tls=on auth=on user=lars 
  from=l...@abc.com recipients=larsgg.tosp...@abc.com errormsg='TLS handshake 
  failed: The Diffie Hellman prime sent by the server is not acceptable (not 
  long enough).' exitcode=EX_PROTOCOL
 
 the domain name is substituded to abc.com for privacy.
 
 When I use other msmtp servers there is nothing wrong. only the 'abc.om' has 
 this problem. How can I fix it?
 
 Sounds like it's their problem, not yours. If you can force your mail 
 server to avoid using TLS when talking to them, then you can probably 
 send mail, but ... their TLS setup is basically broken. Not much you 
 can do other than avoid it.
 
 ~Kyle
 -- 
 The optimist thinks this is the best of all possible worlds. The 
 pessimist fears it is true.
-- J. Robert Oppenheimer

Re: error about TLS when sending mail

[Chengqi(Lars) Song]

it works, great!

thanks
lars
On Thu, 30 Apr 2009, Christian Ebert wrote:

 * Chengqi(Lars) Song on Thursday, April 30, 2009 at 21:12:12 +0800
  I always get this message when sending mail:
  
   Apr 30 20:24:19 host=smtp.abc.com tls=on auth=on user=lars 
  from=l...@abc.com recipients=larsgg.tosp...@abc.com errormsg='TLS handshake 
  failed: The Diffie Hellman prime sent by the server is not acceptable (not 
  long enough).' exitcode=EX_PROTOCOL
  
  the domain name is substituded to abc.com for privacy.
  
  When I use other msmtp servers there is nothing wrong. only the 'abc.om' 
  has this problem. How can I fix it?
^
 In case this means that you're using msmtp, this is an msmtp and
 not a mutt question ;-) I seem to remember encountering something
 similar when using msmtp though.
 
 From man msmtp:
 
 --tls-min-dh-prime-bits=[bits]
  Set or unset minimum bit size of the Diffie-Hellman (DH) prime. See the
  tls_min_dh_prime_bits command below.
 
 [...]
 
 
 tls_min_dh_prime_bits [bits]
  Set or unset the minimum number of Diffie-Hellman (DH) prime bits that 
 msmtp will accept for
  TLS sessions. The default is set by the TLS library and can be selected 
 by using an empty
  argument to this command. Only lower the default (for example to 512 
 bits) if there is no
  other way to make TLS work with the remote server.
 
 
 Setting
 
 tls_min_dh_prime_bits 512
 
 in my msmtprc helped me overcome the problem, perhaps the same
 holds true for you.
 
 c
 -- 
   Was hei?t hier Dogma, ich bin Underdogma!
 [ What the hell do you mean dogma, I am underdogma. ]
 _F R E E_  _V I D E O S_  http://www.blacktrash.org/underdogma/
   http://www.blacktrash.org/underdogma/index-en.html

Problems with sending mail via Gmail

[Niels Rasmussen]

Hi all

I have a problem with sending mails through Gmail smpt server.

everytime I'm sending a mail, mutt freezes and writes this below:

 Approving (LOGIN) ...Segmentation fault

I have this in my .muttrc:

 set smtp_url='smtp://my username@smtp.gmail.com:587/'
 set smtp_pass='my password'

What is wrong here ??

/Niels
Registered Linux user #133791
Get counted at http://counter.li.org

Problems with sending mail via Gmail

[Niels Rasmussen]

I think I got it :)

This was missing in my .muttrc

folder-hook . my_hdr From: My Emailadress.com

-- 
/Niels
Registered Linux user #133791
Get counted at http://counter.li.org

Re: Problems with sending mail via Gmail

[Gary Johnson]

On 2008-11-26, Niels Rasmussen wrote:
 Hi all

 I have a problem with sending mails through Gmail smpt server.

 everytime I'm sending a mail, mutt freezes and writes this below:

  Approving (LOGIN) ...Segmentation fault

 I have this in my .muttrc:

  set smtp_url='smtp://my username@smtp.gmail.com:587/'
  set smtp_pass='my password'

 What is wrong here ??

On 2008-11-26, Niels Rasmussen wrote:
 I think I got it :)
 
 This was missing in my .muttrc
 
 folder-hook . my_hdr From: My Emailadress.com

I encountered the same problem when using mutt's internal SMTP 
client and sending a message in batch mode.  In my case, one bug in 
mutt was leaving the from address undefined and another bug was 
causing a segmentation fault (a null pointer dereference) when the 
from address was undefined.  Both bugs have been fixed in the latest 
development version of mutt-1.5.18, available from the mercurial 
repository.

Regards,
Gary

Blocking when sending mail

[Chengqi(Lars) Song]

Hello,

Mutt is blocked when sending mail. It takes a long time if the mail is
large. Is it possible to send mail in a non-blocking mode?

Thanks
Lars

Re: Blocking when sending mail

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday, November 19 at 03:37 PM, quoth Chengqi(Lars) Song:
 Mutt is blocked when sending mail. It takes a long time if the mail 
 is large. Is it possible to send mail in a non-blocking mode?

Yes, unless you're using the built-in smtp support. If you're using an 
external mail program (such as sendmail, postfix, or msmtp), then you 
just need to set $sendmail_wait to some low non-zero number. However, 
if you're using the built-in smtp support (read: $smtp_url), then no, 
there's no way to send mail in a non-blocking way. Mutt isn't 
multithreaded, and so can't really do multiple things at the same 
time.

~Kyle
- -- 
There can be but little liberty on earth while men worship a tyrant in 
heaven.
  -- Robert Green Ingersoll
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkkjws8ACgkQBkIOoMqOI14VxACdFtlcGG5pvS6su+QinlWlgNjn
1V4AmgMtla1deRwyE8cNJ5ATw1vUsu7R
=HNo6
-END PGP SIGNATURE-

Sending mail through IMAP fails

[K C H Mackenzie]

Hello. I am having trouble setting up Mutt to send mail through IMAP on a
university server. I can read mail without trouble. When I finish composing and
type `y' I get `Sending message' and `Mail sent' quickly but no messages have
reached their targets. I've emailed myself on the IMAP server, and sent mail
to
other ac.uk accounts, plus hotmail and googlemail, without success. The debug
file (level 2) seems to show that mail was sent. 

Here is the .muttrc file. I'm using 1.5.15 and Ubuntu 7.10 and 8.04. 

#

set from=[EMAIL PROTECTED]

set editor=emacs --geometry 140x100+10+0 --no-splash
set print_command=muttprint

set reply_self=no

set ssl_starttls=yes # TSL accepted by the server

set folder=imap://imap.shef.ac.uk/ # same result with imaps
set spoolfile=+INBOX 
set record=+sent-mail
set postponed=+drafts
set imap_user= # (Not the full address, but an internal university code) 
set imap_pass=

set include=yes 
set forward_format =[Fwd: %s]

set sort=reverse-date-sent

set alias_file=~/.mutt_aliases
source ~/.mutt_aliases



I started from the example muttrc of Roland Buehlmanns, but trimmed it while
looking for the problem. The reduced file above seems to check out against the
instructions at http://mutt.sourceforge.net/imap/

Since I can read/move/delete mail, the problem can't be access to the IMAP
server as such.  

Can anyone spot what is going wrong?

I don't want to get involved with fetchmail/exim4/... at this stage if I can
avoid it. 

Thanks in advance, K

Re: Sending mail through IMAP fails

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday, October 16 at 09:32 PM, quoth K C H Mackenzie:
 Hello. I am having trouble setting up Mutt to send mail through IMAP on a 
 university server.

I can see your problem already! IMAP is not a protocol that is 
normally used for *sending* email. There are two nearly-identical 
protocols that are used for sending email (SMTP and SUBMISSION), but 
IMAP is only used for *reading* email.

 When I finish composing and type `y' I get `Sending message' and 
 `Mail sent' quickly but no messages have reached their targets.

What's probably happening is that mutt is using the program 
/usr/sbin/sendmail to send email. This is probably provided by exim4 
on your Ubuntu installation, which is probably not set up correctly 
for your network (i.e. it's probably got a default configuration), 
thus, the mail never leaves your computer.

In order to send mail with mutt, you either need to configure it to 
use a mail sending program (such as exim4 or, more minimally, msmtp 
(http://msmtp.sf.net)) that is correctly configured OR you need to 
configure mutt to send the mail directly. To do the latter, you'll 
need to add some things to your muttrc, specifically, an $smtp_url 
setting. It would probably look something like this:

 set smtp_url=smtps://user:[EMAIL PROTECTED]/

 Since I can read/move/delete mail, the problem can't be access to 
 the IMAP server as such.

Indeed, you are correct!

~Kyle
- -- 
Formal symbolic representation of qualitative entities is doomed to 
its rightful place of minor significance in a world where flowers and 
beautiful women abound.
 -- Albert Einstein
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkj3qXEACgkQBkIOoMqOI16WdwCdGmq2+jTlweJJvO+Y2YIv+vac
S60AoLj8FhAzv2ND/hNRzs97qrbJwa8V
=e+Oz
-END PGP SIGNATURE-

Re: Sending mail through IMAP fails

[K C H Mackenzie]

Many thanks. That's worked fine. 

Kirill

Quoting Kyle Wheeler [EMAIL PROTECTED]:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On Thursday, October 16 at 09:32 PM, quoth K C H Mackenzie:
  Hello. I am having trouble setting up Mutt to send mail through IMAP on a 
  university server.
 
 I can see your problem already! IMAP is not a protocol that is 
 normally used for *sending* email. There are two nearly-identical 
 protocols that are used for sending email (SMTP and SUBMISSION), but 
 IMAP is only used for *reading* email.
 
  When I finish composing and type `y' I get `Sending message' and 
  `Mail sent' quickly but no messages have reached their targets.
 
 What's probably happening is that mutt is using the program 
 /usr/sbin/sendmail to send email. This is probably provided by exim4 
 on your Ubuntu installation, which is probably not set up correctly 
 for your network (i.e. it's probably got a default configuration), 
 thus, the mail never leaves your computer.
 
 In order to send mail with mutt, you either need to configure it to 
 use a mail sending program (such as exim4 or, more minimally, msmtp 
 (http://msmtp.sf.net)) that is correctly configured OR you need to 
 configure mutt to send the mail directly. To do the latter, you'll 
 need to add some things to your muttrc, specifically, an $smtp_url 
 setting. It would probably look something like this:
 
  set smtp_url=smtps://user:[EMAIL PROTECTED]/
 
  Since I can read/move/delete mail, the problem can't be access to 
  the IMAP server as such.
 
 Indeed, you are correct!
 
 ~Kyle
 - -- 
 Formal symbolic representation of qualitative entities is doomed to 
 its rightful place of minor significance in a world where flowers and 
 beautiful women abound.
  -- Albert Einstein
 -BEGIN PGP SIGNATURE-
 Comment: Thank you for using encryption!
 
 iEYEARECAAYFAkj3qXEACgkQBkIOoMqOI16WdwCdGmq2+jTlweJJvO+Y2YIv+vac
 S60AoLj8FhAzv2ND/hNRzs97qrbJwa8V
 =e+Oz
 -END PGP SIGNATURE-
 


==
http://kchmackenzie.staff.shef.ac.uk/
==

Sending mail

[Umut Tabak]

Dear all,

As a newbie, I tried to configure mutt. Partially successful if you 
don't consider that I can not send mails :) . I can get mail but can not 
send. My incoming mail server is an IMAP and outgoing server is an SMTP. 
I guess there is a problem with my .muttrc. I pasted that (relatively 
short for a beginner :) )


#mailboxes imap://mail.mech.kuleuven.be
set imap_user=username #your IMAP user name or login
set imap_pass=password #your IMAP password
set spoolfile=imap://mail.mech.kuleuven.be
set folder=imap://mail.mech.kuleuven.be/INBOX
set folder=/home/utab/Mail
set sendmail=/usr/sbin/ssmtp [EMAIL PROTECTED] -appassword
#set sendmail=/usr/sbin/sendmail
set editor=vim

Thanks in advance.

Umut

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm