info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
IMAP E-Mail sending question.
13 views
Skip to first unread message
Bud Spencer
Aug 3, 2022, 1:33:01 PM8/3/22
to
Hi there.
I'm wondering about the following thing:
There is a server A and Alpine is running on that server and is configured
to talk with mail.server.a and there is user@server.a account.
Then I'll set up Alpine to use IMAP to get E-Mails from server B,
user@server.b ... now when I send E-Mails as user@server.b using
mail.server.b, does Alpine include some indentifying things into header of
those E-Mails that can point out to server.a?
I'd like to keep these two separated, yet use Alpine on server.a to
send/receive both ...
Hope my question made some sense :)
--
₪ BUD ₪
I'm wondering about the following thing:
There is a server A and Alpine is running on that server and is configured
to talk with mail.server.a and there is user@server.a account.
Then I'll set up Alpine to use IMAP to get E-Mails from server B,
user@server.b ... now when I send E-Mails as user@server.b using
mail.server.b, does Alpine include some indentifying things into header of
those E-Mails that can point out to server.a?
I'd like to keep these two separated, yet use Alpine on server.a to
send/receive both ...
Hope my question made some sense :)
--
₪ BUD ₪
Eduardo Chappa
Aug 3, 2022, 3:06:21 PM8/3/22
to
On Wed, 3 Aug 2022, Bud Spencer wrote:
> There is a server A and Alpine is running on that server and is
> configured to talk with mail.server.a and there is user@server.a
> account.
>
> Then I'll set up Alpine to use IMAP to get E-Mails from server B,
> user@server.b ... now when I send E-Mails as user@server.b using
> mail.server.b, does Alpine include some indentifying things into header
> of those E-Mails that can point out to server.a?
Alpine will not add anything that is not requested by protocols. SMTP
> There is a server A and Alpine is running on that server and is
> configured to talk with mail.server.a and there is user@server.a
> account.
>
> Then I'll set up Alpine to use IMAP to get E-Mails from server B,
> user@server.b ... now when I send E-Mails as user@server.b using
> mail.server.b, does Alpine include some indentifying things into header
> of those E-Mails that can point out to server.a?
asks that computers identify themselves (by their IP address) so the IP
address of server.a will be available to the smtp server.b, which will be
included in the Received: headers.
Other than that, everything can be set up and kept separately.
--
Eduardo
https://alpineapp.email
Bud Spencer
Aug 3, 2022, 3:26:36 PM8/3/22
to
So, if I understod this correctly. If server.b doesn't strip these things
from header, then it will be shown that particular E-MAil is sent from
server.a?
Correct?
--
₪ BUD ₪
Eduardo Chappa
Aug 3, 2022, 3:29:01 PM8/3/22
to
server.a.
--
Eduardo
https://alpineapp.email (web)
http://repo.or.cz/alpine.git (Git)
Bud Spencer
Aug 3, 2022, 3:36:55 PM8/3/22
to
On Wed, 3 Aug 2022, Eduardo Chappa wrote:
> On Wed, 3 Aug 2022, Bud Spencer wrote:
>
>> So, if I understod this correctly. If server.b doesn't strip these things
>> from header, then it will be shown that particular E-MAil is sent from
>> server.a?
>>
>> Correct?
>
> Yes, and server.b will add a header to show the message came from server.a.
Thanks for clearing this up! Much obliged!
> On Wed, 3 Aug 2022, Bud Spencer wrote:
>
>> So, if I understod this correctly. If server.b doesn't strip these things
>> from header, then it will be shown that particular E-MAil is sent from
>> server.a?
>>
>> Correct?
>
> Yes, and server.b will add a header to show the message came from server.a.
--
₪ BUD ₪
Henning Hucke
Aug 4, 2022, 2:37:42 AM8/4/22
to
Bud Spencer <b...@campo.verano.it> wrote:
> Hi there.
Hi Mr. Spencer,
I tought that you died recently (for a suitable definition of
"recently"). Wondering how you can write postings as a dead being.
Read: It seems to me that you are asking how to - some kind of - fake
mails.
> [...]
You'll not be able to hide this setup. At least not to people who are
able to read mail headers and know how mail systems function.
Beside of that: You are talking about where you get your mails from but
asking how to hide things if you send mails...
Strange combination!
Regards,
Henning
--
In the first place, God made idiots;
this was for practice; then he made school boards.
-- Mark Twain
> Hi there.
Hi Mr. Spencer,
I tought that you died recently (for a suitable definition of
"recently"). Wondering how you can write postings as a dead being.
Read: It seems to me that you are asking how to - some kind of - fake
mails.
> [...]
> There is a server A and Alpine is running on that server and is configured
> to talk with mail.server.a and there is user@server.a account.
>
> Then I'll set up Alpine to use IMAP to get E-Mails from server B,
> user@server.b ... now when I send E-Mails as user@server.b using
> mail.server.b, does Alpine include some indentifying things into header of
> those E-Mails that can point out to server.a?
>
> I'd like to keep these two separated, yet use Alpine on server.a to
> send/receive both ...
>
> Hope my question made some sense :)
It does.
> to talk with mail.server.a and there is user@server.a account.
>
> Then I'll set up Alpine to use IMAP to get E-Mails from server B,
> user@server.b ... now when I send E-Mails as user@server.b using
> mail.server.b, does Alpine include some indentifying things into header of
> those E-Mails that can point out to server.a?
>
> I'd like to keep these two separated, yet use Alpine on server.a to
> send/receive both ...
>
> Hope my question made some sense :)
You'll not be able to hide this setup. At least not to people who are
able to read mail headers and know how mail systems function.
Beside of that: You are talking about where you get your mails from but
asking how to hide things if you send mails...
Strange combination!
Regards,
Henning
--
In the first place, God made idiots;
this was for practice; then he made school boards.
-- Mark Twain
Bud Spencer
Aug 4, 2022, 6:05:30 AM8/4/22
to
On Thu, 4 Aug 2022, Henning Hucke wrote:
> Bud Spencer <b...@campo.verano.it> wrote:
>
> I tought that you died recently (for a suitable definition of
> "recently"). Wondering how you can write postings as a dead being.
It's a kind of magic.
> Read: It seems to me that you are asking how to - some kind of - fake
> mails.
No. Not at all. Both E-Mail addresses are real, nothing to fake here.
>> [...]
>> There is a server A and Alpine is running on that server and is configured
>> to talk with mail.server.a and there is user@server.a account.
>>
>> Then I'll set up Alpine to use IMAP to get E-Mails from server B,
>> user@server.b ... now when I send E-Mails as user@server.b using
>> mail.server.b, does Alpine include some indentifying things into header of
>> those E-Mails that can point out to server.a?
>>
>> I'd like to keep these two separated, yet use Alpine on server.a to
>> send/receive both ...
>>
>> Hope my question made some sense :)
>
> It does.
>
> You'll not be able to hide this setup. At least not to people who are
> able to read mail headers and know how mail systems function.
Except if server.b strips this any mention of server.a from the headers
and send it as it would have sent from the server.b
> Beside of that: You are talking about where you get your mails from but
> asking how to hide things if you send mails...
> Strange combination!
Not really. It would just be more convenient to use both E-Mail addresses
with same client. But undisclosed reasons server.a should not be visible
in E-Mails sent from server.b ... I see nothing strange about this. At
least for me.
--
₪ BUD ₪
> Bud Spencer <b...@campo.verano.it> wrote:
>
> I tought that you died recently (for a suitable definition of
> "recently"). Wondering how you can write postings as a dead being.
> Read: It seems to me that you are asking how to - some kind of - fake
> mails.
>> [...]
>> There is a server A and Alpine is running on that server and is configured
>> to talk with mail.server.a and there is user@server.a account.
>>
>> Then I'll set up Alpine to use IMAP to get E-Mails from server B,
>> user@server.b ... now when I send E-Mails as user@server.b using
>> mail.server.b, does Alpine include some indentifying things into header of
>> those E-Mails that can point out to server.a?
>>
>> I'd like to keep these two separated, yet use Alpine on server.a to
>> send/receive both ...
>>
>> Hope my question made some sense :)
>
> It does.
>
> You'll not be able to hide this setup. At least not to people who are
> able to read mail headers and know how mail systems function.
and send it as it would have sent from the server.b
> Beside of that: You are talking about where you get your mails from but
> asking how to hide things if you send mails...
> Strange combination!
with same client. But undisclosed reasons server.a should not be visible
in E-Mails sent from server.b ... I see nothing strange about this. At
least for me.
--
₪ BUD ₪
Henning Hucke
Aug 5, 2022, 1:37:20 AM8/5/22
to
Bud Spencer <b...@campo.verano.it> wrote:
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 50 lines --]
Stange information line.
>
> On Thu, 4 Aug 2022, Henning Hucke wrote:
>[...]
manipulate everything which happened before (and at) this server. So
far so true. But you didn't tell that you've control over server.b.
>
>> Beside of that: You are talking about where you get your mails from but
>> asking how to hide things if you send mails...
>> Strange combination!
>
> Not really. It would just be more convenient to use both E-Mail addresses
> with same client. But undisclosed reasons server.a should not be visible
> in E-Mails sent from server.b ... I see nothing strange about this. At
> least for me.
Please enlighten me: why?
For security reasons? This would be so called security by obscurity
which is known to be no security.
It's a little bit like blocking ICMP echo/reply messages. This indeed
closes a hole which can be used to tunnel malicious data through a
firewall but on the other hand you can minimize the risk by also
filtering "oversized" ICMP echo/reply messages and other things.
But if you block ICMP you harm others which not so seldom need this
"tool" to troubleshoot thing. And these others are your partner "in the
internet".
So carefully think about whether or not this really helps you and also
think about how this personal measurement harms other participants of
the internet.
Regards
Henning
--
In theory there is no difference between theory and practise.
In practise there is.
Yogi Beer
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 50 lines --]
Stange information line.
>
> On Thu, 4 Aug 2022, Henning Hucke wrote:
>> You'll not be able to hide this setup. At least not to people who are
>> able to read mail headers and know how mail systems function.
>
> Except if server.b strips this any mention of server.a from the headers
> and send it as it would have sent from the server.b
Of course as ever: If you've got a server under your control you can
>> able to read mail headers and know how mail systems function.
>
> Except if server.b strips this any mention of server.a from the headers
> and send it as it would have sent from the server.b
manipulate everything which happened before (and at) this server. So
far so true. But you didn't tell that you've control over server.b.
>
>> Beside of that: You are talking about where you get your mails from but
>> asking how to hide things if you send mails...
>> Strange combination!
>
> Not really. It would just be more convenient to use both E-Mail addresses
> with same client. But undisclosed reasons server.a should not be visible
> in E-Mails sent from server.b ... I see nothing strange about this. At
> least for me.
For security reasons? This would be so called security by obscurity
which is known to be no security.
It's a little bit like blocking ICMP echo/reply messages. This indeed
closes a hole which can be used to tunnel malicious data through a
firewall but on the other hand you can minimize the risk by also
filtering "oversized" ICMP echo/reply messages and other things.
But if you block ICMP you harm others which not so seldom need this
"tool" to troubleshoot thing. And these others are your partner "in the
internet".
So carefully think about whether or not this really helps you and also
think about how this personal measurement harms other participants of
the internet.
Regards
Henning
--
In theory there is no difference between theory and practise.
In practise there is.
Yogi Beer
Bud Spencer
Aug 5, 2022, 6:42:50 AM8/5/22
to
On Fri, 5 Aug 2022, Henning Hucke wrote:
> Bud Spencer <b...@campo.verano.it> wrote:
>> [-- text/plain, encoding quoted-printable, charset: UTF-8, 50 lines --]
>
> Stange information line.
Innit?
> Bud Spencer <b...@campo.verano.it> wrote:
>> [-- text/plain, encoding quoted-printable, charset: UTF-8, 50 lines --]
>
> Stange information line.
>> On Thu, 4 Aug 2022, Henning Hucke wrote:
>> [...]
>>> You'll not be able to hide this setup. At least not to people who are
>>> able to read mail headers and know how mail systems function.
>>
>> Except if server.b strips this any mention of server.a from the headers
>> and send it as it would have sent from the server.b
>
> Of course as ever: If you've got a server under your control you can
> manipulate everything which happened before (and at) this server. So
> far so true. But you didn't tell that you've control over server.b.
>>> Beside of that: You are talking about where you get your mails from but
>>> asking how to hide things if you send mails...
>>> Strange combination!
>>
>> Not really. It would just be more convenient to use both E-Mail addresses
>> with same client. But undisclosed reasons server.a should not be visible
>> in E-Mails sent from server.b ... I see nothing strange about this. At
>> least for me.
>
> Please enlighten me: why?
--
₪ BUD ₪
Adam H. Kerman
Aug 5, 2022, 12:03:31 PM8/5/22
to
Bud Spencer <b...@campo.verano.it> wrote:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>--2739015498-468396953-1659547978=:11738
>Content-Type: text/plain; format=flowed; charset=UTF-8
>Content-Transfer-Encoding: QUOTED-PRINTABLE
>Hi there.
>I'm wondering about the following thing:
>There is a server A and Alpine is running on that server and is configured=
>=20
>user@server.b ... now when I send E-Mails as user@server.b using=20
>mail.server.b, does Alpine include some indentifying things into header of=
>=20
>=E2=82=AA BUD =E2=82=AA
>--2739015498-468396953-1659547978=:11738--
Could I please request that you not post articles to plain text Usenet
that are attachments with QUOTED-PRINTABLE encoding? There's no plain
text alternative part and there's no reason to encode.
I don't even know how you set alpine to create the intended main part
to be an attachment with no alternative plain text part.
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>--2739015498-468396953-1659547978=:11738
>Content-Type: text/plain; format=flowed; charset=UTF-8
>Content-Transfer-Encoding: QUOTED-PRINTABLE
>Hi there.
>I'm wondering about the following thing:
>=20
>to talk with mail.server.a and there is user@server.a account.
>Then I'll set up Alpine to use IMAP to get E-Mails from server B,=20
>user@server.b ... now when I send E-Mails as user@server.b using=20
>mail.server.b, does Alpine include some indentifying things into header of=
>=20
>those E-Mails that can point out to server.a?
>I'd like to keep these two separated, yet use Alpine on server.a to=20
>send/receive both ...
>Hope my question made some sense :)
>--=20
>Hope my question made some sense :)
>=E2=82=AA BUD =E2=82=AA
>--2739015498-468396953-1659547978=:11738--
Could I please request that you not post articles to plain text Usenet
that are attachments with QUOTED-PRINTABLE encoding? There's no plain
text alternative part and there's no reason to encode.
I don't even know how you set alpine to create the intended main part
to be an attachment with no alternative plain text part.
Bud Spencer
Aug 5, 2022, 5:11:03 PM8/5/22
to
On Fri, 5 Aug 2022, Adam H. Kerman wrote:
> I don't even know how you set alpine to create the intended main part
> to be an attachment with no alternative plain text part.
Then there are two of us. I haven't done such settings ...
> I don't even know how you set alpine to create the intended main part
> to be an attachment with no alternative plain text part.
--
₪ BUD ₪
Adam H. Kerman
Aug 6, 2022, 11:45:24 AM8/6/22
to
Bud Spencer <b...@campo.verano.it> wrote:
I don't know what your alpine settings are, but this is what you are
producing. There are two parts to your article.
This is part one. It's boilerplate. I've seen other clients add this.
I had no idea alpine would ever add it. This is undesireable behavior.
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
Here is the second part.
>--2739015498-288430170-1659733859=:87688
>Content-Type: text/plain; charset=UTF-8; format=flowed
>Content-Transfer-Encoding: QUOTED-PRINTABLE
>--=20
>=E2=82=AA BUD =E2=82=AA
>--2739015498-288430170-1659733859=:87688--
Usenet is 8-bit clean. Never post with QP encoding. alpine has a setting
"Enable 8bit ESMTP Negotiation" which I have set but I don't think it's
set by default. I think that generally prevents alpine creating QP in
email but that shouldn't effect Usenet since SMTP is irrelevant.
As far as how you keep posting with your intended main body part of the
article as an attachment instead, I cannot possibly guess. I've never
had alpine create an email message of mine like that nor would it create
a Usenet article like that. Generally, I don't use alpine as a
newsreader but I have the option to do so as I follow pine naming
convention for my .newsrc so that alpine may use it.
I don't know what your alpine settings are, but this is what you are
producing. There are two parts to your article.
This is part one. It's boilerplate. I've seen other clients add this.
I had no idea alpine would ever add it. This is undesireable behavior.
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>--2739015498-288430170-1659733859=:87688
>Content-Type: text/plain; charset=UTF-8; format=flowed
>Content-Transfer-Encoding: QUOTED-PRINTABLE
>=E2=82=AA BUD =E2=82=AA
>--2739015498-288430170-1659733859=:87688--
Usenet is 8-bit clean. Never post with QP encoding. alpine has a setting
"Enable 8bit ESMTP Negotiation" which I have set but I don't think it's
set by default. I think that generally prevents alpine creating QP in
email but that shouldn't effect Usenet since SMTP is irrelevant.
As far as how you keep posting with your intended main body part of the
article as an attachment instead, I cannot possibly guess. I've never
had alpine create an email message of mine like that nor would it create
a Usenet article like that. Generally, I don't use alpine as a
newsreader but I have the option to do so as I follow pine naming
convention for my .newsrc so that alpine may use it.
Eduardo Chappa
Aug 6, 2022, 12:26:28 PM8/6/22
to
On Fri, 5 Aug 2022, Adam H. Kerman wrote:
> Could I please request that you not post articles to plain text Usenet
> that are attachments with QUOTED-PRINTABLE encoding? There's no plain
> text alternative part and there's no reason to encode.
Adam, please take a look at RFC 5536, which effectively allows for
> that are attachments with QUOTED-PRINTABLE encoding? There's no plain
> text alternative part and there's no reason to encode.
quoted-printable in news articles. I understand you will never like it,
but it is perfectly legal, and there is no reason to create noise about
it.
Bud Spencer
Aug 6, 2022, 5:15:24 PM8/6/22
to
I never knew this kind of thing is going on, no need to foam all over.
Also what you are doing has nothing to do with anything. You do you.
Anyway thank you to bring this up, now I know the issue and can correct it
.. only I didn't find anything like that in the configs.
--
₪ BUD ₪
Bud Spencer
Aug 6, 2022, 5:17:43 PM8/6/22
to
On Sat, 6 Aug 2022, Eduardo Chappa wrote:
> On Fri, 5 Aug 2022, Adam H. Kerman wrote:
>
>> Could I please request that you not post articles to plain text Usenet that
>> are attachments with QUOTED-PRINTABLE encoding? There's no plain text
>> alternative part and there's no reason to encode.
>
> Adam, please take a look at RFC 5536, which effectively allows for
> quoted-printable in news articles. I understand you will never like it, but
> it is perfectly legal, and there is no reason to create noise about it.
Oh. So I didn't accidentally do anything wrong then.
> On Fri, 5 Aug 2022, Adam H. Kerman wrote:
>
>> Could I please request that you not post articles to plain text Usenet that
>> are attachments with QUOTED-PRINTABLE encoding? There's no plain text
>> alternative part and there's no reason to encode.
>
> Adam, please take a look at RFC 5536, which effectively allows for
> quoted-printable in news articles. I understand you will never like it, but
> it is perfectly legal, and there is no reason to create noise about it.
Anyway, could you please point out where I can set this off anyway? Since
I haven't set such thing ... at least not knowingly.
--
₪ BUD ₪
Adam H. Kerman
Aug 6, 2022, 9:01:30 PM8/6/22
to
At 11:26am -0000, 08/06/22, Eduardo Chappa <cha...@washington.edu> wrote:
>On Fri, 5 Aug 2022, Adam H. Kerman wrote:
>>Could I please request that you not post articles to plain text Usenet that
>>are attachments with QUOTED-PRINTABLE encoding? There's no plain text
>>alternative part and there's no reason to encode.
>Adam, please take a look at RFC 5536, which effectively allows for
>quoted-printable in news articles. I understand you will never like it, but
>it is perfectly legal, and there is no reason to create noise about it.
I'm posting a followup with alpine. Here's a non-ASCII character.
>On Fri, 5 Aug 2022, Adam H. Kerman wrote:
>>Could I please request that you not post articles to plain text Usenet that
>>are attachments with QUOTED-PRINTABLE encoding? There's no plain text
>>alternative part and there's no reason to encode.
>Adam, please take a look at RFC 5536, which effectively allows for
>quoted-printable in news articles. I understand you will never like it, but
>it is perfectly legal, and there is no reason to create noise about it.
’
Let's see if I get quoted-printable encoding and if the main body of the
article ends up in a second attachment, with the boilerplate nag about
MIME-aware tools in the first part.
Adam H. Kerman
Aug 6, 2022, 9:14:41 PM8/6/22
to
At 8:01pm -0000, 08/06/22, Adam H. Kerman <a...@chinet.com> wrote:
>MIME-Version: 1.0
>Content-Type: text/plain; charset=ISO-8859-7
>Content-Transfer-Encoding: 8BIT
>At 11:26am -0000, 08/06/22, Eduardo Chappa <cha...@washington.edu> wrote:
>>On Fri, 5 Aug 2022, Adam H. Kerman wrote:
>>>Could I please request that you not post articles to plain text Usenet that
>>>are attachments with QUOTED-PRINTABLE encoding? There's no plain text
>>>alternative part and there's no reason to encode.
>>Adam, please take a look at RFC 5536, which effectively allows for
>>quoted-printable in news articles. I understand you will never like it, but
>>it is perfectly legal, and there is no reason to create noise about it.
>I'm posting a followup with alpine. Here's a non-ASCII character.
>?
In UTF-8, that was supposed to be an apostrophe.
>Let's see if I get quoted-printable encoding and if the main body of the
>article ends up in a second attachment, with the boilerplate nag about
>MIME-aware tools in the first part.
Huh
I was not expecting the MIME header to declare ISO-8859-7 since my shell's
environment has character set to UTF-8, and my terminal emulation matches.
In any event, I didn't get a multipart.
>MIME-Version: 1.0
>Content-Type: text/plain; charset=ISO-8859-7
>Content-Transfer-Encoding: 8BIT
>At 11:26am -0000, 08/06/22, Eduardo Chappa <cha...@washington.edu> wrote:
>>On Fri, 5 Aug 2022, Adam H. Kerman wrote:
>>>Could I please request that you not post articles to plain text Usenet that
>>>are attachments with QUOTED-PRINTABLE encoding? There's no plain text
>>>alternative part and there's no reason to encode.
>>Adam, please take a look at RFC 5536, which effectively allows for
>>quoted-printable in news articles. I understand you will never like it, but
>>it is perfectly legal, and there is no reason to create noise about it.
>I'm posting a followup with alpine. Here's a non-ASCII character.
In UTF-8, that was supposed to be an apostrophe.
>Let's see if I get quoted-printable encoding and if the main body of the
>article ends up in a second attachment, with the boilerplate nag about
>MIME-aware tools in the first part.
I was not expecting the MIME header to declare ISO-8859-7 since my shell's
environment has character set to UTF-8, and my terminal emulation matches.
In any event, I didn't get a multipart.
Adam H. Kerman
Aug 6, 2022, 9:17:52 PM8/6/22
to
Eduardo Chappa <cha...@washington.edu> wrote:
>On Fri, 5 Aug 2022, Adam H. Kerman wrote:
>>Could I please request that you not post articles to plain text Usenet
>>that are attachments with QUOTED-PRINTABLE encoding? There's no plain
>>text alternative part and there's no reason to encode.
>Adam, please take a look at RFC 5536, which effectively allows for
>quoted-printable in news articles. I understand you will never like it,
>but it is perfectly legal, and there is no reason to create noise about
>it.
I don't agree that attachments are part of plain-text Usenet either.
>On Fri, 5 Aug 2022, Adam H. Kerman wrote:
>>Could I please request that you not post articles to plain text Usenet
>>that are attachments with QUOTED-PRINTABLE encoding? There's no plain
>>text alternative part and there's no reason to encode.
>Adam, please take a look at RFC 5536, which effectively allows for
>quoted-printable in news articles. I understand you will never like it,
>but it is perfectly legal, and there is no reason to create noise about
>it.
I've just never seen alpine do that before and I have no idea how
to recreate it.
Bud Spencer
Aug 7, 2022, 12:32:05 PM8/7/22
to
have no idea what is going on.
Like I said. I haven't done any setting of that sort. So I'm completely
clueless why this happens.
--
₪ BUD ₪
Bud Spencer
Aug 8, 2022, 12:46:01 AM8/8/22
to
such thing. Or I'm just missing something big time :)
--
₪ BUD ₪
Eduardo Chappa
Aug 8, 2022, 1:17:58 PM8/8/22
to
On Mon, 8 Aug 2022, Bud Spencer wrote:
> Could you help Eduardo? I still have no idea how to set Alpine not to do
> such thing. Or I'm just missing something big time :)
Bud, there is nothing to do here. You cannot configure Alpine so that it
> Could you help Eduardo? I still have no idea how to set Alpine not to do
> such thing. Or I'm just missing something big time :)
will not do something that Adam will not like.
The point is: There are 8-bits in your message, Alpine will encode them
somehow (meaning they will not be sent as 8-bit). That is the standard.
Bud Spencer
Aug 8, 2022, 2:58:24 PM8/8/22
to
On Mon, 8 Aug 2022, Eduardo Chappa wrote:
> On Mon, 8 Aug 2022, Bud Spencer wrote:
>
>> Could you help Eduardo? I still have no idea how to set Alpine not to do
>> such thing. Or I'm just missing something big time :)
>
> Bud, there is nothing to do here. You cannot configure Alpine so that it will
> not do something that Adam will not like.
I wasn't thinking of this because of him. Just out of interest and if,
> On Mon, 8 Aug 2022, Bud Spencer wrote:
>
>> Could you help Eduardo? I still have no idea how to set Alpine not to do
>> such thing. Or I'm just missing something big time :)
>
> Bud, there is nothing to do here. You cannot configure Alpine so that it will
> not do something that Adam will not like.
which is doubtful, I did have made something in mistake.
> The point is: There are 8-bits in your message, Alpine will encode them
> somehow (meaning they will not be sent as 8-bit). That is the standard.
Thanks for taking time to elaborate this more to my autistic mind :)
--
₪ BUD ₪
Adam H. Kerman
Aug 8, 2022, 3:47:01 PM8/8/22
to
Eduardo Chappa <cha...@washington.edu> wrote:
>On Mon, 8 Aug 2022, Bud Spencer wrote:
>>Could you help Eduardo? I still have no idea how to set Alpine not to do
>>such thing. Or I'm just missing something big time :)
>Bud, there is nothing to do here. You cannot configure Alpine so that it
>will not do something that Adam will not like.
>The point is: There are 8-bits in your message, Alpine will encode them
>somehow (meaning they will not be sent as 8-bit). That is the standard.
You're being unfair, Eduardo. I raised the issue because of the fact that
>On Mon, 8 Aug 2022, Bud Spencer wrote:
>>Could you help Eduardo? I still have no idea how to set Alpine not to do
>>such thing. Or I'm just missing something big time :)
>Bud, there is nothing to do here. You cannot configure Alpine so that it
>will not do something that Adam will not like.
>The point is: There are 8-bits in your message, Alpine will encode them
>somehow (meaning they will not be sent as 8-bit). That is the standard.
alpine created an article as a two-part multipart with one of the two
parts blank (except for the nag boilerplate about using MIME-aware
tools) with his intended main body of the article in the second
attachment.
Multiparts aren't plain text Usenet. That's undesireable.
The quoted-printable encoding was a separate matter. Yes, there is a
quoted-printable encoding standard that alpine implements. Nevertheless,
unencoded text should be prefered over encoded text in an almost entirely
8-bit clean environment like Usenet.
The issue of attachments is of greater concern than the issue of
quoted-printable.
I wasn't able to figure out what settings he used to get that result.
I understand that you disagree with everything I've written.
Nevertheless, I'm not alone in caring that text Usenet remains a plain
text medium of communication.
Adam H. Kerman
Aug 8, 2022, 3:50:55 PM8/8/22
to
Bud Spencer <b...@campo.verano.it> wrote:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>--2739015498-1322974694-1659985100=:22649
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>Content-Type: text/plain; charset=UTF-8; format=flowed
>Content-Transfer-Encoding: QUOTED-PRINTABLE
>Content-Transfer-Encoding: QUOTED-PRINTABLE
>On Mon, 8 Aug 2022, Eduardo Chappa wrote:
>>On Mon, 8 Aug 2022, Bud Spencer wrote:
>>>Could you help Eduardo? I still have no idea how to set Alpine not to do=
>>On Mon, 8 Aug 2022, Bud Spencer wrote:
>=20
>>>such thing. Or I'm just missing something big time :)
>>Bud, there is nothing to do here. You cannot configure Alpine so that it =
>will=20
>>not do something that Adam will not like.
>I wasn't thinking of this because of him. Just out of interest and if,=20
>which is doubtful, I did have made something in mistake.
>>The point is: There are 8-bits in your message, Alpine will encode them=
>=20
>>somehow (meaning they will not be sent as 8-bit). That is the standard.
>So nothing is broken then. I'm fine with that.
Broken behavior is non-standards compliance. That's not the issue here.
>So nothing is broken then. I'm fine with that.
Eduardo makes sure alpine remains standards compliant.
Henning Hucke
Aug 9, 2022, 1:37:44 AM8/9/22
to
Hi Adam,
> Eduardo Chappa <cha...@washington.edu> wrote:
> [...]
to for instance quoted printable encoding?
Especially in newsgroups exactly this should be the case at all. They
should stay as close to us ascii text as possible so that they are as
readable as possible even if the raw article is presented to you.
And I think this is what you'll read if you read all RFCs relevant for
newsgroup articles.
> The issue of attachments is of greater concern than the issue of
> quoted-printable.
Here I'm totally with you.
> [...]
Best regards,
Henning
--
Zero Mostel: That's it baby! When you got it, flaunt it! Flaunt it!
-- Mel Brooks, "The Producers"
> Eduardo Chappa <cha...@washington.edu> wrote:
> [...]
>>The point is: There are 8-bits in your message, Alpine will encode them
>>somehow (meaning they will not be sent as 8-bit). That is the standard.
> [...]
>>somehow (meaning they will not be sent as 8-bit). That is the standard.
> The quoted-printable encoding was a separate matter. Yes, there is a
> quoted-printable encoding standard that alpine implements. Nevertheless,
> unencoded text should be prefered over encoded text in an almost entirely
> 8-bit clean environment like Usenet.
I beg your pardon! In newsgroups text should get uuencoded in preference
> quoted-printable encoding standard that alpine implements. Nevertheless,
> unencoded text should be prefered over encoded text in an almost entirely
> 8-bit clean environment like Usenet.
to for instance quoted printable encoding?
Especially in newsgroups exactly this should be the case at all. They
should stay as close to us ascii text as possible so that they are as
readable as possible even if the raw article is presented to you.
And I think this is what you'll read if you read all RFCs relevant for
newsgroup articles.
> The issue of attachments is of greater concern than the issue of
> quoted-printable.
> [...]
Best regards,
Henning
--
Zero Mostel: That's it baby! When you got it, flaunt it! Flaunt it!
-- Mel Brooks, "The Producers"
Adam H. Kerman
Aug 9, 2022, 12:05:35 PM8/9/22
to
Henning Hucke <h_hucke+n...@newsmail.aeon.icebear.org> wrote:
>Adam H. Kerman <a...@chinet.com> wrote:
>>Eduardo Chappa <cha...@washington.edu> wrote:
>>[...]
>>>The point is: There are 8-bits in your message, Alpine will encode them
>>>somehow (meaning they will not be sent as 8-bit). That is the standard.
>>[...]
>>The quoted-printable encoding was a separate matter. Yes, there is a
>>quoted-printable encoding standard that alpine implements. Nevertheless,
>>unencoded text should be prefered over encoded text in an almost entirely
>>8-bit clean environment like Usenet.
>I beg your pardon! In newsgroups text should get uuencoded in preference
>to for instance quoted printable encoding?
You've whooshed me.
>Adam H. Kerman <a...@chinet.com> wrote:
>>Eduardo Chappa <cha...@washington.edu> wrote:
>>[...]
>>>The point is: There are 8-bits in your message, Alpine will encode them
>>>somehow (meaning they will not be sent as 8-bit). That is the standard.
>>[...]
>>The quoted-printable encoding was a separate matter. Yes, there is a
>>quoted-printable encoding standard that alpine implements. Nevertheless,
>>unencoded text should be prefered over encoded text in an almost entirely
>>8-bit clean environment like Usenet.
>I beg your pardon! In newsgroups text should get uuencoded in preference
>to for instance quoted printable encoding?
>Especially in newsgroups exactly this should be the case at all. They
>should stay as close to us ascii text as possible so that they are as
>readable as possible even if the raw article is presented to you.
>And I think this is what you'll read if you read all RFCs relevant for
>newsgroup articles.
restricted to 7bit like SMTP but does retain the 1000 character line
length limit.
>>The issue of attachments is of greater concern than the issue of
>>quoted-printable.
>Here I'm totally with you.
the standards?
>>[...]
0 new messages