free SMTP server
Nad
address in the message header ?
Sam
> Is there any FREE SMTP server that allows me to change the SENDER
> address in the message header ?
Absolutely NOT.
That's because it's not the SMTP server that sets the "SENDER" address.
That's specified by your mail client.
You can use any mail server. You just need to configure your mail client,
accordingly.
Nad
> 1KDownload
Yes, I understand.
But SMTP servers block the entered address. I need a one that can
accept any address.
Sam
Says who?
> I need a one that can
> accept any address.
Every free mail server -- every free one, that I know of, and I know a bit
about half a dozen of the most popular ones -- will cheerfully accept your
address, if you set it to <pres...@whitehouse.gov>, if you cared to do so.
How exactly did you arrive at the conclusion that all mail servers have
engaged into some kind of a conspiracy to replace your defined sender
address, with some other one? This can't be further from the truth. You'll
have to go out of your way to put it some custom hack, in order to replace
the sender's address with something else.
Nad
> Nad writes:
> > On Dec 7, 11:17 pm, Sam <s...@email-scan.com> wrote:
> >> Nad writes:
> >> > Is there any FREE SMTP server that allows me to change the SENDER
> >> > address in the message header ?
>
> >> Absolutely NOT.
>
> >> That's because it's not the SMTP server that sets the "SENDER" address.
> >> That's specified by your mail client.
>
> >> You can use any mail server. You just need to configure your mail client,
> >> accordingly.
>
> >> application_pgp-signature_part
> >> 1KDownload
>
> > Yes, I understand.
> > But SMTP servers block the entered address.
>
> Says who?
>
> > I need a one that can
> > accept any address.
>
> Every free mail server -- every free one, that I know of, and I know a bit
> about half a dozen of the most popular ones -- will cheerfully accept your
>
> How exactly did you arrive at the conclusion that all mail servers have
> engaged into some kind of a conspiracy to replace your defined sender
> address, with some other one? This can't be further from the truth. You'll
> have to go out of your way to put it some custom hack, in order to replace
> the sender's address with something else.
>
> 1KDownload- Hide quoted text -
>
> - Show quoted text -
Maybe you didn't understand me. Suppose I want to send a mail message
from x...@xx.com to y...@yy.com and I want the sender ("mail from" verb)
address to be n...@nn.com instead of the x...@xx.com. Because If I try to
put any address, it is rejected by the SMTP server. Any ideas??
Sam
This must be a custom configuration that this particular SMTP server uses.
It just occured to me that to you mean something completely different by
"free SMTP server" than what most readers of this newsgroup would mean by
that. The common meaning of "free SMTP server" around here is free mail
server software that one would download, compile, and install on their
servers. Here's one such "free SMTP server": http://www.sendmail.org
If what you really mean is that you don't want to use your Internet
provider's mail relay, and you are looking for some other open mail relay
that would deliver your mail, using any return address of your choosing,
then no, there's no such thing, and there never will be. Anyone who stupidly
sets up their mail servers to permit anyone else to use it, as an open mail
relay, will end up being blacklisted to hell before the day is over.
If you do not want to use the mail servers that your Internet provider gives
their customers in order to send mail, because they (wisely) manually set it
up to require you to provide your true return address, then your options
are:
1) Purchase a shared hosted server, with some bandwidth, for $30-$100 a
month, where you can install whatever software your heart desires, and use
it. You can install your own SMTP server, and use it to send your outgoing
mail using any return address you wish.
2) Purchase a broadband package from an Internet provider that allows you to
run your own servers, and do the same with your own machines.
Frank Slootweg
[...]
> If what you really mean is that you don't want to use your Internet
> provider's mail relay, and you are looking for some other open mail
> relay that would deliver your mail, using any return address of your
> choosing, then no, there's no such thing, and there never will be.
> Anyone who stupidly sets up their mail servers to permit anyone else
> to use it, as an open mail relay, will end up being blacklisted to
> hell before the day is over.
I don't think he means *that* 'open'. Yes, 'open' in the sense that he
can set any return address. Not 'open' in the sense that "permit[s]
anyone else to use it, as an open mail relay".
Probably/perhaps he is quite willing to *authenticate* ('login on')
himself to the 'mail relay' - i.e. *not* 'open' - and then wants to be
able to set "MAIL FROM:" and "From:"/etc. to anything he likes - i.e.
'open'.
For example my MSP's mail relay allows me to do exactly that. I.e.
*its customers* can abuse it (and they can - and hopefully will - be
dealt with) but *others* can't.
But your guess is as good as mine, because Nad/Nadeem isn't very clear
in what he wants.
Nad
for a given address (eg. x...@yy.com) and use that server, would that
work?
I tried to send mails to the SAME DOMAIN eg. from x...@yy.com to
n...@yy.com using the relaying server of yy.com but the server always
rejected the sender address; however, if I change the sender address
to any other domain, it works 100% fine. Tha's weird!! What is going
on here?
And another thing I want to say is that if I use the webmail of the
domain not a mail client, I can change the SENDER address to any I
wish and it works 100% fine !!
Any ideas?
Sam
> There must be somewhere to do this. Now I find out the relaying server
> for a given address (eg. x...@yy.com) and use that server, would that
> work?
Yes. Presuming that you'll need to look up each one of your recipient's mail
servers, every domain. You'll have to look up each domain's MX record, for
aol.com, for example:
$ dig aol.com mx
[ … ]
aol.com. 3600 IN MX 15 mailin-02.mx.aol.com.
aol.com. 3600 IN MX 15 mailin-03.mx.aol.com.
aol.com. 3600 IN MX 15 mailin-04.mx.aol.com.
aol.com. 3600 IN MX 15 mailin-01.mx.aol.com.
So, you can connect to any one of these four addresses (there are actually
more than four servers here, but that's besides the point), and deliver mail
to aol.com.
That is, of course, presuming that your Internet provider has not firewalled
their customers from connecting to external mail servers, requiring them to
use your Internet provider's mail relay, for all mail.
> I tried to send mails to the SAME DOMAIN eg. from x...@yy.com to
> n...@yy.com using the relaying server of yy.com but the server always
> rejected the sender address; however, if I change the sender address
> to any other domain, it works 100% fine. Tha's weird!! What is going
> on here?
The only one who can answer this question for you is the administrator of
that mail server, who would presumably know how his mail server is set up.
> And another thing I want to say is that if I use the webmail of the
> domain not a mail client, I can change the SENDER address to any I
> wish and it works 100% fine !!
>
> Any ideas?
Use the webmail server, then.
Nad
> Nad writes:
> > There must be somewhere to do this. Now I find out the relaying server
> > for a given address (eg. x...@yy.com) and use that server, would that
> > work?
>
> Yes. Presuming that you'll need to look up each one of your recipient's mail
> servers, every domain. You'll have to look up each domain's MX record, for
> aol.com, for example:
>
> $ dig aol.com mx
>
>
> aol.com. 3600 IN MX 15 mailin-02.mx.aol.com.
> aol.com. 3600 IN MX 15 mailin-03.mx.aol.com.
> aol.com. 3600 IN MX 15 mailin-04.mx.aol.com.
> aol.com. 3600 IN MX 15 mailin-01.mx.aol.com.
>
> So, you can connect to any one of these four addresses (there are actually
> more than four servers here, but that's besides the point), and deliver mail
> to aol.com.
>
> That is, of course, presuming that your Internet provider has not firewalled
> their customers from connecting to external mail servers, requiring them to
> use your Internet provider's mail relay, for all mail.
>
> > I tried to send mails to the SAME DOMAIN eg. from x...@yy.com to
> > n...@yy.com using the relaying server of yy.com but the server always
> > rejected the sender address; however, if I change the sender address
> > to any other domain, it works 100% fine. Tha's weird!! What is going
> > on here?
>
> The only one who can answer this question for you is the administrator of
> that mail server, who would presumably know how his mail server is set up.
>
> > And another thing I want to say is that if I use the webmail of the
> > domain not a mail client, I can change the SENDER address to any I
> > wish and it works 100% fine !!
>
> > Any ideas?
>
> Use the webmail server, then.
>
> 1KDownload
The problema is that the webmail (which is Squirrelmail) doesn't allow
me to use HTML format messages.
Now what I want to know also is HOW Hotmail can relay to any address.
Why cannot I do that like hotmail?
Sam
Who says you can't? Given a recipient address of us...@domain.com, look up
domain.com's DNS MX records, and connect to the listed mail servers. I just
showed how to do this for aol.com. The same exact process works for any
Internet domain. That's exactly what all mail servers do, to deliver mail,
and absolutely nothing stops you from doing the same.
But if you cannot establish an actually connection, your Internet provider
must be using a firewall that blocks their customers from connecting to
anyone's mail server, except their own. Talk to your Internet provider's
technical support.
D. Stussy
news:cone.1197175815....@commodore.email-scan.com...
Idiot. Don't feed the spammers. (Also, try using plain text next time -
stop the MIME crap.)
Landmark
....
I think the problem with this thread is that you are using way too
much jargon like "SMTP server" and "Relay" and so on without really
knowing what it means. You are making it all far too technical. It
would be better if you explained WHY you want to send a mail with a
different address to the one your ISP has assigned to you.
Your requirement is not uncommon. It happens all the time. I myself
have several email addresses and send mail for all those addresses
through a single mail server. In fact I never use the free address
that was assigned by the ISP.
For example, many small businesses have a domain name and a website,
and want to be able to send mail which appears to come from an address
at that domain, and have replies go back to that domain, even though
they are sending it through their local ISPs mail server. Normally all
they have to do is configure their email client correctly, and just
about any email client can do this.
You also have to take into account the requirements of your ISP which
may want you to use authenticated SMTP and it may require you to first
complete a form on their website to notify them of your requirement to
send outgoing mail using a specific address. They may even require you
to prove you can receive email for that email address by entering a
code they send to it by email. I guess they could even insist on your
domain records having appropriate SPF records to include their mail
server, but I haven't come across any ISPs who ask for that yet.
Sending using a foreign address is such a common requirment that I
don't know of any reputable ISPs who specifically prohibit it. Your
first port of call is your ISP and its help desk. Here on Usenet
people can only speak in generalisms about what is possible. Only your
ISP can tell you what requirements they have and what limitations they
have imposed on you.
If your requirement is to be able to use someone else's address so
that you can discredit someone, spam people, send abusive mail without
it being traced back to yourself, and so on, then you are not going to
get any help from me on how to do that, and hopefully your ISP is
going to be equally unhelpful.
Nad
> domain.com's DNS MX records, and connect to the listed mail servers. I just
> showed how to do this for aol.com. The same exact process works for any
> Internet domain. That's exactly what all mail servers do, to deliver mail,
> and absolutely nothing stops you from doing the same.
>
> But if you cannot establish an actually connection, your Internet provider
> must be using a firewall that blocks their customers from connecting to
> anyone's mail server, except their own. Talk to your Internet provider's
> technical support.
>
> 1KDownload- Hide quoted text -
>
> - Show quoted text -
I already connected to the mail serevr. But the mail server rejects if
I use any address that belong to the same domain, it must be a
completely differente domain. This is the problem now!
How can I send an email with a sender address that has the same
domain? Is that possible since the relaying server denies it?
Sam
> I already connected to the mail serevr. But the mail server rejects if
> I use any address that belong to the same domain, it must be a
> completely differente domain. This is the problem now!
>
> How can I send an email with a sender address that has the same
> domain? Is that possible since the relaying server denies it?
I showed you how to locate and connect to the recipient's mail server, then
you reply that you've already connected to the recipient's mail server, but
in the next paragraph you claim that you've connected to the "relaying" mail
server instead. The recipient's mail server, and the relaying mail server,
are two separate mail servers. Both statements cannot be true at the same
time. I think that you need to step back, and educate yourself on how SMTP
really works, before you proceed any further.
It's going be difficult for anyone to help you if you insist on speaking a
different language that everyone else uses, and continue to use technical
terms that obviously carry a completely different meaning than you think
they do.
Dave Uhring
> D. Stussy writes:
>> Idiot. Don't feed the spammers. (Also, try using plain text next time
>> - stop the MIME crap.)
>
> The idiot is the one who can't read the "Content-Type: text/plain"
Errrm,
Content-Type: multipart/signed;
boundary="=_mimegpg-commodore.email-scan.com-3209-1197213206-0001";
micalg=pgp-sha1; protocol="application/pgp-signature"
Nad
> 1KDownload
I am sorry for mixing stuff. I am not expert in those terms.
I tried an online tool (http://www.mxtoolbox.com) for MX records but
it returned somthing like relay.xx.com which is I suppose the relaying
server for the domain, this is what I connected to. I found no other
server, just one only.
What can I do? Do I need an open Relay server ?
Frank Slootweg
Your point being?
As you *quote*, it says "multipart/signed". Not too hard to understand
- or even just guess - what that means, is it?
"multipart" means that it has more than one part - and guess what, it
has -, and "signed" means it's signed - and guess what, it is.
One part is - as Sam wrote - "Content-Type: text/plain. The other part
is "Content-Type: application/pgp-signature", hence the "/signed" bit.
I.e. two parts, hence "multipart".
A newsreader (or any other UA) should be able to display the
text/plain part. That's *all* that's needed.
But D. Stussy's newsreader - (Microsoft) Outlook Express - doesn't do
that (nor does its (Vista) replacement, Windows Mail). It does *not*
display the text/plain part, but lists it as an *attachment* (which it
*isn't).
It *also* doesn't display the 'preamble' [1] *before* the text/plain
part, so the reader (the person) does not even know what is (not)
happening. I.e. broken beyond recognition.
Not being able to *handle* the *signature* is no problem. Just ignore
it or whatever. My newsreader for example just lists it as
> [-- application/pgp-signature, encoding 7bit, 8 lines --]
i.e. it just says that there's something there which it can't/doesn't
handle.
[1]
<quote>
This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.
</quote
Dave Uhring
> Dave Uhring <daveu...@yahoo.com> wrote:
>> On Sun, 09 Dec 2007 09:13:27 -0600, Sam wrote:
>> > The idiot is the one who can't read the "Content-Type: text/plain"
>>
>> Errrm,
>>
>> Content-Type: multipart/signed;
>> boundary="=_mimegpg-commodore.email-scan.com-3209-1197213206-0001";
>> micalg=pgp-sha1; protocol="application/pgp-signature"
>
> Your point being?
That the Content-Type: shown in his headers is *not* what he claimed it to
be.
The rest of your article is irrelevant.
Frank Slootweg
> On Sun, 09 Dec 2007 20:11:48 +0000, Frank Slootweg wrote:
> > Dave Uhring <daveu...@yahoo.com> wrote:
> >> On Sun, 09 Dec 2007 09:13:27 -0600, Sam wrote:
>
> >> > The idiot is the one who can't read the "Content-Type: text/plain"
> >>
> >> Errrm,
> >>
> >> Content-Type: multipart/signed;
> >> boundary="=_mimegpg-commodore.email-scan.com-3209-1197213206-0001";
> >> micalg=pgp-sha1; protocol="application/pgp-signature"
> >
> > Your point being?
>
> That the Content-Type: shown in his headers is *not* what he claimed it to
> be.
He didn't *claim* that. You incorrectly *assumed* that.
What he actually wrote - and you snipped the essential bit of - was:
S> The idiot is the one who can't read the "Content-Type: text/plain" header,
S> and blames everyone but himself for all the problems in the buggy Microsoft
S> shitware he insists on using.
So he didn't claim that "Content-Type: text/plain" was "in his
headers".
If he 'claimed' anything, then it was that "Content-Type: text/plain"
*is* a header, not that it is *in* his headers. See the difference?
Anyway, even *if* he had claimed that "Content-Type: text/plain" is
"in his headers", he would be correct, but he didn't claim that, so it's
irrelevant.
[N.B. I hope that you're not implying that a "Content-Type:" 'line' in a
body part isn't a 'header', because if that's the case, the RFC(s) say
you're wrong.]
> The rest of your article is irrelevant.
Yeah, sorry for that! My crystal ball was broken, so I had to go by
what you *actually* wrote, not by what you apparently *meant* to write.
Sam
Making another attempt to understand your predicament, you want to send mail
to user...@domain.com, with a return address set to
someth...@domain.com, and your efforts are stymied by the fact that the
recipient's mail server refuses to accept a return address in the
recipient's domain.
One very unlikely situation that you need to eliminate first, would be your
Internet provider having their firewall set to block all connections to
external mail servers, and redirect them to their own customer mail relay,
which requires you to use your own return address. This is very rare, but
there are some Internet providers that do that. To determine if this is your
situation, just connect using telnet, and check the initial banner to
identify who exactly you're talking to. If that's the case, there's nothing
you can do. Your Internet provider will not let you connect to any other
mail server, except their own. You can find a thousand open mail relays out
there, and it won't do you any good.
But even in the most straightforward interpretation, where the recipient's
mail server refuses to accept mail with an obviously forged return address,
nobody is going to blame anyone for this. You're asking it to accept mail
with a return address that misrepresents the message's true sender. You are
the ones sending this message, and not the sender address you claim in MAIL
FROM:; the recipient's mail server has some rudimentary checks that
identifies this to be the case, and it refuses to play along. Again, there's
nothing that you can do.
What you will come away with, from this situation, is that you will end up
understanding that sending E-mail is not a right, and nobody is required to
accept E-mail from you, or from anyone else. A mail server is under the
control of its administrator, who has the final say as to how the mail
server is configured. The mail server's administrator, and not you, decides
who they accept mail from, and for which reasons. If the recipient's mail
server refuses to accept mail from you, because you do not supply your true
E-mail address, and make something up instead, for whatever reason, you'll
just have to deal with it. No amount of tricks is going to change that.
Sam
Errrm,
http://www.ietf.org/rfc/rfc2045.txt, dated November 1996
Page 8.
Let me know when you've decided to wake up in the 21st century.
Making of fun of self-appointed experts, who actually know shit about the
subject matter they claim to be an authority on, and have never written a
single line of code that's used by anyone else, is my favorite pastime.
Nad
> somethinge...@domain.com, and your efforts are stymied by the fact that the
> 1KDownload- Hide quoted text -
>
> - Show quoted text -
Actually, I am not sure if the server is rejecting the sender address.
When I send a message using telnet "TELNET relay.xx.com 25" and I use
any other domain, the message is sent successfully. If I use the same
domain, the server accepts it (250 sender OK) and finally appears
"Mail queued for delivery."
At the beginning, I thought that the message was sent, but then
realized that the message never arrived into the mailbox (this is the
weird thing)
I used GMAIL smtp server and changed the FROM address; however, the
sender address is always padded into the message header. Is there a
place where I can find more info or help??
and Thanks for the help Sam!!!
D. Stussy
news:475c4c04$0$47023$dbd4...@news.wanadoo.nl...
When will that dickhead learn that MIME encoded messages are not appropriate
for USENET. However, at least he isn't using HTML on top of it all. Please
also note that I use different readers depending on which machine I happen
to be on when viewing a message (e.g. "pine" on linux). However, regardless
of the reader used, his crap is still there.
What I see is this crap:
This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in
1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.
--=_mimegpg-commodore.email-scan.com-3209-1197213206-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
D. Stussy writes:
> "Sam" <s...@email-scan.com> wrote in message
> news:cone.1197175815....@commodore.email-scan.com...
>
> Idiot. Don't feed the spammers. (Also, try using plain text next time -
> stop the MIME crap.)
The idiot is the one who can't read the "Content-Type: text/plain" header,
and blames everyone but himself for all the problems in the buggy Microsoft
shitware he insists on using.
--=_mimegpg-commodore.email-scan.com-3209-1197213206-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBHXAYWx9p3GYHlUOIRAhtnAJoC2mbZIjVbGl8q3jkwAY/6rMFc4gCeNaZD
qQpv0x69cbjXN9OlOlFVfC8=
=t2mc
-----END PGP SIGNATURE-----
--=_mimegpg-commodore.email-scan.com-3209-1197213206-0001--
Sam
> When will my mental superior learn that MIME encoded messages are not
> appropriate for USENET.
When someone invents the TARDIS, and we can all go back to the '90s, when
the Internet was a happy place without all those furriners speaking funny
languages, and posting messages with funny characters in them.
> What I see is this crap:
>
> This is a MIME GnuPG-signed message. If you see this text, it means that
> your E-mail or Usenet software does not support MIME signed messages.
> The Internet standard for MIME PGP messages, RFC 2015, was published in
> 1996.
> To open this message correctly you will need to install E-mail or Usenet
> software that supports modern Internet standards.
And that is absolutely true. Go bitch to Microsoft. It's their newsreader
that's broken, and only they can fix it.
> The idiot is the one who can't read the "Content-Type: text/plain" header,
> and blames everyone but himself for all the problems in the buggy Microsoft
> shitware he insists on using.
Truer words were never spoken.
Sam
> On Sun, 9 Dec 2007, Sam wrote:
>> > When will my mental superior learn that MIME encoded messages are not
>> > appropriate for USENET.
>>
>> When someone invents the TARDIS, and we can all go back to the '90s, when the
>> Internet was a happy place without all those furriners speaking funny
>> languages, and posting messages with funny characters in them.
>
> Nowhwere does that relate to the real world - where anything other than
> text/plain messages are still BANNED from most of usenet.
Right. That's why you see this content's headers tag it "Content-Type:
text/plain".
Now, that wasn't that difficult to figure out, was it?
> Just because you
> WANT the rules to change doesn't mean that they ever will.
They already did. Sorry to see you confused by facts.
> Note, asshole, that I didn't post this using any M$ $hitware.
Noted that, this time, your Usenet software had no apparent issues
processing MIME-compliant content.
Thank you for proving me right. Be sure to let us know the instant your copy
of "Microsoft Outlook Express 6.00.2800.1478" figures out how to properly
implement Internet standards.
D. Stussy
WRONG. Your "text/plain" definition is NOT in the headers - nor is it the
first part of your MIME message. I already showed you that. Regardless,
MIME messages are not allowed in text groups. When are you going to figure
that out?
Sam
> "Sam" <s...@email-scan.com> wrote in message
> news:cone.1197252562....@commodore.email-scan.com...
>
> WRONG. Your "text/plain" definition is NOT in the headers - nor is it the
Yes, they are. See RFC 2045.
> first part of your MIME message. I already showed you that. Regardless,
> MIME messages are not allowed in text groups.
They are most certainly are allowed, you're just in denial.
The windmills are over there. Here's your sword. Good luck!
> When are you going to figure
> that out?
When are you going to figure out that you are an intolerant bigot who
believes that non-English speakers should not be allowed to post on Usenet,
in their own language and non-Latin text?
Fortunately, Internet, and Usenet, has expanded beyond its Latin-1 roots
many decades ago, and has developed standards that include non-English
character sets, languages, and other extensions that go beyond the simpleton
view of Internet that you have as a result of being stuck in the '80s.
But, I guess, for some quaint reason some people still choose to believe
that they live in a world of many days ago, before MIME, and other funny
notions. It's still not clear what motivates their stubborn insistence to
turn back the clock of time, and progress.
But fortunately they are a small, tiny minority. None of them have ever
written or participated in development of any kind of messaging software,
despite their insistence that they are entitled to sit on a throne and judge
what that software should or should not do.
Come back, sir, when your E-mail software is used by thousands of ISPs
worldwide. Until such a surprising event happens, you can just bite my shiny
metal ass.
D. Stussy
Looks like this asshole will never learn.
"Content-Type: multipart/signed; ..." is NOT a header stating "text/plain."
NM Public
>
> I used GMAIL smtp server and changed the FROM address; however, the
> sender address is always padded into the message header. Is there a
> place where I can find more info or help??
If you use the Gmail outgoing SMTP server, you need to use either
your Gmail address or a *validated* alternate address in your
From: header. Details are here:
Setting custom 'From:' addresses in my mail client
<http://gmail.google.com/support/bin/answer.py?answer=81375&topic=12896>
Using a custom 'From:' address to send
<http://mail.google.com/support/bin/answer.py?answer=22370>
I've also written about this on my Power Pine page in this
section:
Gmail Tips
<http://www.ii.com/internet/messaging/pine/pc/#gmailTips>
If you are learning about and experimenting with email,
especially SMTP and/or IMAP, I recommend that you use Pine or
Alpine because they are 1) reasonably user friendly and 2) very
powerful and customizable. Details are here:
<http://www.washington.edu/alpine/>
Good luck with all this,
Nancy
Frank Slootweg
[...]
> When will that dickhead learn that MIME encoded messages are not appropriate
> for USENET. However, at least he isn't using HTML on top of it all.
You are confused/uninformed about what MIME is and is not, and hence
are quite unarmed in 'fights' with people (*not* me) who *are* informed.
"MIME encoded messages" surely *are* "appropriate for USENET", just
not *all* MIME messages. You already gave an example of 'inappropriate'
MIME messages, those with text/html parts.
But for example "MIME encoded messages" are a *must* - and hence
appropriate - for postings containing non-ASCII characters. Since - for
example - 'even' American English uses non-ASCII characters and some
Americans have names with non-ASCII characters in them, this is *not* an
issue of the US versus the rest of the world, so please don't even *try*
to go there.
So "MIME encoded messages are not appropriate for USENET" is clearly a
false statement, given the above appropriate use.
So what do we have? Some MIME on Usenet is 'bad' (HTML) and some is
'good' (non-ASCII characters).
Now to the case at hand. A newsreader must do *some* MIME, otherwise
it can't do non-ASCII characters, which is unacceptable. So it *must* be
able to handle MIME text/plain. And - as I said in my earlier response -
that's *all* it has to do. It can just *ignore* what it can't handle,
i.e. the PGP signature.
> What I see is this crap:
>
> This is a MIME GnuPG-signed message. If you see this text, it means that
> your E-mail or Usenet software does not support MIME signed messages.
> The Internet standard for MIME PGP messages, RFC 2015, was published in
> 1996.
> To open this message correctly you will need to install E-mail or Usenet
> software that supports modern Internet standards.
>
> --=_mimegpg-commodore.email-scan.com-3209-1197213206-0001
> Content-Type: text/plain; format=flowed; charset="US-ASCII"
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit
If you see that 'crap' then your newsreader doesn't do *any* MIME,
i.e. not even text/plain, and is clearly broken. Sam references RFC 2015
of 1996, because he's specifically talking about MIME *PGP* messages.
But the *general* MIME standard, i.e. for text/plain, is much older,
namely 1992/1993.
And Outlook Express and Windows Mail are broken because they do *some*
MIME, but do it incorrectly. I.e. as I said, it's perfectly fine for
them not to *handle* the PGP signature, but there's *no* excuse for not
displaying the text/plain part (but listing it as an attachment, which
it is *not*).
As I said, my newsreader just displays the text/plain part (and lists,
but does not handle, the PGP signature). I.e. it handles MIME
text/plain, but does not handle MIME PGP signatures. Perfectly fine by
me.
I hope this helps.
If you respond, then please refrain from flaming, ranting, etc.,
because it brings nothing and only makes *you* look bad.
Sam
> "Sam" <s...@email-scan.com> wrote in message
> news:cone.1197256122....@commodore.email-scan.com...
>
> Looks like this asshole will never learn.
IKWYABWAI.
> "Content-Type: multipart/signed; ..." is NOT a header stating "text/plain."
And you're just not smart enough to understand RFC 2045. End of story.
D. Stussy
> And you're just not smart enough to understand RFC 2045. End of story.
And you're not smart enough to realize that RFC's are proposals, not
standards. Regardless, your message is still malformed - even for MIME (the
un-MIME-encapsulated section at the top of your message body needs a
content-type declaration).
Sam
> "Sam" <s...@email-scan.com> wrote in message
> news:cone.1197288065....@commodore.email-scan.com...
>> And you're just not smart enough to understand RFC 2045. End of story.
>
> And you're not smart enough to realize that RFC's are proposals, not
> standards.
And you are not smart enough to realize that some RFCs are, indeed,
standards, or what "standards track", at the top of RFC 2045, means.
Actually, you're not even smart enough to know what an Internet standard is,
either.
> Regardless, your message is still malformed - even for MIME (the
> un-MIME-encapsulated section at the top of your message body needs a
> content-type declaration).
No, it doesn't. See RFC 2046, page 21.
A good rule of thumb to follow is that whatever anyone says here regarding
Internet standards, if the message is posted by a Microsoft client, the
correct answer always lies 180 degrees to the opposite.
D. Stussy
> D. Stussy <sp...@bde-arc.ampr.org> wrote:
> [...]
>
> > When will that dickhead learn that MIME encoded messages are not
appropriate
> > for USENET. However, at least he isn't using HTML on top of it all.
>
> You are confused/uninformed about what MIME is and is not, and hence
> are quite unarmed in 'fights' with people (*not* me) who *are* informed.
>
> "MIME encoded messages" surely *are* "appropriate for USENET", just
> not *all* MIME messages. You already gave an example of 'inappropriate'
> MIME messages, those with text/html parts.
>
> But for example "MIME encoded messages" are a *must* - and hence
> appropriate - for postings containing non-ASCII characters. Since - for
> example - 'even' American English uses non-ASCII characters and some
> Americans have names with non-ASCII characters in them, this is *not* an
> issue of the US versus the rest of the world, so please don't even *try*
> to go there.
>
> So "MIME encoded messages are not appropriate for USENET" is clearly a
> false statement, given the above appropriate use.
Just because it was proposed doesn't make it widely accepted....
Furthermore, English-speaking groups need none of the extra characters that
other languages use, and therefore weren't subject to the extension proposed
in the first place.
> So what do we have? Some MIME on Usenet is 'bad' (HTML) and some is
> 'good' (non-ASCII characters).
>
> Now to the case at hand. A newsreader must do *some* MIME, otherwise
> it can't do non-ASCII characters, which is unacceptable. So it *must* be
> able to handle MIME text/plain. And - as I said in my earlier response -
> that's *all* it has to do. It can just *ignore* what it can't handle,
> i.e. the PGP signature.
>
> > What I see is this crap:
> >
> > This is a MIME GnuPG-signed message. If you see this text, it means
that
> > your E-mail or Usenet software does not support MIME signed messages.
> > The Internet standard for MIME PGP messages, RFC 2015, was published in
> > 1996.
> > To open this message correctly you will need to install E-mail or Usenet
> > software that supports modern Internet standards.
> >
> > --=_mimegpg-commodore.email-scan.com-3209-1197213206-0001
> > Content-Type: text/plain; format=flowed; charset="US-ASCII"
> > Content-Disposition: inline
> > Content-Transfer-Encoding: 7bit
>
> If you see that 'crap' then your newsreader doesn't do *any* MIME,
> i.e. not even text/plain, and is clearly broken. Sam references RFC 2015
> of 1996, because he's specifically talking about MIME *PGP* messages.
> But the *general* MIME standard, i.e. for text/plain, is much older,
> namely 1992/1993.
I was looking at the raw message - and note that there is UNENCAPSULATED
text. That is an error. EVERY part of a multi-part message must start with
its own MIME declaration. RFC 2015 refers back to RFC 1847 - which says
this (section 2.1 "exactly 2 body parts" and section 2.2 - same). The
unencapsulated text forms a THIRD part - which is forbidden. Therefore,
even if these RFC's are now standard, he's doing it wrong.
It doesn't matter what news client I use. The message is malformed.
D. Stussy
2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies. N. Freed, N. Borenstein. November 1996.
(Format: TXT=72932 bytes) (Obsoletes RFC1521, RFC1522, RFC1590)
(Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD)
DRAFT Standard means NOT FORMALLY APPROVED.
Also, you failed to note that I also used a NON-M$ product and have the same
issues with your posting.
Frank Slootweg
> D. Stussy writes:
[...]
> > Also, you failed to note that I also used a NON-M$ product and have the same
> > issues with your posting.
>
>
> # X-Newsreader: Microsoft Outlook Express 6.00.2800.1478
> # X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
>
> Yup, a "NON-M$" product. Suuuuuuure. Pull the other one, it's got bells on
> it.
Well, in <news:fji27v$o8b$4...@snarked.org> he claims to also use Pine:
DS> Please also note that I use different readers depending on which
DS> machine I happen to be on when viewing a message (e.g. "pine" on
DS> linux). However, regardless of the reader used, his crap is still
DS> there.
and in <Pine.LNX.4.64.07...@kd6lvw.ampr.org> he seems to do
so.
Frank Slootweg
> "Frank Slootweg" <th...@ddress.is.invalid> wrote in message
> news:475d28c1$0$18960$dbd4...@news.wanadoo.nl...
> > D. Stussy <sp...@bde-arc.ampr.org> wrote:
> > [...]
> >
> > > When will that dickhead learn that MIME encoded messages are not
> appropriate
> > > for USENET. However, at least he isn't using HTML on top of it all.
> >
> > You are confused/uninformed about what MIME is and is not, and hence
> > are quite unarmed in 'fights' with people (*not* me) who *are* informed.
> >
> > "MIME encoded messages" surely *are* "appropriate for USENET", just
> > not *all* MIME messages. You already gave an example of 'inappropriate'
> > MIME messages, those with text/html parts.
> >
> > But for example "MIME encoded messages" are a *must* - and hence
> > appropriate - for postings containing non-ASCII characters. Since - for
> > example - 'even' American English uses non-ASCII characters and some
> > Americans have names with non-ASCII characters in them, this is *not* an
> > issue of the US versus the rest of the world, so please don't even *try*
> > to go there.
> >
> > So "MIME encoded messages are not appropriate for USENET" is clearly a
> > false statement, given the above appropriate use.
>
> Just because it was proposed doesn't make it widely accepted....
If by "it" you mean MIME, then 1) it is not "proposed" but an active
standard and 2) it *is* widely accepted, 'even' some of your postings in
this very thread do have MIME headers.
> Furthermore, English-speaking groups need none of the extra characters that
> other languages use, and therefore weren't subject to the extension proposed
> in the first place.
Please try to read for comprehension. I *specifically* said (see your
quote above):
> Since - for
> > example - 'even' American English uses non-ASCII characters and some
> > Americans have names with non-ASCII characters in them, this is *not* an
> > issue of the US versus the rest of the world, so please don't even *try*
> > to go there.
Your denial of reality doesn't change it in any way. American-English
*does* use non-ASCII characters and some Americans *do* have names with
non-ASCII characters in them. And - as I *said* - these are only
*examples*, i.e. *not* each and every possible use of / need for
non-ASCII characters. (Not to mention that (your) "English" is not
limited to *American* English. Can you say "pound"?)
[...]
> I was looking at the raw message - and note that there is UNENCAPSULATED
> text. That is an error. EVERY part of a multi-part message must start with
> its own MIME declaration. RFC 2015 refers back to RFC 1847 - which says
> this (section 2.1 "exactly 2 body parts" and section 2.2 - same). The
> unencapsulated text forms a THIRD part - which is forbidden. Therefore,
> even if these RFC's are now standard, he's doing it wrong.
>
> It doesn't matter what news client I use. The message is malformed.
Sam already debunked that with his reference to page 21 of RFC 2046.
Note that the example on that page uses the term "preamble" which is
the *exact* same term as I used in my first response. I.e. what you call
"UNENCAPSULATED text" is a preamble which is *specifically* allowed for
the *exact* purpose for which Sam uses it:
<RFC 2046>
This is the preamble. It is to be ignored, though it
is a handy place for composition agents to include an
explanatory note to non-MIME conformant readers.
</RFC 2046>
Sam
> the *exact* purpose for which Sam uses it:
>
> <RFC 2046>
>
> This is the preamble. It is to be ignored, though it
> is a handy place for composition agents to include an
> explanatory note to non-MIME conformant readers.
>
> </RFC 2046>
100 quatloos on this character picking up this thread in about 6 months,
long after he forgets how bad his ass-spanking was, this time.
D. Stussy
It's a (draft) standard for EMAIL - not for USENET, except where NECESSARY.
Signing your messages isn't necessary.
> > Furthermore, English-speaking groups need none of the extra characters
that
> > other languages use, and therefore weren't subject to the extension
proposed
> > in the first place.
>
> Please try to read for comprehension. I *specifically* said (see your
> quote above):
>
> > Since - for
> > > example - 'even' American English uses non-ASCII characters and some
> > > Americans have names with non-ASCII characters in them, this is *not*
an
> > > issue of the US versus the rest of the world, so please don't even
*try*
> > > to go there.
I didn't say that. However, American English uses only 26 letters, plus a
few punctuation marks - all within ASCII (i.e. 7 bit). There are no
American names that use other characters. Regardless, RFC 3977 (PROPOSED)
changes the default character set to UTF-8 which does have all the
non-English but Latin alphabet characters that appear in names (i.e.
accented and other letters).
Preambles are allowed only in MAIL (SMTP) messages. Look at the comment
regarding an X.400-transmitted MIME message and you will find that the
preamble and epilogue sections are NOT allowed. These sections do not apply
to non-SMTP implementations of MIME (RFC 1341, section 7.2.1 - on page 32):
"NOTE: These "preamble" and "epilogue" areas are not used
because of the lack of proper typing of these parts and the
lack of clear semantics for handling these areas at
gateways, particularly X.400 gateways."
It clearly follows that other message formats that use MIME messages (e.g.
NNTP) also must lack these parts. Although the NNTP message format borrows
much from the e-mail formats, this is one part that they LACK.
Interestingly, RFC 3977 (at section 10.2) suggests MIME as one possible
solution AMONG OTHERS, it does NOT officially sanction its use in
NNTP-transported articles. You say it's a standard! It is clear that it is
NOT ADOPTED. (RFC 3977 itself is still in the PROPOSED state. Earlier NNTP
standards, proposed or final, don't reference MIME extensions. No later
RFC's address article content.)
Even if MIME were accepted into NNTP at a full standard level, as a non-SMTP
transmission, that means that the preamble and epilogue sections are NOT
permitted (nor does RFC 3977 suggest that they should be allowed despite its
non-SMTP nature).
Lastly, why even "sign" a normal USENET message? This is not a message
needed for control. No one really cares whether messages are from the
author claimed anymore (or not). Only pretentious self-involved jerks who
are legends in their own minds would dare use such a construct - just to
waste everyone's bandwidth with addtional "junk" to the message payload that
adds no value, intrinsic or otherwise, except for their self-gratification
of self-importance.
Frank Slootweg
> "Frank Slootweg" <th...@ddress.is.invalid> wrote in message
[...]
> > If by "it" you mean MIME, then 1) it is not "proposed" but an active
> > standard and 2) it *is* widely accepted, 'even' some of your postings in
> > this very thread do have MIME headers.
>
> It's a (draft) standard for EMAIL - not for USENET, except where NECESSARY.
*If* that is so - which it's obviously not - what's *your* excuse for
using MIME in Usenet articles? You can't have your cake and eat it too.
> Signing your messages isn't necessary.
Is your *opinion*. It happens also to be mine. But our opinions are
irrelevant. They/we do not determine what is allowed or not. That's
determined by RFCs and common use. As demonstrated, Sam articles conform
to the applicable RFCs and *hence* non-broken newsreaders don't have any
problems with them, and don't show what 'we' don't want showed.
Your newsreaders are broken and you apparently can't stand PGP signed
articles. So your killfile [1] is your friend.
> > > Furthermore, English-speaking groups need none of the extra
> > > characters that other languages use, and therefore weren't subject
> > > to the extension proposed in the first place.
> >
> > Please try to read for comprehension. I *specifically* said (see your
> > quote above):
> >
> > > > Since - for example - 'even' American English uses non-ASCII
> > > > characters and some Americans have names with non-ASCII
> > > > characters in them, this is *not* an issue of the US versus the
> > > > rest of the world, so please don't even *try* to go there.
>
> I didn't say that. However, American English uses only 26 letters, plus a
> few punctuation marks - all within ASCII (i.e. 7 bit). There are no
> American names that use other characters.
As I *said*, American English *does* use non-ASCII characters, for
example diacriticals. Your apparent ignorance on the subject matter does
not change the fact.
And I didn't say "American names", I said "some Americans have names
...". Since this is entering the area of bigotry or even racism, I'll
stop here.
Anyway, the point is totally irrelevant, because "English-speaking
groups" does *not* mean *American* groups where *Americans* only talk
about *American* stuff. As soon as anybody says anything, anywhere,
where *partly* a (in your mind) 'foreign' language is used/referenced,
non-ASCII characters are needed, and hence MIME. EOD.
> Regardless, RFC 3977 (PROPOSED)
> changes the default character set to UTF-8 which does have all the
> non-English but Latin alphabet characters that appear in names (i.e.
> accented and other letters).
Your point being? Both current character sets like ISO/8859 and UTF-8
need MIME, so it makes no difference.
> > > It doesn't matter what news client I use. The message is malformed.
> >
> > Sam already debunked that with his reference to page 21 of RFC 2046.
> >
> > Note that the example on that page uses the term "preamble" which is
> > the *exact* same term as I used in my first response. I.e. what you call
> > "UNENCAPSULATED text" is a preamble which is *specifically* allowed for
> > the *exact* purpose for which Sam uses it:
> >
> > <RFC 2046>
> >
> > This is the preamble. It is to be ignored, though it
> > is a handy place for composition agents to include an
> > explanatory note to non-MIME conformant readers.
> >
> > </RFC 2046>
>
> Preambles are allowed only in MAIL (SMTP) messages. Look at the comment
> regarding an X.400-transmitted MIME message and you will find that the
> preamble and epilogue sections are NOT allowed. These sections do not apply
> to non-SMTP implementations of MIME (RFC 1341, section 7.2.1 - on page 32):
>
> "NOTE: These "preamble" and "epilogue" areas are not used
> because of the lack of proper typing of these parts and the
> lack of clear semantics for handling these areas at
> gateways, particularly X.400 gateways."
>
> It clearly follows that other message formats that use MIME messages (e.g.
> NNTP) also must lack these parts.
Since you're mixing up message formats and transport protocols, it's
better you stop right here.
[...]
> Lastly, why even "sign" a normal USENET message? This is not a message
> needed for control. No one really cares whether messages are from the
> author claimed anymore (or not). Only pretentious self-involved jerks who
> are legends in their own minds would dare use such a construct - just to
> waste everyone's bandwidth with addtional "junk" to the message payload that
> adds no value, intrinsic or otherwise, except for their self-gratification
> of self-importance.
*Finally* you come to your point. Why hide between broken newsreaders,
misinterpretations of RFCs, denial of reality, etc., etc., when the
*real* problem is that you *dislike* (or stronger) what he's doing? (And
please don't pull the bandwidth-waste non-argument. There's much more
and much more waste than this.)
As I said above, your killfile [1] is your friend.
[1] Even OE/WM can kill on author.