There is a server A and Alpine is running on that server and is
configured to talk with mail.server.a and there is [email protected]
account.
Then I'll set up Alpine to use IMAP to get E-Mails from server B, [email protected] ... now when I send E-Mails as [email protected] using mail.server.b, does Alpine include some indentifying things into header
of those E-Mails that can point out to server.a?
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 [email protected] account.
Then I'll set up Alpine to use IMAP to get E-Mails from server B,
[email protected] ... now when I send E-Mails as [email protected] 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
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.
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.
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?
Hi there.
[...]
There is a server A and Alpine is running on that server and is configured
to talk with mail.server.a and there is [email protected] account.
Then I'll set up Alpine to use IMAP to get E-Mails from server B, [email protected] ... now when I send E-Mails as [email protected] 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 Spencer <[email protected]> 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 [email protected] account.
Then I'll set up Alpine to use IMAP to get E-Mails from server B,
[email protected] ... now when I send E-Mails as [email protected] 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.
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!
[-- text/plain, encoding quoted-printable, charset: UTF-8, 50 lines --]
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
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 Spencer <[email protected]> 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?
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
to talk with mail.server.a and there is [email protected] account.
Then I'll set up Alpine to use IMAP to get E-Mails from server B,=20 >[email protected] ... now when I send E-Mails as [email protected] 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
=E2=82=AA BUD =E2=82=AA
--2739015498-468396953-1659547978=:11738--
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-288430170-1659733859=:87688
Content-Type: text/plain; charset=UTF-8; format=flowed >Content-Transfer-Encoding: QUOTED-PRINTABLE
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 ...
--=20
=E2=82=AA BUD =E2=82=AA
--2739015498-288430170-1659733859=:87688--
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.
Bud Spencer <[email protected]> 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
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 ...
--=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.
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.
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.
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 <[email protected]> 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.
?
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.
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.
Eduardo Chappa <[email protected]> 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.
I've just never seen alpine do that before and I have no idea how
to recreate it.
On Sun, 7 Aug 2022, Adam H. Kerman wrote:
Eduardo Chappa <[email protected]> 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.
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 :)
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.
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
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= >=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.
Thanks for taking time to elaborate this more to my autistic mind :)
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.
Eduardo Chappa <[email protected]> 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.
The issue of attachments is of greater concern than the issue of quoted-printable.
[...]
Adam H. Kerman <[email protected]> wrote:
Eduardo Chappa <[email protected]> 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.
The issue of attachments is of greater concern than the issue of >>quoted-printable.
Here I'm totally with you.
[...]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 156:42:14 |
| Calls: | 12,093 |
| Calls today: | 1 |
| Files: | 15,000 |
| Messages: | 6,517,739 |