IMAP E-Mail sending question.

[Bud Spencer]

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 ***@server.a account.

Then I'll set up Alpine to use IMAP to get E-Mails from server B,
***@server.b ... now when I send E-Mails as ***@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 :)

[Eduardo Chappa]

Post by Bud Spencer
There is a server A and Alpine is running on that server and is
account.
Then I'll set up Alpine to use IMAP to get E-Mails from server B,
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
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.

[Bud Spencer]

Post by Eduardo Chappa

Post by Bud Spencer
There is a server A and Alpine is running on that server and is configured
Then I'll set up Alpine to use IMAP to get E-Mails from server B,
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
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.

Thanks for your answer Eduardo!

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?

[Eduardo Chappa]

Post by Bud Spencer
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 Spencer]

Post by Bud Spencer
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!

[Henning Hucke]

Post by Bud Spencer
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.

Post by Bud Spencer
[...]
There is a server A and Alpine is running on that server and is configured
Then I'll set up Alpine to use IMAP to get E-Mails from server B,
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.

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

[Bud Spencer]

Post by Henning Hucke
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.

Post by Henning Hucke
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.

Post by Henning Hucke

Post by Bud Spencer
[...]
There is a server A and Alpine is running on that server and is configured
Then I'll set up Alpine to use IMAP to get E-Mails from server B,
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

Post by Henning Hucke
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.

[Henning Hucke]

[-- text/plain, encoding quoted-printable, charset: UTF-8, 50 lines --]

Stange information line.

[...]

Post by Henning Hucke
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.

Post by Henning Hucke
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

[Bud Spencer]

Post by Henning Hucke

[-- text/plain, encoding quoted-printable, charset: UTF-8, 50 lines --]

Stange information line.

Innit?

Post by Henning Hucke

[...]

Post by Henning Hucke
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.

I don't.

Post by Henning Hucke

Post by Henning Hucke
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?

You are smart man, you figure out possibilities.

[Adam H. Kerman]

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.
There is a server A and Alpine is running on that server and is configured=
=20
Then I'll set up Alpine to use IMAP to get E-Mails from server B,=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
=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]

Post by Adam H. Kerman
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 ...

[Adam H. Kerman]

Bud Spencer <***@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

Post by Adam H. Kerman
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 ...
--=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.

[Bud Spencer]

Post by Adam H. Kerman
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

Post by Adam H. Kerman
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 ...
--=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.

Breath.

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.

[Eduardo Chappa]

Post by Adam H. Kerman
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.

[Bud Spencer]

Post by Eduardo Chappa

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.

Anyway, could you please point out where I can set this off anyway? Since
I haven't set such thing ... at least not knowingly.

[Adam H. Kerman]

Post by Eduardo Chappa

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.

’

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]

MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: 8BIT

Post by Eduardo Chappa

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.

[Adam H. Kerman]

Post by Eduardo Chappa

Post by Adam H. Kerman
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.
I've just never seen alpine do that before and I have no idea how
to recreate it.

[Bud Spencer]

Post by Adam H. Kerman

Post by Eduardo Chappa

Post by Adam H. Kerman
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.
I've just never seen alpine do that before and I have no idea how
to recreate it.

If you figure that out let me know how I turn that thing off ... so far I
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 Spencer]

Post by Bud Spencer

Post by Adam H. Kerman

Post by Eduardo Chappa

Post by Adam H. Kerman
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.
I've just never seen alpine do that before and I have no idea how
to recreate it.

If you figure that out let me know how I turn that thing off ... so far I
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.

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 :)

[Eduardo Chappa]

Post by Bud Spencer
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.

[Bud Spencer]

Post by Bud Spencer
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,
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.

So nothing is broken then. I'm fine with that.

Thanks for taking time to elaborate this more to my autistic mind :)

[Adam H. Kerman]

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
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Could you help Eduardo? I still have no idea how to set Alpine not to do=

=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.
Eduardo makes sure alpine remains standards compliant.

Thanks for taking time to elaborate this more to my autistic mind :)

[Adam H. Kerman]

Post by Eduardo Chappa

Post by Bud Spencer
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
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.

[Henning Hucke]

Adam H. Kerman <***@chinet.com> wrote:

Hi Adam,

Post by Adam H. Kerman
[...]

Post by Eduardo Chappa
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.

Post by Adam H. Kerman
The issue of attachments is of greater concern than the issue of
quoted-printable.

Here I'm totally with you.

Post by Adam H. Kerman
[...]

Best regards,
Henning

[Adam H. Kerman]

Post by Henning Hucke

Post by Adam H. Kerman
[...]

Post by Eduardo Chappa
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.

Post by Henning Hucke
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.

8Bit Content Transfer Encoding is certainly allowed. Usenet wasn't
restricted to 7bit like SMTP but does retain the 1000 character line
length limit.

Post by Henning Hucke

Post by Adam H. Kerman
The issue of attachments is of greater concern than the issue of
quoted-printable.

Here I'm totally with you.

Is the MIME-aware tools nag message language boilerplate from one of
the standards?

Post by Henning Hucke

Post by Adam H. Kerman
[...]