PEP IRC BBQ

2006-07-06 Thread Ricardo SIGNES
From now on, I will be findable in #email on irc.perl.org. I might not be at my console, but I'll be in the channel. Show up if you're afraid of sending email. (If you're afraid of sending email... maybe PEP can help!) -- rjbs signature.asc Description: Digital signature

Re: PEP IRC BBQ

2006-07-07 Thread Ricardo SIGNES
* Karen J. Cravens [EMAIL PROTECTED] [2006-07-06T14:52:23] I deleted the message where you mentioned it, but... is Email::LocalDelivery really still a going concern? Shouldn't it be (or isn't it already) rolled into Email::Send? Or am I completely misremembering (I stopped using Email::LD

a barrage of releases!

2006-07-11 Thread Ricardo SIGNES
Today, I released new versions of: Email-Address Email-Folder-IMAP Email-Folder-IMAPS Email-LocalDelivery Email-MessageID Email-Simple Email-Simple-Creator Email-Simple-Headers Over the rest of the week, I'll probably release more Email:: bugfixes. Once RT decides that I'm cool

Re: wiki pagecount eexplosion

2006-07-13 Thread Ricardo SIGNES
* Dave O'Neill [EMAIL PROTECTED] [2006-07-12T22:02:31] Sheer volume aside, it's probably still a good idea. I don't think there's a single-page comprehensive listing of email-related modules anywhere else. I know there are other modules that fit in. There's the SMS and MMS series...

Re: possible changes for Mail::DeliveryStatus::BounceParser

2006-08-03 Thread Ricardo SIGNES
* William Yardley [EMAIL PROTECTED] [2006-08-03T18:09:01] I've also been working at building some tests for some of the problems we've seen, and building a bigger corpus of emails to use for testing. I am really looking forward to having a nice body of messages selected for use as proof that

Re: possible changes for Mail::DeliveryStatus::BounceParser

2006-08-04 Thread Ricardo SIGNES
* William Yardley [EMAIL PROTECTED] [2006-08-03T23:25:31] Excellent; I would much rather trust the data that's supposed to tell us something than the data whose entrails we have ripped out read. Yeah. The only problem is what to do when there is some sort of conflict between the two bits

Re: Mail::DeliveryStatus::BounceParser - qmail support?

2006-09-26 Thread Ricardo SIGNES
* Ricardo SIGNES [EMAIL PROTECTED] [2006-09-26T07:37:13] * William Yardley [EMAIL PROTECTED] [2006-09-26T01:09:20] Oh crap! Doesn't look like *any* of the new or updated tests from SVN are in the tarball in CPAN. Paging rjbs to the red courtesy phone Fixed in 1.516. I'll release

MBP: orig or final recipient?

2006-10-06 Thread Ricardo SIGNES
This code appears in MBP's parse method: 374next unless my $email = $report-get(original-recipient) 375 || $report-get(final-recipient); In other words, if we get some DSNs, and they give an Original-Recipient, use it as the email that bounced. Otherwise, use

Email::Simple header developments

2006-10-06 Thread Ricardo SIGNES
Email::Simple 1.992 fixes a bug introduced in 1.96, in which headers could not always be added with more than one value. This bug was introduced when we made header ordering reliable. The previous code only ensured that each header had one entry for ordering, as it output all headers of a given

Re: Email::Simple changes?

2007-02-15 Thread Ricardo SIGNES
* Ricardo SIGNES [EMAIL PROTECTED] [2007-02-14T16:57:49] Oh well! Please update to 0.211. Update to 0.213. 0.211 and 0.212 could have problems when delivering the same message to multiple destinations, which was not properly covered by the test suite. -- rjbs

Re: Email::Simple changes?

2007-02-15 Thread Ricardo SIGNES
* Karen J. Cravens [EMAIL PROTECTED] [2007-02-14T17:50:27] Yeah, errm, I've actually got some code that uses the internals directly myself, that I'm gonna hafta change before it gets into production. In fact, I think I *use* _split_head_from_body, now I think about it. I'll have to look

Re: Email::Send Redux

2007-02-21 Thread Ricardo SIGNES
* Dave O'Neill [EMAIL PROTECTED] [2007-02-21T00:07:06] On Tue, Feb 20, 2007 at 07:07:43PM -0500, Ricardo SIGNES wrote: Email::Sender has one main class, the sender. Email::Sender's send method accepts a message and arguments, canonicalizes the arguments, and tries to deliver the message

Re: Email::Send Redux

2007-02-21 Thread Ricardo SIGNES
* Hans Dieter Pearcey [EMAIL PROTECTED] [2007-02-21T10:26:12] On Wed, Feb 21, 2007 at 10:08:50AM -0500, Ricardo SIGNES wrote: I'm not sure. I also don't like Email::Mailer, for the same reason. Email::Delivery::Agent would be okay, but is pretty long. Then again, if most people use

Email::Simple::Creator, false headers

2007-02-23 Thread Ricardo SIGNES
I thought I'd have a quick run through Email::Simple::Creator to clean up some of its foibles. Here is another one that makes me wonder... False Headers Remember _add_to_header? sub _add_to_header { my ($class, $header, $key, $value) = @_; return unless $value;

Email::Simple::Creator

2007-02-23 Thread Ricardo SIGNES
I thought I'd have a quick run through Email::Simple::Creator to clean up some of its foibles. Here are the ones that make me wonder... The changelog says: 1.3 2004-07-05 Create a message using its local crlf (Casey West). Include timezone info in the Date header (Steffen Goeldner).

Email-ARF (abuse reporting format)

2007-03-20 Thread Ricardo SIGNES
AOL lets you say, Look, I want to be a nice guy. If you get complaints about mail from me, please let me know and I'll look into it. They send these report in a format called ARF. http://www.mipassoc.org/arf/ Well, actually, they use two formats, but one is old and lame and is being

Re: Email-ARF (abuse reporting format)

2007-03-21 Thread Ricardo SIGNES
* Ricardo SIGNES [EMAIL PROTECTED] [2007-03-20T22:39:49] There exists an ARF-producing Perl module, MIME::ARF, but it's not on the CPAN and only produces reports. Today I wrote an ARF-reading module, Email::ARF::Report, and uploaded it. It's a prototype, and if you deal with ARF, please let

Re: Email::Base (ad Email::Sender)

2007-07-18 Thread Ricardo SIGNES
* Smith Warren - wasmit [EMAIL PROTECTED] [2007-07-18T16:09:21] Just remember, if you ever want your module to become part of the perl core distribution, it must rely solely upon other core modules. I don't. Email modules do not belong in the core, imho. Secondly for those of us who have

Email::Abstract: big updates; test please!

2007-07-18 Thread Ricardo SIGNES
So, I spent a few hours today writing more comprehensive tests for Email::Abstract. It started when Mark Overmeer noted that he thought there was a bug in the way Mail::Message objects' newlines were handled. I had a look at the tests for Email::Abstract and basically found that there were a

Re: Email::Base 0.000

2007-07-24 Thread Ricardo SIGNES
* Hans Dieter Pearcey [EMAIL PROTECTED] [2007-07-24T22:00:15] On Tue, Jul 24, 2007 at 07:46:36AM -0400, Dave O'Neill wrote: Using '::Bar::Baz' is probably a better choice. Most Perl people know what a :: prefix means for namespacing, but only Catalyst people will find '+Bar::Baz'

MIME-Lite in pep svn

2007-07-29 Thread Ricardo SIGNES
As those of you on pep-checkins saw (sorry for the huge noise), MIME-Lite is now in the PEP subversion repository. I've made a new dev release with zero code changes. I'm not a fan of MIME-Lite, as it's fairly buggy and not all that lite. I'm not really interested in making it the best MIME

Re: Email::Store is dead! Long live Email::Store!

2007-09-19 Thread Ricardo SIGNES
* Karen Cravens [EMAIL PROTECTED] [2007-09-19T11:53:13] sinus yuck and can focus on finishing the install, we can move over there. (Guess I could just turn on the daemon and hope for the best...) Of course, once I get off the Sudafed+Dew I probably won't be so inclined toward lengthy rants.

the big todo list, posted

2007-09-24 Thread Ricardo SIGNES
http://emailproject.perl.org/wiki/Big_Todo_List I've dumped my previous mail on this topic to the wiki, in response to the occasional, What can I do? mails and privmsgs. So far, these haven't led to much, but... well, a fellow can hope. -- rjbs

new Email::Abstract!

2007-11-16 Thread Ricardo SIGNES
At long last (and about 3 months past due, says my OmniFocus) I have released a new stable release of Email::Abstract. This release should be significantly saner, with better facilities for a plugin to declare when it will work and when it should be ignored. Email::Abstract is likely to be the

(non-)progress on Email::Base and Email::Sender

2007-12-30 Thread Ricardo SIGNES
I'm tired of trying to fix hard-to-fix issues in Email::Send, and tired of saying, Yeah yeah, Email::Sender someday soon blah blah. So, I'm doing a bit more work on it. Here are my current thoughts: Email::Base is good enough for now. All it does is provide -throw, which is enough. Someday,

Re: Email::Classifier

2008-02-18 Thread Ricardo SIGNES
* Jonas Liljegren [EMAIL PROTECTED] [2008-02-17T19:50:52] The MD::BounceParser seemed to bee a bit disorganized and had seems to have the assumption that you only would want to use it for finding out email-addresses to remove from send-lists. That is definitely the reason it was made. It was

Re: Email::Classifier

2008-02-22 Thread Ricardo SIGNES
* Ricardo SIGNES [EMAIL PROTECTED] [2008-02-21T23:38:18] I think my main concern relates to the way that one would use Classifier, and what it would return. I imagine this as a very basic use case: my $classifier = Email::Classifier-new({ classifiers = [ ... ], ... }; Rather

Re: Email::Classifier

2008-02-25 Thread Ricardo SIGNES
* Jonas Liljegren [EMAIL PROTECTED] [2008-02-25T05:04:56] I still want to have methods dependent on the type of classifier. The orig_message_id may have to scan the message, searching for the id. But it should not have to do so if the message_id isn't going to be used. Other examples are

Re: Email::Classifier

2008-02-25 Thread Ricardo SIGNES
* Jonas Liljegren [EMAIL PROTECTED] [2008-02-25T08:25:54] I want to get it on demand. Not extracting all possible information just in case it may bee needed. It could be hundreds of different things. Ok. So I could let $msg_id be a object that computes itself on stringification. My first

Re: validating email addresses

2008-04-17 Thread Ricardo SIGNES
* Dave Howorth [EMAIL PROTECTED] [2008-04-17T05:42:59] I use Email::Valid to check the syntax and MX record. I'm wondering if there is any best practice for the next steps: - verify the existence of the mailbox Don't. Email verification probing is basically abuse, in my opinion. The

Re: Announcement Test::SMTP module released

2008-04-28 Thread Ricardo SIGNES
* Jose Luis Martinez [EMAIL PROTECTED] [2008-04-28T14:24:40] I released a week ago Test::SMTP. This module is a helper for writing tests for SMTP servers. I basically announced it on the qpsmtpd list, but I've just found this list, so I'm reannouncing: Thanks for the note. I saw it in

Re: Problem with attachment, 1 becomes 10

2008-05-04 Thread Ricardo SIGNES
* Mikael Bonnier [EMAIL PROTECTED] [2008-05-04T20:49:51] I'm trying to write a program that can send out mails to companies where I'm interested in working. These mails are the same except that the company name is switched. My CV should be attached as a pdf-file. Let me rephrase your

bug in MIME::Entity make_singlepart

2008-06-26 Thread Ricardo SIGNES
I thought I'd cc the list since this is sort of a weird, fun bug. Sometimes, when collapsing a message into single part, the C-T is horked up. It starts as: Content-Type: multipart/related; boundary=xyzzy; type=foo ...and ends as: Content-Type: text/plain; boundary=xyzzy; type=foo Erk!

Re: bug in MIME::Entity make_singlepart

2008-06-26 Thread Ricardo SIGNES
* Ricardo SIGNES [EMAIL PROTECTED] [2008-06-26T13:37:09] Demonstration attached. Thanks, ezmlm. Here it is: use strict; use MIME::Parser; # my $entity = MIME::Parser-new-parse_open('bizarre.msg'); my $entity = MIME::Parser-new-parse(\*DATA); sub cleanup_mime { my ($entity) = @_; foreach

Re: I hate Unicode

2008-06-26 Thread Ricardo SIGNES
* Karen Cravens [EMAIL PROTECTED] [2008-06-26T15:38:17] (Dangitall, if 7-bit ASCII was good enough for Fidonet, it ought to be good enough for email. Kids these days.) I'm getting this when I try to retrieve $SomeEmailMimeMessage-header('subject'): Unknown encoding X-UNKNOWN at

Re: bug in MIME::Entity make_singlepart

2008-06-27 Thread Ricardo SIGNES
* Dave O'Neill [EMAIL PROTECTED] [2008-06-27T10:30:10] On Thu, Jun 26, 2008 at 01:37:09PM -0400, Ricardo SIGNES wrote: Content-Type: multipart/related; boundary=xyzzy; type=foo Content-Type: text/plain; boundary=xyzzy; type=foo The docs for make_singlepart say Also crunches 0-part

Re: Strange Behavior in Email::Valid for email addresses w/newlines

2008-10-08 Thread Ricardo SIGNES
* Justin Simoni [EMAIL PROTECTED] [2008-10-08T05:06:11] I'm having an interesting case, where email addresses with newlines are seen as valid, but carriage returns and/or carriage returns, with a newline aren't seen as valid: Interesting... That regex in Email::Valid is scary, That's

Re: porting to github

2008-11-14 Thread Ricardo SIGNES
* Ricardo SIGNES [EMAIL PROTECTED] [2008-11-13T21:42:39] I will begin moving PEP SVN to github shortly. I will not move the few things that I did not put there myself, and will contact those authors if I can. Email-Applications Email-Base Email-Corpus Email-Filter-SpamAssassin Email

Email::Classifier: not dead yet

2008-12-01 Thread Ricardo SIGNES
I need to stop sitting on good ideas! Way back in February, someone posted saying, how about that email classifier we want to replace the awful awful BounceParser? I replied with some of my own ideas, including an implementation. Then I did nothing.

Re: Email::Classifier: not dead yet

2008-12-01 Thread Ricardo SIGNES
* Simon Wistow [EMAIL PROTECTED] [2008-12-01T20:45:53] On Mon, Dec 01, 2008 at 07:15:20PM -0500, Ricardo SIGNES said: I may sit on it for another week or so, but unless I get some feedback on the order of no, stop, this is crazy! I am going to release it and start using it for things. Your

Email::Sender: also not dead yet

2008-12-05 Thread Ricardo SIGNES
The first thing that got me involved in PEP was Email::Send, which was largely unusable for serious email-related work becase it offered no mechanism for specifying an envelope sender or recipient. It had a bunch of other problems, some of which, we felt made fixing Email::Send in a

Email::Sender API approaches stability

2008-12-08 Thread Ricardo SIGNES
I don't doubt that I'll hit a few glitches on the way to finality, but Email::Sender's API is getting pretty close to usable. Check it out and have a go: http://github.com/rjbs/email-sender Right now, normal usage is something like this: my $sender = Email::Sender::Transport::Sendmail-new;

Email::Sender 0.000 released

2008-12-10 Thread Ricardo SIGNES
I still consider it fair game for big changes. I will be breaking it into a few dists soon. http://rjbs.manxome.org/rubric/entry/1706 -- rjbs

Net-Server-Mail repo

2009-01-14 Thread Ricardo SIGNES
Xavier, I feel like I already talked to you about this, but I can't find any record of it, so I'm guessing that I'm wrong. emailproject.perl.org/svn has been moved (mostly) to github. One of the few things I have not dealt with is Net-Server-Mail, because I am not one of its maintainers. I see

Re: Net-Server-Mail repo

2009-01-15 Thread Ricardo SIGNES
* Xavier x.guim...@free.fr [2009-01-15T01:26:31] I have no other repository. I made a few changes on Net::Server::Mail since it work for me (more than 1 million message a day) and I have no demand to modify something. I've taken Net::Server::Mail in maintenance few years ago because there

Re: Net-Server-Mail repo

2009-01-15 Thread Ricardo SIGNES
* xavier.guim...@laposte.net [2009-01-15T12:31:40] no problem for me, you can use GIT and delete svn files. Excellent. Earlier today I wrote a backpan-to-git importer. I imported all previous releases of Net-Server-Mail to git, then the unreleased changes, then a few minor fixes:

Email::MIME::Kit released

2009-01-25 Thread Ricardo SIGNES
After a long time and a bunch of rewriting, Email::MIME::Kit has been released. Here's what I posted in my journal about it: Building email messages is a pain. Even if you use a library to build the message string for you, you have to know a lot of crap and pay attention to a lot of details.

Re: Email::MIME issues

2009-02-16 Thread Ricardo SIGNES
* Lyle webmas...@cosmicperl.com [2009-02-16T10:27:01] I guess the question really is, should Email::MIME take the single parts headers, when only one part is added to the containing Email::MIME object? Or should the single parts headers be lost, and the containing Email::MIME objects

Re: Sending simple email

2009-06-06 Thread Ricardo SIGNES
* Bill Moseley mose...@hank.org [2009-06-06T11:34:29] I see the recommendation to use Email::Sender, but are there docs available? You have sent this message at an excellent time! Email::Sender::Simple is potentially done, and I've written a quickstart guide, just last night.

Re: Sending simple email

2009-06-07 Thread Ricardo SIGNES
* Bill Moseley mose...@hank.org [2009-06-07T19:07:34] On Sat, Jun 06, 2009 at 12:01:40PM -0400, Ricardo SIGNES wrote: You have sent this message at an excellent time! Email::Sender::Simple is potentially done, and I've written a quickstart guide, just last night. http

Re: Sending simple email

2009-06-08 Thread Ricardo SIGNES
* Roderick A. Anderson raand...@cyber-office.net [2009-06-06T17:50:13] Ricardo SIGNES wrote: * Bill Moseley mose...@hank.org [2009-06-06T11:34:29] I see the recommendation to use Email::Sender, but are there docs available? You have sent this message at an excellent time! Email::Sender

Re: query regarding undocumented feature of Email::Simple

2009-06-30 Thread Ricardo SIGNES
* Saurabh Hirani saurabh.hir...@gmail.com [2009-06-30T02:07:41] So I looked at the source and deduced that if I have $email-header_set($headername) i.e I don't give the value to set, as per the internal working of the code, it actually deletes the header - which is what I want. Is this an

Email::Sender SMTP message

2009-10-13 Thread Ricardo Signes
My master branch of Email-Sender currently adds a HasMessage role which gets applied to Success classes by the SMTP transports so that success can include the SMTP response after the . This will allow a Postfix transport where success will have a -queueid accessor. Anybody have thoughts on the

ditching the wiki

2009-12-04 Thread Ricardo Signes
The wiki isn't used. Unless someone objects strongly, I am going to get rid of it and replace it with a few static pages. -- rjbs

Re: I do not understand the error CGI that I get CGI using Email:: Simple

2010-05-04 Thread Ricardo Signes
* fakessh fake...@fakessh.eu [2010-05-03T20:55:20] click error when I am not MIME:: Lite I find myself with a CGI error in httpd and browser. I do not understand why What's the error? package PerlWebmail::Message; use base qw(MIME::Lite); use base qw(Email::Simple); Extending

Re: I do not understand the error CGI that I get CGI using Email:: Simple

2010-05-04 Thread Ricardo Signes
* fakessh fake...@fakessh.eu [2010-05-04T08:20:14] [Tue May 04 14:15:11 2010] [error] [client 90.30.250.62] Can't use string (fake...@fakessh.eu) as a HASH ref while strict refs in use at /usr/lib/perl5/vendor_perl/5.8.8/Email/Simple.pm line 100., referer: This is a warning, not an error.

Re: Email::Folder stuck at first message

2010-05-04 Thread Ricardo Signes
* Eddie Rowe webmas...@tarheeloesrescue.org [2010-04-14T11:41:45] I have tried to process messages from a Mozilla Thunderbid INBOX file. Sorry it took me a month to reply. [code] use Email::Folder; my $folder = Email::Folder-new(c:/users/eddie/desktop/INBOX.txt); while( my $message =

Re: how to add a proper attachment to an email message

2010-05-13 Thread Ricardo Signes
* fakessh fake...@fakessh.eu [2010-05-13T16:05:31] my question is simple how to add a proper attachment to an email message I use as main modules use Email::Send and use Email::Simple::Creator You need to use Email::MIME. -- rjbs

Re: Fwd: Re: Email::MIME walk_parts doesn't walk all my parts

2010-09-06 Thread Ricardo Signes
* Erik Logtenberg e...@logtenberg.eu [2010-08-29T17:26:38] Since this change, inspired by Ricardo Signes, fixes an obvious bug in Email::MIME, I'd like to request this patch be pushed into git. Also a new release of Email::MIME containing this fix would be nice. Released in 1.905, thanks

Re: do I always need to specify an encoding with Email::MIME?

2011-05-05 Thread Ricardo Signes
* James Peregrino james_peregr...@harvard.edu [2011-05-02T12:53:46] I'm trying to use Email::MIME to send a simple email with a .doc file as an attachment. I receive it fine with Gmail, but my job email chokes on it when it tries to scan the attachment for viruses ('UNSCANABLE'). send

Re: Alternative to Mail::IMAPClient that supports proxyauth?

2011-06-30 Thread Ricardo Signes
* Jesse Thompson jesse.thomp...@doit.wisc.edu [2011-06-23T15:09:24] Does anyone know if there is an alternative to Mail::IMAPClient that supports proxyauth. I don't know of any IMAP client worth using much beyond Mail::IMAPClient, which I use -- and with which proxy auth works. -- rjbs

Re: ARF MIME reports best perl options

2011-11-10 Thread Ricardo Signes
* Steve Atkins st...@blighty.com [2011-11-10T20:25:26] I need to be sending out ARF (i.e., RFC 5965) reports on a production systems, possibly 100-1,000 ARFS/second, using perl. That's pretty high volume. Yes. I'm not sure how Email::ARF will do, but am interested to find out...

Re: ARF MIME reports best perl options

2011-11-18 Thread Ricardo Signes
* Joseph Crotty josephcro...@gmail.com [2011-11-10T23:31:39] All, an initial patch to get the ball rolling. Untested, but hope helps. Some sections have comments with no action taken as unsure the correct course of action. This patch doesn't even result in compiling code. I'll have a look at

Re: backwards incompatible asciihood change in Email::Address

2012-01-15 Thread Ricardo Signes
* Ruslan Zakirov r...@bestpractical.com [2012-01-15T08:22:23] May be it's proper from RFC point of view, but it breaks Request Tracker application and it's going to cost a lot of development to get it fixed. I've updated Github's repo with a change to only reject non-ASCII in the email

Re: backwards incompatible asciihood change in Email::Address

2012-01-15 Thread Ricardo Signes
* Ruslan Zakirov r...@bestpractical.com [2012-01-15T10:24:59] On Sun, Jan 15, 2012 at 19:09, Ricardo Signes perl@rjbs.manxome.org wrote: I've updated Github's repo with a change to only reject non-ASCII in the email address, which really is a problem.  My guess is that you were having

Re: Email::Address hangs

2012-01-29 Thread Ricardo Signes
* Joseph Crotty josephcro...@gmail.com [2012-01-28T18:20:28] When calling parse on a large To: header field it hangs. Large in this case is 600 emails some with comments. I put in a length check on the To: field to avoid this. Are there any other ways to parse long To:field fields

Re: reading webmail inbox from perl

2014-01-28 Thread Ricardo Signes
* Devireddy, Nagendra ndevire...@ariba.com [2014-01-28T06:30:04] Our mail server address is something like this devmail.fqdn.com and I am trying to read inbox messages from that one by one. With what protocol? -- rjbs signature.asc Description: Digital signature

Re: reading webmail inbox from perl

2014-01-28 Thread Ricardo Signes
* Devireddy, Nagendra ndevire...@ariba.com [2014-01-28T08:40:18] Imap I suggest using Mail::IMAPClient. It's easy to use and fairly well documented. -- rjbs signature.asc Description: Digital signature

Re: Derrivative code

2014-07-06 Thread Ricardo Signes
* Geoffrey Leach ge...@hughes.net [2014-07-05T18:30:19] I'm at work on MH.pm, which I hope to submit to CPAN as Email::LocalDelivery:MH.pm. The code is based on Email::LocalDelivery::Maildir.pm Question, in such a case is there a preference for maintaining the format, naming conventions,

Re: things need co-maint

2014-07-30 Thread Ricardo Signes
* 'lesleyb' lesl...@herlug.org.uk [2014-07-30T06:58:14] On Tue, Jul 29, 2014 at 07:03:39AM -0400, Ricardo Signes wrote: There are a lot of email modules that I don't use and am not being very vigilant about maintaining. In some cases, I can chown them to HANDOFF on PAUSE and in other cases

Re: things need co-maint

2014-08-19 Thread Ricardo Signes
* Geoffrey Leach ge...@hughes.net [2014-08-19T19:54:44] Does this imply the passing of the Perl Email Project? Perhaps you ncould elaborate. The PEP, as far as I am concerned, is a non-thing. It is a name describing nothing that exists. In about five years, the only thing that has happened

Re: things need co-maint

2014-08-20 Thread Ricardo Signes
* Erik Logtenberg e...@logtenberg.eu [2014-08-20T06:03:14] Of this list of modules I use, Email-Send and MIME-Lite are on your list of modules that need a new (co)maintainer. I urge you to consider using Email::Sender in place of Email::Send. It is a significant upgrade to testability and

Re: The PDF attachments sent with Email::MIME::Kit are damaged

2014-11-02 Thread Ricardo Signes
* Octavian Rasnita orasn...@gmail.com [2014-11-02T08:05:54] Please apply the following diff to Email::MIME::Kit::KitReader::Dir. Okay! I've released a new version with this patch. Enjoy! -- rjbs signature.asc Description: Digital signature

Email::MIME::Kit v3

2014-11-20 Thread Ricardo Signes
Ever since its early releases, Email::MIME::Kit had a big problem. It screwed up encodings. Specifically, imagine his manifest (I'm kinda skipping some required junk): # manifest.yaml renderer: TemplateToolkit headers: - Subject: Message for [% name %] alternatives: - type:

Re: Email::Address::XS

2016-05-28 Thread Ricardo Signes
* p...@cpan.org [2016-05-23T13:05:39] > I created new perl module Email::Address::XS for parsing and formatting > email groups or addresses. Parser is borrowed from dovecot and that part > implemented in C/XS. Cool! > Thanks to named group support I would like to extend Email::MIME module > to

Re: Email::Address::XS

2016-05-30 Thread Ricardo Signes
* p...@cpan.org [2016-05-28T16:48:40] > Basically yes. From caller perspective I want to pass email address > object and let Email::MIME to do MIME encoding correctly. Something like > this: > > my $email = Email::MIME->create( > header_addr => [ ... ], > ); I think that requiring people

Re: Email::Address::XS

2016-08-01 Thread Ricardo Signes
* p...@cpan.org [2016-07-12T11:43:02] > On Monday 04 July 2016 01:52:41 Ricardo Signes wrote: > > > > I'd stick to header_str, I think, but I'm not sure. At any rate: > > yes. > > And this is what I do not like... to pass objects to function with name > hea

Re: Email::Address::XS

2016-06-30 Thread Ricardo Signes
My coworkers have returned to the other side of the world! I attended YAPC! i had a vacation! I am back. * p...@cpan.org [2016-06-01T12:44:01] > On Tuesday 31 May 2016 02:42:48 Ricardo Signes wrote: > > * p...@cpan.org [2016-05-28T16:48:40] > > > > > Basically yes. F

Re: Email::Address::XS

2016-07-03 Thread Ricardo Signes
* p...@cpan.org [2016-07-03T08:39:22] > On Friday 01 July 2016 02:51:31 Ricardo Signes wrote: > > > What if we defined a role (here, just a well-known name) called > > Email::MIME::Header::Value, which is used to signal that a particular > > method, say "as

Re: Email::Address::XS

2017-01-28 Thread Ricardo Signes
* p...@cpan.org [2017-01-14T15:32:57] > So lets move. This is implemented in my pull request: > https://github.com/rjbs/Email-MIME/pull/35 Done! -- rjbs signature.asc Description: Digital signature

Re: Email::Address::XS

2016-08-18 Thread Ricardo Signes
* p...@cpan.org [2016-08-08T17:41:04] > Here we are need to deal with objects which internally needs to be MIME > encoded and objects which mustn't. I don't think this matters. If an object is passed in, it must be able to produce a MIME encoded form. Even if you say: header_str => [ header

Re: Email::Address::XS

2016-09-11 Thread Ricardo Signes
* p...@cpan.org [2016-09-05T04:25:11] > I do not want to add ->as_mime_header (or other function) which will do > MIME encoding/decoding into Email::Address::XS. That module is for > formating and parsing email addresses headers, not for MIME > encoding/decoding. Same as it is for Email::Address

Re: Email::Address::XS

2016-09-18 Thread Ricardo Signes
* p...@cpan.org [2016-09-17T19:05:51] > $class->from_mime_string() will take raw MIME encoded string and returns > new object of $class (which will have decoded string parts) > $object->as_mime_string() will convert (Unicode) $object into raw MIME > encoded string > > It is OK for you? That

Re: Email::Address::XS

2016-08-22 Thread Ricardo Signes
* p...@cpan.org [2016-08-20T06:01:16] > Email::MIME is module which automatically do any MIME encoding/decoding > without user interaction, so that decoding must be done automatically > and without such "upgrade" function. So do you mean that whenever someone reads the header with a specific

Re: Email::Address::XS

2016-09-28 Thread Ricardo Signes
* p...@cpan.org [2016-09-18T11:40:53] > Currently passing string values of From/To/Cc/Bcc/... headers into > header_str() method is broken in Email::MIME. That is because > Email::MIME currently uses Email::Address for generating those header > values (which is broken) and then MIME encode

Re: the state of art of CPAN

2017-03-06 Thread Ricardo Signes
* Marc Chantreux <m...@unistra.fr> [2017-03-06T03:32:48] > On Sat, Mar 04, 2017 at 07:28:19PM -0500, Ricardo Signes wrote: > > Cool, good luck! > > people are really enthousiatic and i really would like to start thinking > about a "PSGI for SMTP". What do you

Re: the state of art of CPAN

2017-03-04 Thread Ricardo Signes
* Marc Chantreux [2017-02-21T09:53:45] > hello people, Hi, Marc! Sorry for the delayed reply. I'm afraid I'm often a bit behind on these things, but I am here and alive and interested! > About sympa, we want to remove a lot of homebrew code by replacing them > with existing

Re: Patches for Email::* modules

2017-11-27 Thread Ricardo Signes
* p...@cpan.org [2017-11-24T08:08:28] > There is a big silence so I do not know if Email::* modules are going to be > unmaintained or if there is planned some activity. Thanks! I do plan to work through these. The situation roughly like this: * I am very busy * Insufficiently-reviewed changes

Re: Any advice for a searchable web archiver ?

2017-11-27 Thread Ricardo Signes
* Marc Chantreux [2017-11-20T14:42:24] > > We're using Xapian as part of Cyrus IMAP, and it's quite useful for > > what we're doing, > > do you think this should be enough to store mailing lists archives? Based on personal experience, yes. -- rjbs signature.asc

Re: Are Email::* modules unmaintained?

2018-06-25 Thread Ricardo Signes
* p...@cpan.org [2018-06-25T05:08:32] > So what is status of Email::* modules? Does silence now mean that > modules are abandoned / unmaintained? I guess so. You are mistaken. The answer is the same as every other time you have asked: I am here, I am alive, I am interested, and I am extremely