[ANN] TMail 1.2.1

[Mikel Lindsaar]

TMail is The Mail Handling Library for Ruby!

TMail is the Ruby Mail handler used in the
Ruby on Rails and Nitro web frame works as
well as many others (now including, the Ruby
Talk mail gateway!).

TMail is now a gem. You can install it on any
platform via:

# gem install tmail

Alternatively you can download the source code
or view extra documentation at the website:

http://tmail.rubyforge.org/


Release Summary:
------------------
New release handles five tickets in the TMail
tracker as well as a lot more documentation and
renames a library to handle copyright concerns.

Additionally added 25 more test cases to the library
to handle the above tickets.

This should be a drop in replacement for existing
TMail installations.


Release Update Details:
-------------------------

Closed #16899 - HeaderField.new_from_port and added test
cases to cover this code. Also changed behaviour of
HeaderField.new_from_port to return nil if it does not
find a matching header in the port provided (would previously
return an empty Header object which you could do nothing
with beyond deleting it). Extended UNIXMbox.fromaddr to
also search for EnvelopeSender and also made it a public
method, not private - Thanks to Maarten O. for alerting
on these bugs.

Closed #16900 - UNIXMbox.fromaddr missing port param and
does not return Envelope Sender. This report was
initially to correct typo on "Regep" to "Regexp". Also
added test cases to cover this class method. Also added
ability to scan for the EnvelopeSender explictly as it
would not come up on searching for "From" due to Regexp
confilct with From: (with the colon). Thanks to Maarten
O. for reporting this.

Closed 16025 - TMail scanner.rb would not parse ATOM
chars correctly making it fail tests where the C version
passed them. Fixed this by updating the Scanner.rb
version to be in step with the C version (there was an
extra @ symbol in the ATOM CHARS definition that was not
in the C version.) This was initially done in the Rails version
of TMail and has been removed. Apple Mail.app used to
send unquoted '@' chars in an address line which is not
per RFC and so this "patch" which breaks other things
has been removed. (mikel)

Closed 16283 - TMail would not decode correctly due to
bug in text-utils - put in previous patch from old tmail
trunk version. Thanks to garyo for spotting this.

Closed Bug - Handled quote boundary being gready on
content-type header fields (M. Mondragon)

Changed the name of mailscanner to tmailscanner to handle
a copyright issue. MailScanner is a copyrighted name.

Added about 15 test cases from the Rails community. Added
failing test case for an unquoted @ char in the From
header field.

See the changelog for previous changes.


Bug Reports / Fixes:
----------------------

As always, we really welcome any bug reports or code
for patches you have created. Please submit anything
you find through our RubyForge tracker project which
you can get to from our website:

http://tmail.rubyforge.org/


We hope you enjoy this release!


Mikel & The Growing TMail Team

 

[Mikel Lindsaar]

Just a follow up with this, there was a slight hitch in the release =>
made a bad gem.

We are fixing this, so right now the files are missing from the gem
servers (because I yanked them). Will be back there soon.

Sorry for the hassle

Regards

Mikel

 

[Mikel Lindsaar]

Hello everyone,

Sorry about the false start on this, but:

"Step right up, step right up!

TMail 1.2.1 is now up on Rubyforge for young and old to download!

Act now and not only will you get the best ruby mail handler known to
mankind* you will also get a free set of steak knives**!"

Files at: http://rubyforge.org/frs/?group_id=4512&release_id=18049


Regards


Mikel

* statement only true as of writing with the definition of mankind =
Mikel Lindsaar
** offer only valid for anyone standing within a 500m radius of me at
time of posting.

 

[Charles Lowe]

This is great news! No more action_mailer when all you really want is
tmail.

I wonder though - something I came up against before - is there a way to
attach a large binary file (using ports?) without reading it in its
entirety first? Ideally, you could just point the attachement to an IO
object, set the associated filters (eg base64), and then get it to
stream it to disk / smtp server.

 

[Mikel Lindsaar]

This is great news! No more action_mailer when all you really want is
tmail.

Heh.. that's exactly how I got myself into the corner of becoming the
maintainer

I wonder though - something I came up against before - is there a way to
attach a large binary file (using ports?) without reading it in its
entirety first? Ideally, you could just point the attachement to an IO
object, set the associated filters (eg base64), and then get it to
stream it to disk / smtp server.

Good idea. Though TMail itself has no concept of SMTP or POP3 or any
other protocol really, it just handles the mail object headers really.
Doesn't touch the body.

It makes sense, I guess we would have to give a TMail::Mail object to
be able to accept a Net::SMTP object and wrap it (much the same way we
do with TMail::Mail.load)

Have you played much with the ports area? To be brutally honest, it
is something I am only starting to dive into, I have been
concentrating on getting all the existing tests passing (which they
all do now in trunk, for 1.9 and 1.8.6) and getting all the address
and header parsing working (which a lot more works now than it did
before) and finally documentation (there is a LOT more docs than there
was in 0.9).

Now that we have 1.9 compatibility wrapped I want to focus more on
adding more documentation and fixing any other bugs for the 1.2
branch. But I would love a hand if you want to give it a shot. We
need some more TMail developers I think

My ideal scene for TMail would be being able to just define the mail
object, give it a Net::SMTP connection and say "go send thyself" and
it handles the rest.

But need some more hands for that

Mikel

 

[Charles Lowe]

You could certainly have TMail have a concept of SMTP/POP3 if you wanted
to wrap it up in a helper method, but all I really mean is to be able to
write the message to an IO (/Port) like object, for streaming to file,
socket etc. Eg:

Net::SMTP.start('...') do |smtp|
smtp.open_message_stream, '...', ['...'] do |io|
tmail.write io
end
end

And similarly:

open('mymail.eml', 'w') { |f| tmail.write f }

Like you say though, this is maybe possible with the Ports abstraction
that exists currently (though I must admit I'm not sure what Ports
really adds over just using regular IO object interfaces.)

What doesn't seem to be possible is to chain filters in a lazy streaming
way on top of ports. I'd like to be able to write this kind of thing:

part = TMail::Mail.new
part.content_type = 'text/html'
part.body = open('test.html')
tmail << part
part = TMail::Mail.new
part.content_type = 'application/octet-stream'
part.body = Filter::Base64.encode open('mydata.bin')
tmail << part
...

The idea is that Filter::* classes wrap encoding and decoding in a
streaming way, by just providing #read / #write etc. Then you can send
mails with 50Mb attachments (don't ask without having to read the
whole thing into memory.

Similarly, you should be able to open a mail, ask for a binary
attachment, and get an IO-like object, that is really a
Filter::Base64.decode wrapped substream in the file.

I've got streaming filters that I wrote before for a ruby pdf lib
(base64, hex, ascii85 etc), that do this kind of thing.

Anyway, kind of a long email, but if you're interested I could maybe
come up with some patches to move things in that direction....

Charles

 

[Bira]

Heh.. that's exactly how I got myself into the corner of becoming the
maintainer

I'd like to seize this opportunity to ask a question of my own . I
tried asking it in Tmail-talk, but I probably phrased it the wrong
way...

Let's say I have an e-mail message containing other, forwarded,
messages. I tell TMail to parse this message, and it returns me a
TMail::Mail object.

Is there a way to get the forwarded messages inside as TMail::Mail
objects? From what I could see of the RDoc, the answer seems to be
"no". If that is indeed the case, is this something you would like to
have in TMail? I'm not exactly an expert in RFC822, but I would love
to help implementing it.

 

[Mikel Lindsaar]

open('mymail.eml', 'w') { |f| tmail.write f }
Anyway, kind of a long email, but if you're interested I could maybe
come up with some patches to move things in that direction....

Absolutely interested, come over to TMail-Talk and we'll hash it out more.

You can subscribe here:

http://rubyforge.org/mailman/listinfo/tmail-talk

Regards

Mikel

 

[Mikel Lindsaar]

I'd like to seize this opportunity to ask a question of my own . I
tried asking it in Tmail-talk, but I probably phrased it the wrong
way...

No... I just had my TMail mailing list going into the wrong spot. I
have answered you over on TMail-Talk.

Is there a way to get the forwarded messages inside as TMail::Mail
objects? From what I could see of the RDoc, the answer seems to be
"no". If that is indeed the case, is this something you would like to
have in TMail? I'm not exactly an expert in RFC822, but I would love
to help implementing it.

Sure, would love your help implementing it! And go look at RFC2022...
it updates 822.

Regards

Mikel

 

[Eivind Eklund]

Sure, would love your help implementing it! And go look at RFC2022...
it updates 822.

You mean RFC2822. RFC2022 is about multicast over ATM (a non-TCP/IP
network protocol.)

Also, even 2822 probably won't help you that much, though it is a
valid reference. What you're interested in is MIME wrapping of
forwarded messages and older forwarded messages. The older standard is
RFC934 (standard for encapsulating messages), and the relevant MIME
probably is RFC2045 (obsoletes RFC1521).

Note that no matter what you do, I don't think you'll be able to do
this reliably - forwarded mail messages just don't follow the
standards 100%. So, any implementation is an improvement - you don't
have to hit 100% to make this useful.

Eivind.

 

[Mikel Lindsaar]

You mean RFC2822. RFC2022 is about multicast over ATM (a non-TCP/IP
network protocol.)

Yes, that's exactly what I meant (bad fingers!)

Also, even 2822 probably won't help you that much, though it is a
valid reference. What you're interested in is MIME wrapping of
forwarded messages and older forwarded messages. The older standard is
RFC934 (standard for encapsulating messages), and the relevant MIME
probably is RFC2045 (obsoletes RFC1521).

Thanks for the pointer.

Note that no matter what you do, I don't think you'll be able to do
this reliably - forwarded mail messages just don't follow the
standards 100%. So, any implementation is an improvement - you don't
have to hit 100% to make this useful.

Right, valid point.

I think the key thing will be expanding on the interface we already
have in TMail to access the attachments, there is some access, it is
just not very intuitive and making it easier is what I am after.

Eivind, are you on TMail-Talk? Sounds like it would be good to have
you over there as I am trying to get some email knowledgeable people
(and also just TMail users) in there to help hash out this sort of
thing.

Regards

Mikel