headers
Peter J. Holzer | 1 Jul 2010 14:06
Picon
Favicon

Re: RFC on concept: mailinglist_reject_nonsubbed

On 2010-06-29 02:13:08 +0000, Robin H. Johnson wrote:
> I'm mucking with an idea, and hoping the denizens here might have some
> input, esp. about potential breakage introduced.
> 
> Summary:
> For any given valid recipient, compare the sender whitelist of exact
> matches and regexes.  If the sender is NOT present, issue a permanant
> deny (5xx).

I've written a plugin to do this for majordomo mailinglists: 
http://www.hjp.at/projekte/qpsmtpd/majordomo/ 
It's been in use for several years now. Early versions only looked at
the envelope sender, but that was surprising to majordomo users
(majordomo uses the From: header), so I implemented an alternate check
for the From: header. Since then it works flawlessly. Cuts down
enormously on the spam the moderators get.

I started porting it to mailman, but we never got around to switch our
public mailinglists from majordomo to mailman that wasn't finished
either.

	hp

--

-- 
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | hjp <at> hjp.at         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on community <at> lists.openmoko.org
Permalink | Reply | 1 comment |
headers
Robin H. Johnson | 1 Jul 2010 23:20
Picon
Favicon
Gravatar

Re: RFC on concept: mailinglist_reject_nonsubbed

On Thu, Jul 01, 2010 at 02:06:48PM +0200, Peter J. Holzer wrote:
> On 2010-06-29 02:13:08 +0000, Robin H. Johnson wrote:
> > I'm mucking with an idea, and hoping the denizens here might have some
> > input, esp. about potential breakage introduced.
> > 
> > Summary:
> > For any given valid recipient, compare the sender whitelist of exact
> > matches and regexes.  If the sender is NOT present, issue a permanant
> > deny (5xx).
> 
> I've written a plugin to do this for majordomo mailinglists: 
> http://www.hjp.at/projekte/qpsmtpd/majordomo/ 
> It's been in use for several years now. Early versions only looked at
> the envelope sender, but that was surprising to majordomo users
> (majordomo uses the From: header), so I implemented an alternate check
> for the From: header. Since then it works flawlessly. Cuts down
> enormously on the spam the moderators get.
> 
> I started porting it to mailman, but we never got around to switch our
> public mailinglists from majordomo to mailman that wasn't finished
> either.
Nice!

The base of it looks fairly extensible, so I'll add mlmmj support to it
for my needs then :-).

--

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2 <at> gentoo.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie Brady | 17 Jul 2010 22:24
Picon
Picon

[BUG] Default search path used in require_resolvable_fromhost


http://bugs.contribs.org/show_bug.cgi?id=5808

 Jesper Knudsen      2010-03-01 01:29:10 MST 

When using the require_resolvable_fromhost plugin for qpsmtpd I noticed 
that mails from user <at> localhost.localdomain was actually getting through 
this filter. I finally found out that the plugin has a bug that causes it 
to insert default search path if it cannot find the domain. This means in 
my case that localhost.localdomain was then tried resolved as 
localhost.localdomain.swerts-knudsen.dk and since I have a wilcard CNAME 
was resolved as my public IP.

Since this plugin is only enabled for public interface the fix is to set 
the "dnsrch" flag when creating the Net::DNS object.

In require_resolvable_fromhost:
my $res = Net::DNS::Resolver->new (
                                   dnsrch => 0
                                   );
Permalink | Reply | 5 comments |
headers
Charlie Brady | 18 Jul 2010 00:17
Picon
Picon

rpm packaging bug - smtpd user created with shell not /bin/false


http://bugs.contribs.org/show_bug.cgi?id=6025

if ! id smtpd >/dev/null 2>&1
then
    # need to create smtpd user.
    if perl -e 'exit ! defined(getgrnam("postdrop"))'
    then
    # if postfix is installed, we will probably use
    # queue/postfix, which will need this:
        supp="-G postdrop"
    fi
    useradd -r -m $supp smtpd
fi

qpsmtpd needs a user "smtpd", but should not create a home directory or 
give access to a shell.
Permalink | Reply | 1 comment |
headers
Jared Johnson | 21 Jul 2010 14:54
Favicon

URIBL plugin and 'semicolon insertion munging'

Hi,

I'm working with Devon Carraway's URIBL plugin and have been testing its
effectiveness in finding URI's using 6 million lines or so of email
traffic from a day in the life of our mail servers.  My testing has shown
that the following line in the while ( $l = $transaction->body_getline )
loop within lookup_start is problematic:

        # Dodge inserted-semicolon munging
        $l =~ tr/;//d;

Unlike the other bits of "dodge this sort of munging" operations,
examining my test results and asking uncle google has not made it clear to
me what "inserted-semicolon munging" really is.  Can anyone shed light on
how semicolons could be used to obfuscate URIs so the URIBL plugin can't
detect them?  If I have an understanding of this, perhaps I can come up
with a safer alternative.  I'll paste some of the output of my test script
to demonstrate the effect of tr/;//d.  The 'Original result' is what we
find if we're using tr/;//d, the 'New result' is what we find without it.

<TD>&nbsp;<B>Required:</B><BR><BR><FONT size=2
face=Tahoma>&nbsp;.NET</FONT><BR><FONT size=2
face=Tahoma>&nbsp;Blah</FONT><BR><FONT size=2
face=Tahoma>&nbsp;Blah</FONT><BR></TD>
Results differ!
Original result: nbsp.net
New result:      no match

Wichita, KS 67204, USA &nbsp;&nbsp;www.somesite.com&nbsp;&nbsp; =
Results differ!
(Continue reading)

Permalink | Reply | 9 comments |
headers
Charlie Brady | 23 Jul 2010 04:29
Picon
Picon

tls plugin and SSL version


I've seen some reports that qpsmtp fails some PCI compliance testing 
because it can be accessed via SSLv2.

http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard

http://bugs.contribs.org/show_bug.cgi?id=6141

Here's a simple, and untested, patch - someone might care to do something 
more elaborate to allow choice of TLSv1 or SSLv3 (unfortunately 
IO::Socket::SSL doesn't seem to allow disable of just SSLv2).

--- qpsmtpd-0.83/plugins/tls.orig	2010-07-22 22:04:00.000000000 -0400
+++ qpsmtpd-0.83/plugins/tls	2010-07-22 22:09:35.000000000 -0400
 <at>  <at>  -80,6 +80,7  <at>  <at> 
     local $^W; # this bit is very noisy...
     my $ssl_ctx = IO::Socket::SSL::SSL_Context->new(
         SSL_use_cert => 1,
+        SSL_version => 'TLSv1',
         SSL_cert_file => $self->tls_cert,
         SSL_key_file => $self->tls_key,
         SSL_ca_file => $self->tls_ca,
 <at>  <at>  -176,6 +177,7  <at>  <at> 
         my $tlssocket = IO::Socket::SSL->new_from_fd(
             fileno(STDIN), '+>',
             SSL_use_cert => 1,
+            SSL_version => 'TLSv1',
             SSL_cert_file => $self->tls_cert,
             SSL_key_file => $self->tls_key,
             SSL_ca_file => $self->tls_ca,
(Continue reading)

Permalink | Reply | 6 comments |
headers
Nishikant Kapoor | 23 Jul 2010 16:20

550 Sorry, you are not allowed to send email to this server before solving a CAPTCHA.

I am trying to install autowhitelist_captcha Version 1.0 by Marc 
Sebastian Pelzer, and running into a problem. Hope someone can point me 
in the right direction.

When sender <at> senderDomain is sending me an email at mydomain, she is 
receiving back a "failure notice" : "550 Sorry, you are not allowed to 
send email to this server before solving a CAPTCHA. Please check your 
INBOX."

BUT, there is no CAPTCHA email sent to her!!!

I am runing qpsmtpd by Ask Bjoern Hansen, and checked that the patch 
discussed at http://www.mail-archive.com/qpsmtpd <at> perl.org/msg08219.html 
is already applied to it.

Here is the log:
...
28231 setting _config_cache for smtpgreeting to [Mail - Welcome to 
Qmail] from get_qmail_config and returning it
...
28231 dispatching EHLO localhost.localdomain
...
28231 dispatching MAIL 
FROM:<autowhitelist_captcha_a67d7338e329fe16cc3464077efcb62e <at> senderDomain.com>
28231 full from_parameter: 
FROM:<autowhitelist_captcha_a67d7338e329fe16cc3464077efcb62e <at> senderDomain.com>
28231 from email address : 
[<autowhitelist_captcha_a67d7338e329fe16cc3464077efcb62e <at> senderDomain.com>]
28231 running plugin (mail): autowhitelist_captcha
readline() on closed filehandle BLACKLIST at
(Continue reading)

Permalink | Reply | 0 comments |
headers
Devin Carraway | 23 Jul 2010 20:25

Re: URIBL plugin and 'semicolon insertion munging'

On Wed, Jul 21, 2010 at 07:54:30AM -0500, Jared Johnson wrote:
> Unlike the other bits of "dodge this sort of munging" operations,
> examining my test results and asking uncle google has not made it clear to
> me what "inserted-semicolon munging" really is.  Can anyone shed light on

My memory of this is fuzzy, but my SVN log indicates it was an attempt to deal
with a style of munging that exploited different browser behavior on
encountering semicolons in the hostname component of URLs.  At the time, the
form I was considering was "http://domain;.com/".  Under firefox, the
semicolon is taken to mean the end of the hostname and the start of the path,
thus triggering the implied-.com behavior and ending up at
"http://domain.com/;.com/".  I forget what IE does/did, but given the IE/FF
market share balance in 2005 when I added that feature, it was probably
similar.

In fact the problem is a lot more complex, because the five major browsers out
there all deal differently with deviations from the norm in URLs, and spammers
exploit those deviations to mislead parsers.  For the case I had in mind,
stripping semicolons out would be the right thing, but will be misled by the
munge pattern "http://domain.com;.com/foo".  The uribl plugin deals with a lot
of the munging tricks that were common back when it was written, but it's
probably not comprehensive today and it's definitely suceptible to picking up
bogus hostnames (e.g. the "nbsp;.net" behavior you note) based on what's left
after the known munging tricks are unwound.

http://code.google.com/p/browsersec/wiki/Part1#Uniform_Resource_Locators has a
summary of some of the deviations, although it doesn't address this specific
one.

--

--
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jared Johnson | 24 Jul 2010 00:18
Favicon

Re: URIBL plugin and 'semicolon insertion munging'

Ah, I tried it in my own FF and the trick still works :)  It seems like
all you have to do to get around the &nbsp; etc. problem is to wait a
little longer before applying the fixup -- allow the semicolon to match in
the hostname search and then strip it out.  Attached a patch, untested
(though the same change is tested on my now-greatly-forked uribl
plugin)... I'm sad to say I haven't been on github for a while so it may
be an age before i get around to submitting a patch according to the
standards, but if anybody else is interested in picking it up here it is
:)

Also, was it intended that the URI finding sub should find RHS hostnames
in email addresses as well?  I'm pretty sure it does... although again,
the testing I'm doing is no longer on the official code.  It seems
undesirable to me, I'm currently working on avoiding such hits while still
getting things like http://citibank.com:fooooooo <at> phishingsite.com

I got approval from my boss yesterday to submit my updates to the plugin
to the ML, btw, which I'll do when it's a bit closer to finished, probably
the beginning of next week.  It's a huge change though, and notably adds
dependancies on MIME::Parser and Net::DNS::Async and completely changes
the config file format.  I don't really have approval to spend hours
creating digestible individual patches... but posting the whole plugin is
better than not posting any code, right? :)

-Jared

> On Wed, Jul 21, 2010 at 07:54:30AM -0500, Jared Johnson wrote:
>> Unlike the other bits of "dodge this sort of munging" operations,
>> examining my test results and asking uncle google has not made it clear
>> to
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jared Johnson | 24 Jul 2010 01:57
Favicon

Re: URIBL plugin and 'semicolon insertion munging'

> It seems like
> all you have to do to get around the &nbsp; etc. problem is to wait a
> little longer before applying the fixup -- allow the semicolon to match in
> the hostname search and then strip it out.

My bad.. I guess the plugin currently only fixes up '&#\d\d\d' encoding,
not &nbsp; etc.  maybe i'll work on that...

-Jared
Permalink | Reply | 4 comments |

Gmane