Jean Louis <bugs@gnu.support> ha escrit:
> mail -E "unset askcc" -a "Date: `/bin/date +'%a, %d %b %Y %T %z'`"
> -a "Content-Type: text/plain; charset=utf-8" -a "Content-Disposition:
> inline" -a "Content-Transfer-Encoding: 8bit" -a "From: Jean Louis
> <yourem...@example.com>" -E 'set
> record=maildir:~/Maildir/myem...@yahoo.com' -s 'Hello there'
> --alternative --content-type=text/html
> --attach=/home/data1/protected/index.html "Jean Louis
> <myem...@yahoo.com>" --content-type=text/plain
Thanks. Let me notice that the Content-Disposition and
Content-Transfer-Encoding settings have no effect.
> You need to replace myem...@yahoo.com with your Yahoo address,
Sorry, I have none. But never mind.
>> 2. Preferably, the output produced by the mail binary when sending the
>> message with verbose on (-E 'set verbose').
> You may now with the command try yourself.
Jean, allow me to bring your attention to the fact that the output *I*'d get
is completely irrelevant. What *is* relevant, is what *you* get.
> > 3. Raw content of the message as it arrived at the remote node.
>
> It is here temporary:
> https://gnu.support/files/tmp/rawcontent.txt
Thanks. I must say that a brief glance on this mail suffices to
state that this message was *not* created by GNU mail. First of all, notice
this:
Content-Type: multipart/alternative;
boundary="=_stw1.rcdrun.com-1522-1492412035-0001-2"
That's not a boundary line generated by GNU mailutils. We use the
following code (libmailutils/mime/mime.c:473):
snprintf (boundary, sizeof boundary, "%ld-%ld=:%ld",
(long) random (), (long) time (0), (long) getpid ());
As you seem it is obvious the content-type header above was not created
by GNU mailutils.
Secondly, it has the leading plaintext stanza
"This is a MIME-formatted message. If you see this text it means that
your E-mail software does not support MIME-formatted messages."
which mailutils never creates, either.
Surprisingly, the message does contain the X-Mailer header that seems to
have been produced by mailutils. The only way I can interpret it, is
that the message have been reformatted by the receiving party upon
arrival.
Apart from these obvious facts, it is a perfectly valid MIME message,
that no sane mail reader can interpret as containing attachments.
However, while I'm writing these lines, it strikes me that the content
type of the second MIME part contains the "name" attribute. While RFC
1341 does not explicitly forbid its use for the "inline" content
disposition, I can easily conceive that it may lead some MUAs astray.
If my guess is right, the attached patch should fix that.
Regards,
Sergey
>From e865e0f1faf4b09ec687032410fe2edfb9b61e20 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff <g...@gnu.org.ua>
Date: Mon, 17 Apr 2017 15:33:12 +0300
Subject: [PATCH] mail: don't set name and filename for multipart/alternative.
* mail/send.c (saveatt): Avoid setting name and filename in Content-Type
and Content-Disposition headers, if the message type is set to
multipart/alternative.
---
mail/send.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mail/send.c b/mail/send.c
index 21529a0..8d8de6c 100644
--- a/mail/send.c
+++ b/mail/send.c
@@ -444,7 +444,8 @@ saveatt (void *item, void *data)
char *p;
rc = mu_attachment_create (&part, aptr->content_type, aptr->encoding,
- aptr->name, aptr->filename);
+ env->alt ? NULL : aptr->name,
+ env->alt ? NULL : aptr->filename);
if (rc)
{
mu_error (_("can't create attachment %s: %s"),
--
1.7.12.1
_______________________________________________
Bug-mailutils mailing list
Bug-mailutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-mailutils
