Jared Johnson wrote:
sub parse_mime {
That works, only this should be called "parsed_mime" because you're
asking for the parsed bit, not telling it to parse (every time).
Matt.
> > So if you're interested in the "parsed mime" functionality, your
> > plugin can "plugin_use util/parsed-mime" and the right magic happens.
>
> Oh yeah that's right, someone *did* implement what you're talking about.
> You can do it with 'plugin inheritance' (which ironically i knew nothing
>
>
>
> Jared Johnson wrote:
>>
>> > I think we should probably consider putting support for parsed
>> messages
>> > into core, with the parsing done lazily if requested by the API.
>>
>> I forgot, we did kinda think of a couple of reasons not to want an API.
>> depending on where you put it, you may
Jared Johnson wrote:
>
> > I think we should probably consider putting support for parsed messages
> > into core, with the parsing done lazily if requested by the API.
>
> I forgot, we did kinda think of a couple of reasons not to want an API.
> depending on where you put it, you may find QP i
> I think we should probably consider putting support for parsed messages
> into core, with the parsing done lazily if requested by the API.
I forgot, we did kinda think of a couple of reasons not to want an API.
depending on where you put it, you may find QP in general depending on
MIME::Parser
> I think we should probably consider putting support for parsed messages
> into core, with the parsing done lazily if requested by the API.
It's a good idea, it's only that I haven't yet had the time and
justification to write and to test a move from the plugin model (see the
attached plugin in m
On Sun, 25 Jul 2010, Jared Johnson wrote:
The plugin has the following advantages over the original:
- Uses MIME::Parser to unpack message text so that we can look for URI's
in base64-encoded data, etc., and _not_ look for URI's in noise.
I think we should probably consider putting support fo
>> Attached also is tld_lists.pl, a companion file that needs to be dropped
>> in lib/Qpsmtpd/ which provides the list of first, second, and third
>> level
>> TLDs that we care about. It's derived from our URIBL datafeed as well
>> as
>
> Would they be ok if this was
> released as an independent C
>> And
>> I'm confused by that bit. From what I can tell, the async/uribl plugin
>> ignores plugins/uribl entirely and uses
>> Qpsmtpd::Plugins::Async::DNSBLBase, which in turn uses ParaDNS.
>
> In that case, it's possible (and likely) that it may never have
> worked with async. When time is shor
Jared Johnson wrote:
>
> >> - Introduces support for URIBL services that may not have worked right,
> >> at
> >> least out of the box, before. Defines the subtle differences between
> >> various known URIBL services in order to maximize compatibility.
> >
> > Is it worth pulling some of this co
> On Sun, Jul 25, 2010 at 04:43:36AM -0500, Jared Johnson wrote:
>> The plugin has the following advantages over the original:
>
> Based on a single read-through of the code, I like most of it. Some
> assorted observations, though:
>
> - Parsing out the MIME sections is worthwhile, though it's rea
On Sun, Jul 25, 2010 at 04:43:36AM -0500, Jared Johnson wrote:
> The plugin has the following advantages over the original:
Based on a single read-through of the code, I like most of it. Some
assorted observations, though:
- Parsing out the MIME sections is worthwhile, though it's really somethi
> Do the owners of that data care about it being used this way? You may
> be violating any agreement with them. Would they be ok if this was
> released as an independent CPAN module?Either way, can we
> structure this as an API instead of just an include file?
Forgot to mention, yes, I'd be
>> - Introduces support for URIBL services that may not have worked right,
>> at
>> least out of the box, before. Defines the subtle differences between
>> various known URIBL services in order to maximize compatibility.
>
> Is it worth pulling some of this config out of the code and putting it
>
> - Introduces support for URIBL services that may not have worked right, at
> least out of the box, before. Defines the subtle differences between
> various known URIBL services in order to maximize compatibility.
Is it worth pulling some of this config out of the code and putting it
into some
15 matches
Mail list logo
