Re: Any advice for a searchable web archiver ?

* 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

* 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: the state of art of CPAN

* 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: Email::Address::XS

* 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: Email::Address::XS

* 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

* 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

* 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

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

* 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

* 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

Email::MIME::Kit v3

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

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

* 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

* '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: Derrivative code

* 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: reading webmail inbox from perl

* 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: backwards incompatible asciihood change in Email::Address

* 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: Alternative to Mail::IMAPClient that supports proxyauth?

* 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: do I always need to specify an encoding with Email::MIME?

* 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: how to add a proper attachment to an email message

* 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: I do not understand the error CGI that I get CGI using Email:: Simple

* 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

* 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

* 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: query regarding undocumented feature of Email::Simple

* 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

Re: Sending simple email

* 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: Sending simple email

* 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

Email::MIME::Kit released

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

* 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

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

Net-Server-Mail repo

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

Email::Sender 0.000 released

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

Email::Sender API approaches stability

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: also not dead yet

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

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

* 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: bug in MIME::Entity make_singlepart

* 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

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

* 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

* 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

* 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

* 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

* 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

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

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

* 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!

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

Email::Simple::Creator

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

* 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?

* 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: possible changes for Mail::DeliveryStatus::BounceParser

* 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

* 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

* 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!

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: PEP IRC BBQ

* 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

PEP IRC BBQ

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