> > Also, CVS is now what I'll release as 0.27 unless something Really Bad
> > comes up in the next few days. Testing would be most appreciated. I am
> > planning to put it on my production servers thursday.
>
> Are you interested in my SpamAssassin patch (you are missing the
> Unix socket sup
> Apart from demonstrating my ability to forget vital features of running my
> system, does anyone have an opinion about whether it is worthwhile running
> qpsmtpd under PPerl???
We're running it (mostly) at perl.org, because it really hides the
startup overhead, which can have a huge effect on
>
> I'm curious as to whether anyone has built a forking server around qpsmtpd
> (essentially doing what tcpserver does, but in perl)? I'm aware of the
> select server version(*), but would prefer a forking server (say, using
> Net::Daemon). That would seem to be able to provide the same speedup a
> > pperl is pre-forking.
>
> Yes, but SelectServer isn't.
SelectServer doesn't fork at all.
> > It doesn't fork on every connection. The forking on every connection is
> > part of what causes some of the overhead.
>
> Do you have evidence that that is the case? Fork should be inexpensive,
>
I'm pretty sure this is a problem with clamdscan (note the _d_) not
properly parsing mime messages, and expecting them to be pre-parsed.
(clamscan -- note there is no _d_ -- has built in de-miming.)
-R
> > I'm pretty sure this is a problem with clamdscan (note the _d_) not
> > properly parsing mime messages, and expecting them to be pre-parsed.
> > (clamscan -- note there is no _d_ -- has built in de-miming.)
> You have to enable mime parsing in the config file. The option is:
>ScanMail
> If
> However please send patches if you find things missing. It's performing
> extremely well for me.
And for me too.
I'm testing it (in production). It's definitely performing faster and
lighter than pperl.
Now if only I could convince someone else (*cough*) that the qmail
tcpserver architecture
> > And for me too.
> >
> > I'm testing it (in production). It's definitely performing faster and
> > lighter than pperl.
>
> All sounds good.
>
> > Now if only I could convince someone else (*cough*) that the qmail
> > tcpserver architecture, high performance, and perl don't play along.
>
> S
> 1. Some mail servers(possibly Lotus Notes and others) don't queue and
> retry.
Can you confirm this? It would not surprise me if Lotus Notes is
doing something suboptimal, but this particular problem seems
unlikely.
> If there was version of ALLOWSOFT (opposite of DENYSOFT) that would allow
> Also just a random suggestion. On the list a reply-to field of
> [EMAIL PROTECTED]
> would help. Just hitting replies got directly to the sender, hense off
> list. W/ that in the reply field just hitting reply would send the
> message to the list.
Please google for "Reply-To Considered Harm
> Then adding tarpit support to existing plugins just becomes:
> $self->transaction->notes('tarpit', 1) if $tarpit_condition;
> tarpit_helper then records the ip address, denysofts, and tarpit picks it up
> next time it tries and does its thing.
I'm working on some new configuration mechanisms
> [EMAIL PROTECTED]:[plugins]$./dot-qmail-exists.pl
> suidperl needs fd script
You updated your perl. This is not a qpsmtpd problem.
cvsuser 04/04/14 19:19:02
Modified:.qpsmtpd-forkserver
Log:
- move configuration to top. (still suboptimal)
- child limiting
- logging helper
Revision ChangesPath
1.3 +39 -18qpsmtpd/qpsmtpd-forkserver
Index: qpsmtpd-forkserver
===
> Is their a value that you can put in qpsmtp that limits the amount of
> time a connection will say active? Something like
No. Not yet.
Definitely on my list of things to add. We've had issues with
connection limiting and lack of timeouts.
-R
>
> throwing an
>
> alarm $timeoutlength;
>
> into the main event loop is certainly easy enough
It's not quite that simple if you want to cleanup things, or aren't
running under tcpserver.
-R
> > Definitely on my list of things to add. We've had issues with
> > connection limiting and lack of timeouts.
> Do you have an idea of how you would do it?
Two different pieces.
First, a timeout callback for each "transport".
(tcpserver,select,fork). In some cases, this might just set a flag,
> seems to be a recent flurry of stuff that clamav isn't catching.)
Like what? I haven't noticed much get past clamav.
-R
> > Like what? I haven't noticed much get past clamav.
>
> ah, playing with things i bit, i see that i needed to add a '--mbox' to
> the clamscan command, or it wouldn't pick up the archives. (which is
> odd, since i thought it was picking them up before.)
Yup. That'll do it.
> (i'm not using
> Wierd things are happening when I run my qpsmtpd-0.26 installation
> under PPerl.
Yes, pperl and qpsmtpd often end up with weird things. It generally
works fine, but when it doesn't, it's really weird. That's why we
switched to forking.
-R
> 3) qpsmtpd-forkserver
hand
> 4) Any of the above using of pperl or SpeedyCGI?
Not anymore :)
> 5) Version 0.27.1? Anyone running CVS HEAD in production?
I think we're a mix of 0.27.1 and HEAD.
> 6) What is your load (messages per day)?
Well, extrapolating..
In one 30 minute period today,
> Since I am running a mail system that's supposed to simply work, because I
> sell the service, bincimap is absolutely out of the question.
You might want to look into dovecot. It "just works."
Very nice stuff, David.
Attached is a patch against 0.28-dev.
It only implements it in TcpServer, but that covers all thee major
uses, since SelectServer hasn't stabilized.
The one thing I'm wondering is if we've over-engineered this. At the
moment, we've only got TcpServer's loop and SelectSe
> > -use constant DENY => 901;
> > -use constant DENYSOFT => 902;
> > +use constant DENY => 901; # 550
> > +use constant DENYSOFT => 902; # 450
> > +use constant DENYHARD => 903; # 550 + disconnect
> > +use constant DENYSOFTHARD => 904; # 450 + disconnect
> >use consta
> > Here is a complete implementation of SMTP AUTH
> Could you s/\t//g; and resend?
> Tabs don't work well in open environments.
Eww. 4 spaces per tab please!
M-x untabify
-R
> > should we
> > be moving towards applying changes to CVS directly ourselves ?
>
> The best long term solution is to get RT or Bugzilla setup for the
> project.
We have an RT setup already.
I'll chat with Ask and we'll figure out how to get it back into better
use.
-R
> Looking into it a bit further - stunnel is the way to go. That way we
> don't have to fiddle with qpsmtpd at all - it just comes for free.
But then you don't get STARTTLS unless you do some funky magic. You
just get SSL on another port.
(Or am I missing something?)
Maybe the funky magic isn't
> stunnel has built in support for SMTP. I think it even handles
> extending the EHLO ESMTP options.
> But I'll need to do some testing.
Ahh, that stuff is new since the last time I patched stunnel (to give
it a tiny GUI on Windows.)
You're talking about the stuff in src/protocol.c, which looks
> > The received header insterted by QPSMTPD isn't understood by
> > SpamAssassin, and I'm wondering where to start. I'm no RFC expert,
> > but isn't the IP address supposed to be in brackets? When I
> > bracket it, SA has no problems. Anyway, here is the header:
The Received: line isn't meant to
> The current version of Net::SMTP doesn't make any attempt to determine
> the hostname of the current computer (not that I blame Graham for
> that), so that all e-mails are sent out as from
> "localhost.localdomain" unless an explicit Hello string is provided.
Thanks, applied.
-R
> The AV scanner plugin I am currently using (uvscan) requires the
> attached patch so that it can scan the existing temp file, rather than
> making a copy just for the scan.
Thanks, applied.
-R
> Yeah, I was just noticing how odd it was that FROM was always logged
> but TO wasn't logged at all. I think this is the wrong way to go
> --- SMTP.pm.orig2004-07-15 11:22:34.0 -0500
> +++ SMTP.pm 2004-07-15 11:23:32.0 -0500
> @@ -251,6 +251,7 @@ sub rcpt {
Thanks, ap
> +
> +## call srand(), else we will have (e.g.) the same tempfile in
> +## _all_ children
> +## i.e. after 'use File::Temp; ($fh,$name)=tempfile();' in a plugin
> +srand( ($$ ^ $port) ^ (time ^ unpack("C*", $iaddr)) );
>
> close($server);
What version of perl are you u
> >
> > All children. All forked. No srand. All different.
>
> I've seen this before - it might depend on loaded modules (e.g. a
> module might call srand in the parent). I've applied the patch anyway
> as it's sensible.
I just tested calling srand in the parent, and I still get different
file
> # zgrep 'kavscanner plugin: Running:' /var/log/mail.log.1.gz
> Jul 15 06:26:19 mail qpsmtpd: 31027 kavscanner plugin: Running:
> /opt/AVP/kavscanner -Y -P -B -MP -MD -* /tmp/uV7UIj6NQE 2>&1
> Jul 15 06:26:49 mail qpsmtpd: 31044 kavscanner plugin: Running:
> /opt/AVP/kavscanner -Y -P -B -MP -MD -*
> Sounds like it it might be useful to modify qpsmtpd so it can treat
> the return codes from the plugins optiionally and decide what to do
> further down the line.
I have some plans to do return code mapping and some smart stuff with
notes which would allow you to do things like that.
Right no
> The qpsmtpd web site says: "qpsmtpd as checked out from CVS has been used
> for the primary perl.org mail servers since 2001." Is it not true anymore?
> I'm using the lastest CVS on my setup, should I use the REL_0_28 tag instead
> of the CVS trunk?
It's true that we use a hacked up CVS version,
> 2004-07-21 07:52:38.502388500 tcpserver: end 16062 status 14
>
> Is it's the spamassassin plugin that's making the alarm calls in sub
> data time out and kill the process? Shouldn't that be caught by the
> eval in run_hooks? It seems just Too Unlikely that it should hit the
> race condition o
> Yeah, but the existing CVS code doesn't run at all because that brace
> needs to be a semicolon. If I get a chance tonight, I'll commit a fix
> for this (as well as a couple of other niggles I have).
I suspect that was my fault. I've fixed that one issue.
It would be cool to integrate mailgraph (or something like it) into
qpsmtpd.
http://www.onlamp.com/pub/a/onlamp/2004/08/12/mailgraph.html
> > I'm also currently preparing RPM and .deb packages for qpsmtpd (RPM
> > should be finished shortly, .deb may take longer since I'm a debian
> > newbie).
>
> That said, I should maybe solicit some input on the directory layout I
> have in mind.
>
> So I want to change it like this:
The curren
> > It would be cool to integrate mailgraph (or something like it) into
> > qpsmtpd.
> > http://www.onlamp.com/pub/a/onlamp/2004/08/12/mailgraph.html
>
> Interesting! My boss just last week suggested we need to do some
> internal promoting and maintain some uptime graphs of the various
> systems.
> Is there anyone else running multiple queue plugins?
Yes, we are.
The plugins, except for the last, should *only* return OK or DECLINED.
-R
> I know the problem now; it's not possible to run the same plugin
> twice, even with different parameters. I just made a hardlink from
> queue/qmail-queue to a different name and it correctly fell through
> the first two layers and delivered with the last.
In theory, that's supposed to work. Ev
> I see that in May-June, a patch or two for timeout settings
> got posted. Anyone have updates on these?
I *think* I have some timeout related patches applied to my local copy
that aren't in the trunk yet. I'll try and get those extracted.
I just committed some new plugins to the CVS trunk:
geoip - uses MaxMind's GeoIP database to find out where in the world
a connection is coming from. Compatible with 0.28
p0f - uses Michal Zalewski's p0f (a passive OS fingerprinting tool)
to figure out what kind of machine a connection is c
> I posted a patch to require_resolvable_fromhost a month or so ago, which
> had that useless (IMHO) check removed. It also performed it's DNS lookups
> in the background, allowed IPv4 and IPv6 address literals, caught
> private/local address literals and DNS lookups. For some reason it didn't
> ma
> A bit like this?
> http://stats.logidac.com/qpsmtpd.shtml
That's quite pretty!
> We already have 'queue' and 'deny' hooks - we can just plug in to that.
> I've been using the attached plugin to do stats capturing to a dbm
> database - I'd probably change the backend now (given some weirdness I've
> been seeing with Berkeley DB under load), but the general concept has
> work
(Side note, John, your newsreader is not doing nice things to the mail
headers.)
> Funny, I thought that was what regexes were for... ;)
regwhat?
> > - We teach plugins to record things.. so spamassassin could do
> > something like $qp->transaction->notes( 'stats_spam' => 1 ); or
> >
> Robert Spier wrote:
> > (Side note, John, your newsreader is not doing nice things to the mail
> > headers.)
> (Sorry, Mozilla mail, you know. :o Care to be specific and I'll open
> a ticket with them?)
(It loses the (To|Cc): qpsmtpd at perl.org, so it
> > (It loses the (To|Cc): qpsmtpd at perl.org, so it's really annoying to
> > reply to.)
> That's a carbon-based error (i.e. /I/ am deleting it). Since I am
> using a newsreader (and I'm not on the list), if I leave that header
> in, I get a warning message from the listserve software. I'll stop
I just committed the first (lightly tested) code for plugin wrapping.
This lets you write plugins that look like this:
(plugins/wrap)
sub register {
my ($self, $qp, $wrap, @args) = @_;
$self->wrap_plugin($wrap,@args);
}
sub mail_handler {
my ($self) = @_;
warn "WE ARE HERE\n";
my $r
Other things I committed tonight:
- We were calling load_plugins twice. This meant that plugins got
registered twice and therefore called twice.
- You can now use the same on-disk plugin with multiple arguments.
Just put :0,:1,:2 after the name. i.e.
queue/qmail-queue /path/to/prim
> Please try to add tests as you go.
>
> If we add a few ENV overrides for the configuration directory location
> it should be possible to test plugins (and the plugins mechanism)
> too...
It might be cleaner to get rid of the ENV overrides and genericize out
the configuration (like you wanted to
> > - We were calling load_plugins twice. This meant that plugins got
> > registered twice and therefore called twice.
>
> I wonder if we should protect against this with a flag. Or if the
> following:
I thought about the flag, but there may be reasons when you wish to
call it twice. (Can't t
> I was thinking about this the other day. It would be a simple matter
> of having a function that plugins can call:
>isa_plugin('pluginname');
> Which you can just put somewhere in your plugin file. And yes, I think
> the symbol table munging is horrid and should be done using
> inheritance, a
> Anyone done any work (or thinking) about supporting hashcash [1] support
> to qpsmtpd? Validation is included in SpamAssassin 3 - is there any value
> in a qpsmtpd validation plugin as well? An outward minting plugin would
> also be nice, at least for small-medium sites.
This made me do the ma
> > On the outward side... that seems quite out of place for qpsmtpd,
> > although I could understand if you're using it for relay. Seems more
> > like it should be part of qmail-send or such though.
>
> Yep, I'm using it for relaying too. qpsmtpd seems a much better place to
> do it than 10 diff
> Today I was supposed to do my expenses. Instead I did this.
> http://www.sergeant.org/Apache-Qpsmtpd/
You rock!
So, how does it perform compared to forkserver?
-R
> So qpsmtpd is wrong to say it can't parse a single character sub-domain?
Yes.
It's before 9am, and I'm still groggy, but I think this regexp is the
issue.
my $subdomain = '(?:[a-zA-Z0-9](?:[-a-zA-Z0-9]*[a-zA-Z0-9]))';
I think what we want is this:
my $subdomain = '(?:[a-zA-Z0-9](?:[
> > So, how does it perform compared to forkserver?
>
> I have no idea :-) I haven't had any chance to do benchmarking, in
> fact I'm not entirely sure it'll fully work.
You'd better get cracking. ;)
> What I do know is that check_earlytalker definitely doesn't work.
Doh! We like that feature.
> If the files aren't unlinked on ALRM, when should they be
> unlinked?
Our usage of File::Temp _will_ cleanup the files on destruction, the
problem is an unhandled ALRM will cause the program to terminate
without doing those cleanups.
qpsmtpd-forkserver DOES have an ALRM handler, and it works we
> > + my $threshold = $self->{_args}->{reject_threshold};
> > + return (DENY, "spam score $score exceeded threshold $threshold")
> > +if $score >= $threshold;
>
> I think it was intentional not to put it in there as to not reveal the
> local configuration... I could be convinced otherwise t
> Robert Spier already started implementing this:
> You'll have to check out from CVS to get these two...
I've been sidetracked, but my future plans are to use my plugin
wrapper/inheritance stuff to put greylisting[1] in place for windows
boxes.
I haven't had time to look i
> Talk to Randal Schwartz too. He's been doing this for a while now.
Yes, I got the idea from him way back when. He's got the benefit of
being able to do it in his TCP stack, and not at the application
level.
-R
>
> > I wonder if it would be more appropriate to add this to Qpsmtpd/SMTP.pm instead...
>
> + if ( $size == 0 ) { # empty message
> +$self->respond(554, "No data received")
> +and return $self->disconnect;
> + }
> +
I'm pretty sure that an empty body is valid RFC2821.
Server SMTP sys
> *spamassassin
>Must replace any existing X-Spam headers with local score,
>rather than adding. Don't care what other SA instances thought.
>(Michael Holzt)
I'm not sure this is correct. Sometimes we do care what other SA
instances thought. Like when we're compari
> Robert Spier wrote:
>
> > I think what we want is this:
> > my $subdomain = '(?:[a-zA-Z0-9](?:[-a-zA-Z0-9]*[a-zA-Z0-9])?)';
>
> I tested this with
>
> use re 'debug';
>
> and it did seem to correctly match the pattern we ar
I think the general direction we agreed to go earlier is to develop a
configuration interface such that everyone can have what they want.
You can have your plugin per directory setup.
I can have my .ini files.
Someone else can have his database lookups.
Since we won't be able to agree on a s
> I want to be able to have some users that will never use greylisting.
> How do I do that?
This is what I designed the plugin inheritance system for.
-R
> Webcvs seems poorly again. I go to http://cvs.perl.org/viewcvs/qpsmtpd/
> and I get
Grr. Looks like one of the viewcvs configuration options isn't
working right. I've put a workaround in place.
-R
> At 25 connections we starting hitting a load of 1.5 - 2.0. If that's
> normal it's cool, if not what might I be doing wrong?
That's normal. qpsmtpd+clamav+spamassassin is a pretty heavy
combination.
> seconds ago but was denied with the require_resolvable_fromhost. What
> seems like is happening is that Qpsmtpd is dropping the connection but the
> buffers aren't being flushed so that when the next Qpsmtpd picks up the
> file handle the old one had it's getting the data that was left over.
>
> Any objections to move qpsmtpd to Subversion (from the CVS repository)
> after we release the next version?
For people interested in testing this out, there's an updated mirror
of the current CVS at
https://svn.develooper.com/qpsmtpd/cvs/
-R
> I don't know how you were planning on doing the move, but you might
> want to try both cvs2svn and VCP to see which more accurately captures
> the branch/tag of the original CVS repository.
We'll be using cvs2svn. VCP doesn't support tags.
-R
Algorithm::FloodControl
http://www.perl.com/pub/a/2004/11/11/floodcontrol.html
This would be an interesting thing to implement as a qpsmtpd plugin.
I think I'd want to treat an event as from a single envelope from.
-R
> - my $timeout = $self->config('timeout');
> + my $timeout = $self->config('timeoutsmtpd') # qmail smtpd control file
> +or $self->config('timeout') # qpsmtpd override
> +or 1200; # default smtpd value
Please don't use C< or >. use C< || >
I got a little overzealous tonight and sync'ed the perl.org production
system up with CVS HEAD.
So.. soon it'll be time to roll 0.28. :)
-R
(Part of the reason I did this was because I'm testing with 5.8.6 RC1,
to try and get around a "regex running until the heat death of the
universe" prob
Why are we restoring STDIN/STDOUT after a failed exec, right before we
exit?
Bad things happen when that exec fails... especially if the streams
get flushed in the wrong place.
Any reason not to do the following? (Second half of patch is the
interesting part.)
-R (running this in production no
> I thought we were already past 0.28. But, I don't pretend to know how
> you Perl guys version things... ;-)
You're right. I meant 0.29. Although there have been enough changes,
we should probably call it 0.32 or something.
> One thought: perhaps this could be a good time to go through the
>
What's wrong with /^TV/ ?
ALL modern Microsoft executables start with /^MZ/.[1]
For more info as to why what we're doing is silly, see this post:
http://archives.neohapsis.com/archives/postfix/2002-04/1914.html
-R
Footnotes:
[1] Mark Zbikowski
> I can pull head, port, test and diff
> it sooner than later if there's any interest. I know some use multilog, but
> I've been running with stdout piped to logger until I patched for it.
This wouldn't be a bad thing to have.
-R (expressing some interest in seeing the patch)
> > because '=' binds tighter than 'or', so
>
> [one short test program later]
>
> Hrm... you're right. Work fine with parens, though... ;)
Unnecessary punctuation!
I always forget about the =/or binding order... but I think Keith
proved my point. Use C< || >.
C< or > will cause problems soo
> In a really old version (from +2 years ago, when the queue code was in
> Qpsmtpd.pm) it was used to set the readers to filehandle 0 and 1 like
> this:
>
> close MESSAGE_WRITER or die "could not close message writer in
> parent";
> close ENVELOPE_WRITER or die "could not close enve
cvsuser 04/11/27 09:54:46
Modified:plugins/queue qmail-queue
Log:
Remove extraneous filehandling twiddling from qmail-queue that could cause
weirdness if the exec failed.
Revision ChangesPath
1.8 +3 -8 qpsmtpd/plugins/queue/qmail-queue
Index: qmail-queue
> Here's a patch against 0.28. I'll try to remember to diff it against HEAD,
> but no promises. =)
Your mailer wrapped some lines. Can you send it encoded differently?
> P.S. Let me send this message with my subscribed email. *smirk*
I added the other one to the allow list, too.
-R
> > Here's a patch against 0.28. I'll try to remember to diff it against HEAD,
> > but no promises. =)
>
> Your mailer wrapped some lines. Can you send it encoded
> differently?
Never mind. I unwrapped it and got large chunks of it applied. I'll
see about getting parts of it committed over t
This made me think, shouldn't the DENY code log the deny reason,
instead of modifying every plugin to log the reason?
-R
> @@ -47,6 +52,9 @@
>sub rcpt_handler {
> my ($self, $transaction, $rcpt) = @_;
> my $note = $transaction->notes('badmailfrom');
> - return (DENY, $note) if
> >> I can pull head, port, test and diff
> >> it sooner than later if there's any interest. I know some use
> >> multilog, but
> >> I've been running with stdout piped to logger until I patched for it.
> >
> > This wouldn't be a bad thing to have.
>
> How about logging going through the plugin m
> > For more info as to why what we're doing is silly, see this post:
> > http://archives.neohapsis.com/archives/postfix/2002-04/1914.html
>
> Great theory, but poor in practice. If I can block any significant
> percentage of executable attachments by assuming a certain Base-64
> prefix, then tha
> > This made me think, shouldn't the DENY code log the deny reason,
> > instead of modifying every plugin to log the reason?
>
> Only if you can make it consistent and change all the different
> handlers to DTRT. (IMO).
Like this patch?
Index: Qpsmtpd/SMTP.pm
> logging/syslog unix
> logging/stdout 5
>
> Where 'inet' is the syslog's default, 'unix' and 'stream /path/to/stream'
> and the '5' arg for stdout is just like the entry in config/loglevel.
Smells like inconsistency to me.
Yes, right now we're using syslog-like log levels, but seems like we
mi
> > I think plugins are a little too heavy for this.
>
> Why? We have config plugins - are they too heavy?
config and logging is orthogonal. If logging breaks, you don't find
out that other things broke. We also tend to do a lot of logging.
At a first approximation:
[EMAIL PROTECTED] ~/projec
> it's a minor thing, but the default port for qpsmtpd-forkserver is 2525
> in the code, but it claims to be 25 in the usage text.
>
> also, the $MAXCONNIP was not settable from the command line.
>
> patch attached fixes both.
>
Thanks, applied.
> > plugins are, by their nature, fragile. I'm just not sure I like my
> > logging to be fragile.
>
> I'm fairly sure we can make it "safe" to the point that if all logging
> plugins break we log to STDERR at a minimum.
> Log::Dispatch has a plugin architecture, and it seems to me that we
> sho
> What I did initially was to just copy queue/qmail-queue and hardcode
> it to use qmqpc-queue (so I don't have any messy message loops). I
> also changed it to return DECLINED instead of OK on success. However,
> it occurred to me that I could just as easily extend the existing
> queue plugin to
> I'm sure my simple logging/syslog plugin could be enhanced. In the case of
> syslog, this cutoff can be ultimately controlled in /etc/syslog.conf.
> Perhaps the lower level events don't get written to disk, or maybe they do
> but get rolled more often. Maybe some are written to a pipe from sysl
> - my ($name) = ($0 =~ m!(.*?)/([^/]+)$!);
> + my ($name) = ($0 =~ m#(.*?)/([^/]+)$#);
Please don't make stylistic changes as part of other patches. The
general qpsmtpd standard is to use ! in this case, not #.
>$configdir = "$name/config" if (-e "$name/config/$config");
> + if (exists $
> my ($space, $from) = ($from_parameter =~ m/^from:(\s*)(<[^>]*>)/i)[0];
> $self->transaction->notes("extra_space_in_mail_from", $space ne
> $self->transaction->"");
I'd prefer to see something similar to the 'cautious' above. But
instead of encoding the 'extra_space_in_mail_from' log
> relay_client method on the $connection, but I know that Robert was
> threatening to make a 0.29 release...
I was hoping Ask would take the hint. :)
I think we're at a stable point right now. I can roll a release, but
really it's Ask's decision.
-R
1 - 100 of 443 matches
Mail list logo
