gmane.mail.qpsmtpd

KW Distribution 17 MSI sans OS a un prix ...

KW Distribution — 2013-05-06T15:49:17

Re: db suite plugin

Ernesto — 2013-05-02T14:08:10

Am 01.05.2013 19:28, schrieb Luigi Noris:
Hi Luigi,

the entries in db_base

driver=mysql
database=maildb

are used to build the $data_source for DBI->connect as follows:

'DBI:' . $config->{driver} . ':' . $config->{database};

The above example connects to a local database:

'DBI:mysql:maildb';

DBI allows to specify a remote database:

dbi:DriverName:database_name
dbi:DriverName:database_name< at >hostname:port
dbi:DriverName:database=database_name;host=hostname;port=port

So try:

driver=mysql
database=maildb< at >example.com:3306

or:

driver=mysql
database=database=maildb;host=example.com;port=3306

NOT TESTED!

Please notice me, if you get error messages.

See also:

http://dienstleistung-kultur.de/qpsmtpd/db_base.shtml#configuration

http://dienstleistung-kultur.de/qpsmtpd/db_common.shtml#db_connect

http://search.cpan.org/~timb/DBI-1.625/DBI.pm#connect

Regards
Ernesto

db suite plugin

Luigi Noris — 2013-05-01T17:28:02

Hello, I try to use db suite plugin because I need to share the DB of greylisting with two server. My intention is to use a remote mysql server but I unable to understand where and how specify the server IP or name in the db_base config.

Thx in adv,

Gigi Noris

I found the future by dredging in the past

Matt Simerson — 2013-04-30T03:23:16

I found myself wanting to check for clients who are adding illegal whitespace after the MAIL FROM and RCPT TO commands.  Before I started hacking, I did a quick search and found this thread:

Stricter parsing of mail from: and rcpt to:

http://grokbase.com/t/perl/qpsmtpd/04cmjwqh9p/stricter-parsing-of-mail-from-and-rcpt-to/oldest

The gist of the thread is that a number of people were for stricter parsing, a number were against, and nothing happened. A similar exchange was had regarding angle brackets, except that time hooks were added allowing plugins to rewrite the address, adding the missing angle brackets.

For other similar purposes, Qpsmtpd::Command was added, and the ability to substitute ones own parser was added, probably about the same time the parse_addr_withhelo plugin was added. 

But I don't need an entirely new parser. I just want to do something quick and fun like:

   if ( 'from: ' eq lc substr($envelope_header, 0, 6) ) {
        $self->adjust_karma(-1);
   };

After reading the proposed solutions, the one I adopted was storing the unparsed line in a connection note, making it available to plugins that wish to inspect and act upon it.

Matt

PS: I find it amusing that 7 or 8 years later, clients inserting that space have a 97+% correlation with infected PCs. Not enough to block based on it, but more than enough to cast suspicious glances.

--- a/lib/Qpsmtpd/SMTP.pm
+++ b/lib/Qpsmtpd/SMTP.pm
< at >< at > -354,6 +354,7 < at >< at > sub mail {
     }
 
     $self->log(LOGDEBUG, "full from_parameter: $line");
+    $self->connection->notes('envelope_from', $line);
     $self->run_hooks("mail_parse", $line);
 }
 
< at >< at > -442,6 +443,7 < at >< at > sub mail_respond {
 
 sub rcpt {
     my ($self, $line) = < at >_;
+    $self->connection->notes('envelope_rcpt', $line);
     $self->run_hooks("rcpt_parse", $line);
 }

clamdscan plugin defaults

Matt Simerson — 2013-04-30T02:30:52

Within the register sub of the clamdscan plugin, is this little nugget:

    # Set some sensible defaults
    $self->{'_args'}{'deny_viruses'} ||= 'yes';
    $self->{'_args'}{'max_size'}     ||= 128;
    $self->{'_args'}{'scan_all'}     ||= 0;

Having a default enable for denying viruses is sensible enough. 

But a max_size of 128K? You mean all a virus author needs to do is attach an image to his virus laden message to evade virus scanning on a qpsmtpd server?  Is that really a sensible default?  

My first inclination is that max_size should default to whatever $config->data_bytes is set to. Why would such a low limit be considered sensible?

The other thing I'm questioning is why scan_all=0 is the 'sensible' default.  If one is going to bother running a virus scanner, it would seem the "safe" choice is to scan everything. Should it be as easy as inserting an illegal character into the Content-Type field value (which would get ignored later), to bypass multipart detection, and thus virus scanning?

Matt

Re: new feature: DKIM message signing

Shane Hill — 2013-04-28T13:17:53



yay!

new feature: DKIM message signing

Matt Simerson — 2013-04-26T08:47:38

I added a signing feature to my DKIM plugin. 

https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/dkim

Matt

PS: for added pleasure, I also added a script that makes deploying DKIM really, really easy.  How easy?

# cd ~smtpd/config/dkim
# ./dkim_key_gen.sh example.org

Voila. Keys and selector generated. Now DNS needs to be updated. I made that easy too:

# cat example.org/dns

apr2013._domainkey TXT "v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/Wu1fd74UXwH//0uiX/6C0hkv3I/PdeTxfnzHN6GrehJpCYBd1BKuigduwt/wZFVgUopwxmcjxSK6qrkADtHC+ZiqC/sqcVuVDhnvzkIgd7dYhqBcVORg6f8Eg8132yPkmHyDm588qKfdFSEUVgBqSfqZg4ZdG4Uq5erHAyQIEcs0h7xqUKJKA5xJWdRwaVYbNkNDAscax1WrSvMHQkKBf5bWUtkMGc/HeoZ6T3VTn5Le0OgLoINj4lNTFfT6toXsbZsKzOaUYacnWVOq2v2lWgghOMRQHYPr7ldl2E7/6sNSpNT8KXAiT7wlfE+/xXg+0DyQq/ahKaPgAecCCFiwIDAQAB"

Tell the world that the ONLY mail servers that send mail from this domain are DKIM signed and/or bear our MX and A records.

With SPF:

        SPF "v=spf1 mx a -all"
        TXT "v=spf1 mx a -all"

With DMARC:

_dmarc  TXT "v=DMARC1; p=reject; adkim=s; aspf=r; rua=mailto:dmarc-feedback< at >example.org; ruf=mailto:dmarc-feedback< at >'example.org; pct=100"

With DomainKeys (deprecated)

_domainkey TXT "o=-; t=y; r=postmaster< at >example.org"

For more information about DKIM and SPF policy, the documentation within each plugin contains a longer discussion and links to more detailed information:

   perldoc plugins/dkim
   perldoc plugins/sender_permitted_from

plugin announcement: DMARC

Matt Simerson — 2013-04-26T08:38:58

NAME
Domain-based Message Authentication, Reporting and Conformance

SYNOPSIS
DMARC: an extremely reliable means to authenticate email.

DESCRIPTION
From the DMARC Draft: "DMARC operates as a policy layer atop DKIM and
SPF. These technologies are the building blocks of DMARC as each is
widely deployed, supported by mature tools, and is readily available to
both senders and receivers. They are complementary, as each is
resilient to many of the failure modes of the other."

DMARC provides a way to exchange authentication information and
policies among mail servers.

DMARC benefits domain owners by preventing others from impersonating
them. A domain owner can reliably tell other mail servers that "if it
doesn't originate from this list of servers (SPF) and it is not signed
(DKIM), then reject it!" DMARC also provides domain owners with a means
to receive feedback and determine that their policies are working as
desired.

DMARC benefits mail server operators by providing them with an
extremely reliable (as opposed to DKIM or SPF, which both have
reliability issues when used independently) means to block forged
emails. Is that message really from PayPal, Chase, Gmail, or Facebook?
Since those organizations, and many more, publish DMARC policies,
operators have a definitive means to know.

Instructions on how to use the plugin, how to deploy DMARC to protect ones own domains, and more is included as POD in the plugin.

Available in the qpsmtpd-dev repo:

https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/dmarc

As contrasted to most qpsmtpd plugins, DMARC provides an extremely reliable basis for message rejection. Better still, it's based on the published policies of the domain the message purports to be from (in the From: header), making it complementary to SPF, which checks the Envelope FROM sender.

If you find that SpamAssassin isn't catching all the forged < at >google.com emails that the Win bots are sending, this plugin will do the trick. It'll also stop all the forged [a-z]{6}< at >yahoo.com spams those senders haven't made it onto a DNSBL yet. The largest *legitimate* email senders have deployed DMARC records. And now I have too. :-)

Matt

plugin announcement: FCrDNS

Matt Simerson — 2013-04-26T08:25:55

NAME
       Forward Confirmed RDNS - http://en.wikipedia.org/wiki/FCrDNS

DESCRIPTION
       Determine if the SMTP sender has matching forward and reverse DNS.

       Sets the connection note fcrdns.

WHY IT WORKS
       The reverse DNS of zombie PCs is out of the spam operators control.
       Their only way to pass this test is to limit themselves to hosts with
       matching forward and reverse DNS. At present, this presents a
       significant hurdle.


There's more POD that explains the tests, config settings, and method. 

Much like many other plugins, fcrdns is not reliable enough (only about 90%)  to use for message rejection. However, when combined with any sort of heuristics system such as the karma plugin, the fcrdns plugin provides another extremely reliable indication of spam likelihood. 

Matt

Devin's Received auth header patch

Matt Simerson — 2013-04-26T07:33:48

Back in August of last year, Devin Carraway posted this:

http://www.nntp.perl.org/group/perl.qpsmtpd/2012/08/msg9954.html

And  a very short discussion ensued. 

I have applied a modified portion of that patch to qpsmtpd-dev. After the patch, the # enclosed area in the following header is removed:

Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.125])
(76.121.98.64)
### (smtp-auth username matt< at >redacted.com, mechanism plain) ###
by mail.theartfarm.com (qpsmtpd/0.92) with (AES128-SHA encrypted)
ESMTPSA; Fri, 26 Apr 2013 02:51:22 -0400

While many mailing list to www gateways redacting email addresses in headers, many do not. It just seems imprudent to be publishing that data into the headers, as well as having logged it. 

Matt


--- a/lib/Qpsmtpd/SMTP.pm
+++ b/lib/Qpsmtpd/SMTP.pm
< at >< at > -824,7 +824,7 < at >< at > sub received_line {
           . " (HELO "
           . $self->connection->hello_host . ") ("
           . $self->connection->remote_ip
-          . ")\n  $authheader  by "
+          . ")\n by "
           . $self->config('me')
           . " (qpsmtpd/"
           . $self->version

qpsmtpd-dev release 0.92

Matt Simerson — 2013-04-26T06:54:26

I just tagged the 0.92 release of qpsmtpd-dev.

It can be downloaded by clicking the Tags button on the github project page at https://github.com/qpsmtpd-dev/qpsmtpd-dev. The changes are listed below.

Matt

0.92 Apr 20, 2013

new plugins: dmarc, fcrdns

new feature: DKIM message signing. See 'perldoc plugins/dkim' for details.
includes script for generating DKIM selectors, keys, and DNS records.
RAM bumped up to 300MB, to avoid memory exhaustion errors.

Qpsmtpd.pm: untaint config options before passing them to plugins.

auth_vpopmaild: untaint responses obtained from network. Combined with the taint fix for config options, enables auth_vpopmaild to work when setting the host config and port

tls: added ability to store SSL keys in config/ssl

log2sql: added UPDATE query support

removed FAQ to: https://github.com/qpsmtpd-dev/qpsmtpd-dev/wiki/faq

helo: cease processing DNS records after first positive match

karma: sprinkled karma awards throughout other plugins
- limit poor karma hosts to 1 concurrent connection
- allow +3 conncurrent connections to hosts with good karma
- limit recipients to 1 for senders with negative karma

Sanitize spamd_sock path for perl taint mode - Markus Ullmann

geo_ip: added too_far option (deduct karma from distant senders)

bogus_bounce: add Return-Path check, per RFC 3834

Fix for Net::DNS break - Markus Ullmann

SPF: arrange logic to so improve reliability of spf pass reporting (helpful to DMARC plugin)

is_naughty removed from is_immune feature. Allows more granular handling by plugins.

Logterse now on github

Charles B — 2013-04-06T07:17:26

I am migrating my web server and in the process have relocated the logterse plugin and ancillaries to github under qpsmtpd-logterse.
Its unchanged from the version that was on ncc.com.au

Enjoy!

Regarding Qpsmtpd

chetan sharma — 2013-02-14T18:12:15

Hi
   I just installed qpsmtpd on my system with 25 port and i have also
installed postfix email server. I moved the smtp port of postfix to 2525 so
that i can configure. So then after i tried to send a mail from the CLI
using mail command then i got this Error.

"[root< at >postfix qpsmtpd-0.84]# mail root
Subject: new mail
dsag

ds
d
v.
.
Cc:
[root< at >postfix qpsmtpd-0.84]# Feb 14 23:35:07 postfix sendmail[16669]:
r1EI57op016669: from=root, size=42, class=0, nrcpts=1,
msgid=<201302141805.r1EI57op016669< at >postfix.test>, relay=root< at >localhost
Feb 14 23:35:07 postfix sendmail[16669]: r1EI57op016669: to=root,
ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay,
pri=30042, relay=[127.0.0.1] [127.0.0.1], dsn=4.2.0, stat=Deferred: 450 No
plugin decided if relaying is allowed
"


And from Gui of squirrel mail i am getting this Error.

"Message not sent. Server replied:

    Requested mail action not taken: mailbox unavailable
    450 No plugin decided if relaying is allowed
"
Can anyone help me on this issue that what is the reason behind this Error.

Re: Net::DNS broke qpsmtpd-forkserver

David Nicol — 2012-12-27T21:51:59


Net::DNS is under somewhat active maintenance, I just received a warning
and an invitation to join its mailing list, as TipJar::MTA has a dependency
on it.

Re: Net::DNS broke qpsmtpd-forkserver

Peter J. Holzer — 2012-12-27T21:21:23

[...]

That block was a crude workaround for a bug in Net::DNS. IIRC it has
been fixed a long time ago, so it should be safe to remove that block
completely. I'd have to check the code of Net::DNS to be sure, though.

hp

Net::DNS broke qpsmtpd-forkserver

Walt Mankowski — 2012-12-27T19:26:28

I just restarted qpsmtpd after a reboot and it was no longer receiving
mail.  In my logs I saw messages that said

    method Net::DNS::Header::nextid undefined at ./qpsmtpd-forkserver line 288.

The problem is in this block of code:

    # all children should have different seeds, to prevent conflicts
    srand();
    for (0 .. rand(65536)) {
        Net::DNS::Header::nextid();
    }

That method was removed in Net-DNS-0.69, which was released on
December 5.  I changed that line to

        Net::DNS::Header::id();

That fixed my immediate problem, but since I don't really understand
what that block is trying to do, I don't know if it introduces any
other problems.

Walt

Re: postfix-queue taking a LONG time on large mails

Michael Holzt — 2012-12-04T19:48:40

I believe this will only affect the further processing of the mail, e.g.
use of virtual domain/alias tables. As it does not work properly without
that flag anyway, yes, it was set.

In the meanwhile I did some further investigation. It appears that quite
a good part of the delay is happening internally in qpsmtpd. As I said,
with my alternative queuing plugin a big mail now only took about 16
seconds. I then increased logging to see which plugin runs when and
the queue plugin is only called after 14 of these 16 seconds.

In the steps before queuing qpsmtpd does some copying/processing and
it processes the mail line by line. I suspect this to be the reason
of the delay. I'm not sure if this can be changed easily. I would 
guess that other MTAs do this processing already while receiving the
mail (data-phase before data post), therefore not having to do the
processing in full afterwards.

Oh, and the queing plugin will again process the mail line by line,
adding further delay. This is true for all queue plugins. This can
surely not be changed easily without deep modifications inside
qpsmtpd and the way we process a mail.

With my alternative queing plugin the delay is now more or less
acceptable but I'm still not satisfied. I think more research in
finding the source of the long delay is warranted as even processing
10 MB line by line shall not be that slow on a modern machine (this
is a quadcore Opteron).


Regards,
Michael

RE: postfix-queue taking a LONG time on large mails

Sydney Bogaert — 2012-11-30T08:07:14

Hello,

Did you specify FLAG_MASK_EXTERNAL as argument to queue/postfix-queue ?
Does it change something ? I've had problems with the plugin until I added this parameter.

Sydney

-----Message d'origine-----
De : Michael Holzt [mailto:kju< at >fqdn.org]
Envoyé : jeudi 29 novembre 2012 01:09
À : qpsmtpd< at >perl.org
Objet : Re: postfix-queue taking a LONG time on large mails

The postfix-queue plugin uses a socket to the cleanup daemon. I'm not
sure if the connection over the socket is slow (the cleanup daemon might
be slow reading data from it) or if there is some additional processing
which takes time.

An alternative path would be to drop the mail into the postdrop queue
and the notify the pickup-daemon. This would have the advantage that
qpsmtpd would not need to wait for an answer. A disavantage would be
that if something goes wrong after putting the mail in the queue (e.g.
pickup-daemon not accepting it), it would not reflect on the SMTP
return code. Another (minor) disavantage would be that doing it this
way, Postfix would insert another Received-Line (but who cares).

I have just written a very stupid queue plugin which uses
Mail::Postfix::Postdrop to inject the mail. Interestingly enough it
seems that the code from our Postfix-queue Plugin was copied from
there (we e.g. have a comment which still talks about speaking to
the pickup daemon).

I tested my plugin and while it still took 16 seconds to queue the
mail (10 MB attachemnet) , this is certainly much better than the
more than two minutes of the current queue plugin.

Therefore I suggest that we change either the current plugin (which
for reasons unknown to me uses a library which was made directly
part of qpsmtpd) or add a second one (the internal library would need
to be slightly modified).

Regards
Michael

Re: Alternative Postfix-Queue Plugin 'postfix-maildrop'

Michael Holzt — 2012-11-29T03:28:42

I mentioned in my other mail that it probably makes sense to have
both methods. However the functionality of the current plugin is
mostly not done in the plugin itself but in Qpsmtpd::Postfix. I'm
not sure why this is so, and I don't think it is good to have that
code in Qpstpd-Core, but that is how it is.

So to integrate the alternative method, Qpsmtpd::Postfix needs to
be modified and then the existing Postfix-queue plugin could be
enhanced to support both methods.

I will provide a patch to do so after some more testing and when
I'm confident that everything works fine. I sent the plugin as of
now mainly in the hope that others might test it as well.


Regards
Michael

Re: Alternative Postfix-Queue Plugin 'postfix-maildrop'

Matt Simerson — 2012-11-29T03:21:37

It doesn't look like it would be very difficult to update your plugin so that it works using the drop-in method, and the old method as well.  Perhaps with a config setting that lets people swap between the efficient -vs- paranoid method?

I don't have a preference on this matter, but others that use this plugin may. Having a backwards compatible option, and a paragraph of POD explaining the difference (pros & cons) would go a long ways towards smoothing over any potential objections. 

Matt

On Nov 28, 2012, at 7:16 PM, Michael Holzt <kju< at >fqdn.org> wrote:

Alternative Postfix-Queue Plugin 'postfix-maildrop'

Michael Holzt — 2012-11-29T03:16:24

Hello everyone,

considering what I wrote in my last mails, I have now written my own
experimental queue plugin for postfix which will drop the mail into
the postdrop-Spool and then notify the pickup daemon.

With this plugin the queuing of a 10 MB mail will now only take
three seconds. The processing afterwards (by the pickup daemon)
will still take two minutes, but at least the SMTP client is no
longer stalled and might run into an error.

This plugin currently duplicated some of the functions out of
Qpsmtpd::Postfix. It might make sense to add this as an alternative
inject method to that class.

My plugin is attached. I don't make any promised but it works for
me. Testing by others and feedback would be very much appreciated.



Regards
Michael