We are now running on my new gateway code that will hopefully get
even more messages across the Usenet divide.
Please help me keep an eye on the gateway these next couple of days
and verify that it’s running as planned. You can email issues to me
privately at this address.
James Edward G. II
Hey James,
Have you got it on TMail now?
If so and you hit bugs wrt TMail let me know… we’ll get them fixed
asap.
Mikel
On Oct 29, 2007, at 7:37 PM, James Edward G. II wrote:
We are now running on my new gateway code that will hopefully get
even more messages across the Usenet divide.Please help me keep an eye on the gateway these next couple of days
and verify that it’s running as planned. You can email issues to
me privately at this address.
My upgrade did not go as planned and I have reverted, while I figure
it out. Some messages were not gated. I apologize.
James Edward G. II
On Oct 29, 2007, at 7:55 PM, Mikel L. wrote:
Have you got it on TMail now?
My new version uses TMail, yes.
If so and you hit bugs wrt TMail let me know… we’ll get them
fixed asap.
I did have to revert because Usenet was rejecting my posts. It’s how
TMail is doing the headers. For example, TMail constructed a header
like:
“X-Ruby-Talk:\r\n\t<11152772-
[email protected]>\r\n”
My Usenet host rejected that header because it didn’t have a space
after the colon.
I’m hesitant to call that a bug since I’m trying to use an email
library for Usenet posts. Does anyone know if this is a strict
requirement of Usenet posts and/or email?
James Edward G. II
James,
Unless anyone has anything to the contrary, per this RFC it looks like a
bug.
I’ve quoted the RFC below.
James, could you give me a test case for it - or at least the email or
way you created the email and I’ll get this nutted out.
Regards
Mikel
Quote from RFC 822:
August 13, 1982 - 4 - RFC #822
Standard for ARPA Internet Text Messages
3. LEXICAL ANALYSIS OF MESSAGES
3.1. GENERAL DESCRIPTION
A message consists of header fields and, optionally, a body.
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).
3.1.1. LONG HEADER FIELDS
Each header field can be viewed as a single, logical line of
ASCII characters, comprising a field-name and a field-body.
For convenience, the field-body portion of this conceptual
entity can be split into a multiple-line representation; this
is called "folding". The general rule is that wherever there
may be linear-white-space (NOT simply LWSP-chars), a CRLF
immediately followed by AT LEAST one LWSP-char may instead be
inserted. Thus, the single line
To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
can be represented as:
To: "Joe & J. Harvey" <ddd @ Org>,
JJV@BBN
and
To: "Joe & J. Harvey"
<ddd@ Org>, JJV
@BBN
and
To: "Joe &
J. Harvey" <ddd @ Org>, JJV @ BBN
The process of moving from this folded multiple-line
representation of a header field to its single line represen-
tation is called "unfolding". Unfolding is accomplished by
regarding CRLF immediately followed by a LWSP-char as
equivalent to the LWSP-char.
Note: While the standard permits folding wherever linear-
white-space is permitted, it is recommended that struc-
tured fields, such as those containing addresses, limit
folding to higher-level syntactic breaks. For address
fields, it is recommended that such folding occurI did have to revert because Usenet was rejecting my posts. It’s how
TMail is doing the headers. For example, TMail constructed a header
like:“X-Ruby-Talk:\r\n\t<11152772-
[email protected]>\r\n”
James, I just tried this and get a different result:
irb(main):007:0> mail = TMail::Mail.new
=> #<TMail::Mail port=#TMail::StringPort:id=0xa7fa80 bodyport=nil>
irb(main):008:0> mail[‘X-Ruby-Talk’] =
‘[email protected]’
=> “[email protected]”
irb(main):009:0> mail.to_s
=> “X-Ruby-Talk:
[email protected]\n\n”
Leaves a space after the colon and doesn’t introduce a line feed 
Using TMail 1.1.0…
Mikel
Le 30 octobre 2007 à 04:01, James Edward G. II a écrit :
I did have to revert because Usenet was rejecting my posts. It’s how
TMail is doing the headers. For example, TMail constructed a header
like:“X-Ruby-Talk:\r\n\t<11152772-
[email protected]>\r\n”
Double-plus-ungood. Strictly, it may be an acceptable folded header,
but it’s the first time I see that kind of syntax in the wild (with the
break directly after the colon).
My Usenet host rejected that header because it didn’t have a space
after the colon.I’m hesitant to call that a bug since I’m trying to use an email
library for Usenet posts. Does anyone know if this is a strict
requirement of Usenet posts and/or email?
Yes, both. Usenet and mail use the same generic message format (RFC
2822 [1]). The headers used and the signification of those may be
slightly different, but the messages are to be structured the same way.
The real difference comes from the administrative standpoint, where
rules governing (the text part of) Usenet are much more restrictive
(since there are nothing like a binary email address versus a text only
email address).
On Oct 29, 2007, at 7:57 PM, James Edward G. II wrote:
figure it out.
Usenet readers, can you confirm the gateway is functioning as
expected again? My logs tell me messages are being gated again, but
Google G. (my Usenet debugging tool) seems slow to update tonight.
James Edward G. II
On Oct 30, 2007, at 12:39 AM, Mikel L. wrote:
=> #<TMail::Mail port=#TMail::StringPort:id=0xa7fa80 bodyport=nil>
irb(main):008:0> mail[‘X-Ruby-Talk’] =
‘[email protected]’
=> “[email protected]”
irb(main):009:0> mail.to_s
=> “X-Ruby-Talk: <11152772-
[email protected]>\n\n”Leaves a space after the colon and doesn’t introduce a line feed
The gateway code was using the encoded() method:
require “tmail”
=> true
mail = TMail::Mail.new
=> #<TMail::Mail port=#TMail::StringPort:id=0xa26cb4 bodyport=nil>
mail[“X-Ruby-Talk”] = “<11152772-
[email protected]>”
=> “[email protected]”
mail.to_s
=> “X-Ruby-Talk: <11152772-
[email protected]>\n\n”
mail.encoded
=> “X-Ruby-Talk:\r\n\t<11152772-
[email protected]>\r\n\r\n”
Is that not what I should be doing?
James Edward G. II
On Oct 30, 2007, at 8:41 AM, Mikel L. wrote:
No, you are doing it right. Looks like a bug. I’ll get onto it.
Added a bug report
http://rubyforge.org/tracker/index.php?
func=detail&aid=15194&group_id=4512&atid=17370
Mikel, if you could email me (private is fine) when there’s a new
version of TMail I could try that would be great. I would love to
try another deploy of my improved gateway code. Thanks.
James Edward G. II
On Oct 29, 2007, at 7:37 PM, James Edward G. II wrote:
We are now running on my new gateway code that will hopefully get
even more messages across the Usenet divide.
The TMail team tried to squeeze in a fix for our new gateway script
and I tried another deploy this morning. Unfortunately, it still
didn’t work for our needs. We ran into the same issue in a different
place.
I’ve reverted the gateway code again. I was watching for the issue
this time and caught it fast. I believe only one message was not gated.
I apologize again for the continuing issues. We’ll get this stuff
sorted out eventually and hopefully the new features will have been
worth the effort.
James Edward G. II
The new gateway is now in place and does seem to be gating messages.
Hooray for the fixes added to TMail just for us!
I’ll try to monitor the gateway a bit over the next couple of days to
make sure it’s doing its job. Help me out though and email me if you
notice oddities.
Thanks all. Sorry this took so long.
James Edward G. II
On Nov 1, 2007, at 7:34 AM, James Edward G. II wrote:
The new gateway is now in place and does seem to be gating messages.
Just a small update on how this went…
According to my scan of the log this morning, every email the gateway
sent since yesterday’s upgrade was accepted by Usenet. I was even
able to find messages modified by the gateway and they looked great
on comp.lang.ruby.
This transition appears to be a success.
James Edward G. II
No, you are doing it right. Looks like a bug. I’ll get onto it.
Added a bug report
http://rubyforge.org/tracker/index.php?func=detail&aid=15194&group_id=4512&atid=17370
Regards
Mikel
Hi,
On Fri, 2007-11-02 at 21:48 +0900, James Edward G. II wrote:
Just a small update on how this went…
Thank you.
Arlen
Thanks for your work James.
Mikel
In article [email protected],
[email protected] writes:
Thanks for your work James.
According to my scan of the log this morning, every email the gateway
sent since yesterday’s upgrade was accepted by Usenet. I was even
able to find messages modified by the gateway and they looked great
on comp.lang.ruby.This transition appears to be a success.
James Edward G. II
Well, there appears to be at least one little glitch remaining.
The following header line in the immediately referenced article
shouldn’t appear with an unencoded article body:
Content-Transfer-Encoding: Base64
It’s possible that the error was in the originally submitted
message, but I’d guess that it’s more likely that the gateway
translated the body but failed to update the header. In any case,
here’s some more of the header for message identification:
From: [email protected]
Newsgroups: comp.lang.ruby
Subject: Re: Gateway Upgraded
Date: Sat, 3 Nov 2007 02:47:50 -0500
Message-ID:
[email protected]
X-Trace: talisker.lacave.net 1194076112 58526 65.111.164.187 (3 Nov
2007 07:48:32 GMT)
NNTP-Posting-Date: Sat, 3 Nov 2007 07:48:32 +0000 (UTC)
X-Mail-Count: 277342
X-Ml-Name: ruby-talk
X-Rubymirror: Yes
X-Ruby-Talk:
[email protected]
And just as a side remark, I’ll note that the following comment
should be wrapped at normal text width.
X-Received-From: This message has been automatically forwarded from
the
ruby-talk mailing list by a gateway at comp.lang.ruby. If it is
SPAM, it did
not originate at comp.lang.ruby. Please report the original
sender, and not
us. Thanks! For more details about this gateway, please visit:
http://blog.grayproductions.net/categories/the_gateway
Thanks for maintaining the gateway,
On Nov 3, 2007, at 11:10 AM, Douglas Wells wrote:
This transition appears to be a success.
James Edward G. II
Well, there appears to be at least one little glitch remaining.
The following header line in the immediately referenced article
shouldn’t appear with an unencoded article body:Content-Transfer-Encoding: Base64
I’ll look into this issue tomorrow. Thanks for pointing it out.
James Edward G. II
Mikel, I have some TMail questions for you…
On Nov 3, 2007, at 11:10 AM, Douglas Wells wrote:
This transition appears to be a success.
James Edward G. II
Well, there appears to be at least one little glitch remaining.
The following header line in the immediately referenced article
shouldn’t appear with an unencoded article body:Content-Transfer-Encoding: Base64
This was caused by some code like:
incoming = TMail::Mail.parse($stdin.read)
outgoing = TMail::Mail.new
outgoing.transfer_encoding = incoming.transfer_encoding
outgoing.body = incoming.body
I assume that’s because TMail is undoing the Base64 encoding for me
and not putting it back to match the transfer_encoding() of
outgoing. Do I have that right?
What’s the best way for us to fix this? Should I not copy the
transfer encoding of the original message? Will TMail normalize all
of them for me? What does it normalize to? Maybe I should declare
that.
Note that the affected message here was not one the gateway does any
translation for, so this is going to be a widespread issue with the
new gateway and we need to find a sensible solution for it.
visit: http://blog.grayproductions.net/categories/the_gateway
Mikel, why is TMail not wrapping this? I know you added some checks
to ignore X-* headers, but shouldn’t it only ignore them if they
aren’t easily wrapped? This one has a lot of whitespace in it, so
it’s wrappable, right?
Thanks for the help.
James Edward G. II
On Nov 4, 2007, at 5:46 PM, Mikel L. wrote:
Is there any reason you are making two TMail objects instead of just
making one new one and parsing in the incomming string and then adding
what you need?
I use the two message approach because I filter what goes through.
Only certain headers are passed and we may need to translate the
content-type and body. It seems easier to work with a blank slate
than to try and remove all of the unwanted material.
James Edward G. II
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs