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: Patches for Email::* modules

2017-11-27 Thread Ricardo Signes
* [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: the state of art of CPAN

2017-03-06 Thread Ricardo Signes
* Marc Chantreux <> [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: Email::Address::XS

2016-09-28 Thread Ricardo Signes
* [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: Email::Address::XS

2016-08-22 Thread Ricardo Signes
* [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-08-01 Thread Ricardo Signes
* [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-07-03 Thread Ricardo Signes
* [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

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. * [2016-06-01T12:44:01] > On Tuesday 31 May 2016 02:42:48 Ricardo Signes wrote: > > * [2016-05-28T16:48:40] > > > > > Basically yes. F

Re: Email::Address::XS

2016-05-30 Thread Ricardo Signes
* [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-05-28 Thread Ricardo Signes
* [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

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: things need co-maint

2014-08-20 Thread Ricardo Signes
* Erik Logtenberg [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: things need co-maint

2014-08-19 Thread Ricardo Signes
* Geoffrey Leach [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-07-30 Thread Ricardo Signes
* 'lesleyb' [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: Derrivative code

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

Re: reading webmail inbox from perl

2014-01-28 Thread Ricardo Signes
* Devireddy, Nagendra [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: backwards incompatible asciihood change in Email::Address

2012-01-15 Thread Ricardo Signes
* Ruslan Zakirov [2012-01-15T10:24:59] On Sun, Jan 15, 2012 at 19:09, Ricardo Signes 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: Alternative to Mail::IMAPClient that supports proxyauth?

2011-06-30 Thread Ricardo Signes
* Jesse Thompson [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: do I always need to specify an encoding with Email::MIME?

2011-05-05 Thread Ricardo Signes
* James Peregrino [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: how to add a proper attachment to an email message

2010-05-13 Thread Ricardo Signes
* fakessh [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: I do not understand the error CGI that I get CGI using Email:: Simple

2010-05-04 Thread Ricardo Signes
* fakessh [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 [2010-05-04T08:20:14] [Tue May 04 14:15:11 2010] [error] [client] Can't use string ( as a HASH ref while strict refs in use at /usr/lib/perl5/vendor_perl/5.8.8/Email/ 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 [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: query regarding undocumented feature of Email::Simple

2009-06-30 Thread Ricardo SIGNES
* Saurabh Hirani [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

Re: Sending simple email

2009-06-08 Thread Ricardo SIGNES
* Roderick A. Anderson [2009-06-06T17:50:13] Ricardo SIGNES wrote: * Bill Moseley [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: Sending simple email

2009-06-07 Thread Ricardo SIGNES
* Bill Moseley [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

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: Net-Server-Mail repo

2009-01-15 Thread Ricardo SIGNES
* Xavier [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
* [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:

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. 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

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. -- rjbs

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: Right now, normal usage is something like this: my $sender = Email::Sender::Transport::Sendmail-new;

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::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

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

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

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: 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: 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: 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-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

(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,

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::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'

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


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).

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::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

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: 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: 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: 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...

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


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


2006-07-06 Thread Ricardo SIGNES
From now on, I will be findable in #email on 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