Re: Rewritten URIBL plugin
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 about until looking at the async uribl plugin the other night): You do know who that someone was, right? ;) snip Voila! A lazy 'plugin model' that is *also* and API, which doesn't 'use MIME::Parser' until you *want* to use it; furthermore, you don't have to just put the official mime_parser plugin in there, with a little modification (or alternatively some care to use the same filename within an alternate directory) you could use your home-rolled messier-but-more-efficient version that doesn't use MIME::Parser at all. Nice. That does work out to be a nice bit of code reuse. The syntactic sugar is.. well.. lacking, but that's ok. It's understandable! I could easily modify my own stuff to do this and test it. I'd even be interested in pulling a couple of our own home-grown MIME recursion methods into it. If this is indeed the will of the council ;) I like it. But I'm just one person. p.s. I'm kind of stoke about plugin inheritance these days. I'm becoming convinced that after some code churn on our side it will allow us to finally switch to async without having to do just rewrite all our plugins, switch to the async daemon, and see what happens. And with a little churn on the upstream side, if that manages to happen, I also think it could allow us to un-fork 90% of the QP plugin code we currently have re-written and instead submit patches to QP that have some guarantee to be tested and aren't surrounded by completely useless context :) Nice. -R
Re: Rewritten URIBL plugin
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.
Re: per-recipient configuration
I have stuff that might wind up looking like
$rcpt-persistent-{statistics_receivedmsgs_total}++;
$rcpt-persistent-{statistics_receivedstatsbysender}{$NormalizedSenderAddress}++;
Perhaps $rcpt-storage could be provided that could be tied... it just
seems like this is the less conventional accessor in qp-land.
notes('foo') can be accessed with -{_notes}-{foo}, but this is not the
general convention. When I want to increment a note i just do
$foo-notes( blah = $foo-notes('blah') + 1 ). That said, some of my
colleagues have also complained that notes() even exists as a method and
think it would be fine for it to just be a reserved namespace accessed
directly as a hash key.
in addition to reading configuration.
Nothing's exactly stopping you from reading configuration directly with a
persistence hook, it just doesn't seem that natural to me, and I think the
needs of a hook_user_config are a subset of the needs of a persistence
hook. I wouldn't really cry if I had to change every $rcpt-config() call
in my codebase to $rcpt-get() or $rcpt-storage() etc, it just seems less
intuitive and less in line with the existing convention of $qp-config()
-Jared
Re: per-recipient configuration
colleagues have also complained that notes() even exists as a method and
think it would be fine for it to just be a reserved namespace accessed
directly as a hash key.
or at least that notes() should return the {_notes} hashref if it doesn't
have any callers
-Jared
Re: per-recipient configuration
On Thu, Jul 29, 2010 at 11:48 AM, Jared Johnson jjohn...@efolder.net wrote: Nothing's exactly stopping you from Another thing that nothing stops us from, in a late-bound programming language without private namespaces, is adding additional methods to base objects without changing the code that declares the base objects, as long as the implementation of the base objects promises to remain the same.
Re: per-recipient configuration
Another thing that nothing stops us from, in a late-bound programming language without private namespaces, is adding additional methods to base objects without changing the code that declares the base objects, as long as the implementation of the base objects promises to remain the same. I do think it would be best though to come to decisions upstream to provide methods that most people will find sufficient and intuitive, because once they find it insufficient or unintuitive and add their own methods, they'll start using them in their code and the code becomes that much more forked. I find the $qp-config() style method intuitive for this myself; adding a hashref accessor to at least the notes() method and perhaps to this persistence-method-that-might-also-want-to-cover-config-needs, might be considered intuitive by many. -Jared
URIBL plugin 'action' defaults
Would anyone object to setting the default action to 'deny' on certain reliable low-fp URIBL lists? Probably Spamhaus SBL-XBL and DBL and URIBL Black. It seems like a new user turning on uribl checks would expect them to do something more than adding headers, as long as the services it rejects for are reliable. But this also means that anyone who was already using the plugin without setting any actions would see a change in behavior on upgrade. -Jared
Re: URIBL plugin 'action' defaults
How about instead of hardcoding this, make deny be the default in the sample config? -R Jared Johnson wrote: Would anyone object to setting the default action to 'deny' on certain reliable low-fp URIBL lists? Probably Spamhaus SBL-XBL and DBL and URIBL Black. It seems like a new user turning on uribl checks would expect them to do something more than adding headers, as long as the services it rejects for are reliable. But this also means that anyone who was already using the plugin without setting any actions would see a change in behavior on upgrade. -Jared
Re: URIBL plugin 'action' defaults
And by that, I mean.. I'm not sure I *object*, because there *are* blacklists we trust... but in general, I think we try and avoid doing things that could cause people to lose mail unintentionally. So I think I lean slightly towards the consistent defaults of header tagging side. -R Robert Spier wrote: How about instead of hardcoding this, make deny be the default in the sample config? -R Jared Johnson wrote: Would anyone object to setting the default action to 'deny' on certain reliable low-fp URIBL lists? Probably Spamhaus SBL-XBL and DBL and URIBL Black. It seems like a new user turning on uribl checks would expect them to do something more than adding headers, as long as the services it rejects for are reliable. But this also means that anyone who was already using the plugin without setting any actions would see a change in behavior on upgrade. -Jared
