New free blacklist: BRBL - Barracuda Reputation Block List

[Jeff Chan]

[Pardon the spam; thought this new blacklist might be worth at
least trying.]

Apparently Barracuda will be publishing a free-to-use sender
blacklist called BRBL:

http://www.barracudacentral.org/rbl

Haven't tried it myself but thought it may be of interest.

Cheers,

Jeff C.
--
Jeff Chan
mailto:***@surbl.org
http://www.surbl.org/

[Andy Sutton]

On Sat, 2008-09-20 at 23:51 -0700, Jeff Chan wrote:
> Haven't tried it myself but thought it may be of interest.

I wonder if it will include the barracuda devices that are set to
backscatter?
--
-Andy

Philosophy is a battle against the bewitchment
of our intelligence by means of language.
- Ludwig Wittgenstein

[Len Conrad]

We're trying it today.

For the same period of about 4.5 hours, zen had about 110 hits, while b.barracuda had about 165.

Len


______________________________________________
IMGate OpenSource Mail Firewall www.IMGate.net

[Sahil Tandon]

Len Conrad <***@Go2France.com> wrote:

> For the same period of about 4.5 hours, zen had about 110 hits, while
> b.barracuda had about 165.

What about overlap? Were the barracuda hits only those that skipped by
zen? Thanks.

--
Sahil Tandon <***@tandon.net>

[Len Conrad]

>> For the same period of about 4.5 hours, zen had about 110 hits, while
>> b.barracuda had about 165.
>
>What about overlap? Were the barracuda hits only those that skipped by
>zen? Thanks.

for the same period, zen = 153 hits, barracuda = 226 hits

when I comm the two sorted files, zen and barra, of hit IPs, no IPs are common.

I didn't believe this, so I wrote a script that looped over one file and grepped for its IPs in the other file, and vice versa. :) Same result.

I find it hard to believe. Even for such a small sample, 0% overlap? If barracuda is as accurate as zen, great.

Len



______________________________________________
IMGate OpenSource Mail Firewall www.IMGate.net

[mouss]

Len Conrad wrote:
>>> For the same period of about 4.5 hours, zen had about 110 hits, while
>>> b.barracuda had about 165.
>> What about overlap? Were the barracuda hits only those that skipped by
>> zen? Thanks.
>
> for the same period, zen = 153 hits, barracuda = 226 hits
>
> when I comm the two sorted files, zen and barra, of hit IPs, no IPs are common.
>
> I didn't believe this, so I wrote a script that looped over one file and grepped for its IPs in the other file, and vice versa. :) Same result.
>
> I find it hard to believe. Even for such a small sample, 0% overlap? If barracuda is as accurate as zen, great.
>


do these numbers take into account zen blocking at smtp level (on your
server or before)?

[Matus UHLAR - fantomas]

> >> For the same period of about 4.5 hours, zen had about 110 hits, while
> >> b.barracuda had about 165.
> >
> >What about overlap? Were the barracuda hits only those that skipped by
> >zen? Thanks.

On 21.09.08 21:14, Len Conrad wrote:
> for the same period, zen = 153 hits, barracuda = 226 hits

There's no problem in creating blacklist that will have 100% hitrate :)

The problem is in false positives - you won't get any mail with it

--
Matus UHLAR - fantomas, ***@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse

[Chris Russell]

> The problem is in false positives - you won't get any mail with it

I've had servers listed on Barracuda before, despite 17 emails to their
support systems we never had any response, and had to change a customers
mail architecture to compensate.

Very wary of them ..

Chris

[SM]

At 03:24 22-09-2008, Chris Russell wrote:
> I've had servers listed on Barracuda before, despite 17 emails to their
>support systems we never had any response, and had to change a customers
>mail architecture to compensate.

It's a free blacklist. People will use it until they get listed and
find out that there is no way to get unlisted as the blacklist is
said to be accurate or there's no delisting policy.

This new free blacklist has not published its listing methodology
yet. There is a removal request link. I'll wait for someone to get
listed to find out whether that actually works.

Regards,
-sm

[Justin Mason]

SM writes:
> At 03:24 22-09-2008, Chris Russell wrote:
> > I've had servers listed on Barracuda before, despite 17 emails to their
> >support systems we never had any response, and had to change a customers
> >mail architecture to compensate.
>
> It's a free blacklist. People will use it until they get listed and
> find out that there is no way to get unlisted as the blacklist is
> said to be accurate or there's no delisting policy.
>
> This new free blacklist has not published its listing methodology
> yet. There is a removal request link. I'll wait for someone to get
> listed to find out whether that actually works.

The fact that there's a prominent removal-request link is a good
sign, in my opinion ;) Let's see how it goes.

--j.

[Ralf Hildebrandt]

* Justin Mason <***@jmason.org>:

> The fact that there's a prominent removal-request link is a good
> sign, in my opinion ;) Let's see how it goes.

My top rejections for today are:

% fgrep www.barracudanetworks.com/reputation /var/log/mail.log |
awk '{print $10}' | sort |uniq -c | sort -n | tail

18 mx35.ispgateway.de[80.67.29.41]:
x 18 unknown[203.210.244.169]:
x 18 unknown[62.64.92.218]:
x 18 unknown[77.222.138.14]:
x 19 unknown[194.186.250.230]:
21 mx20.ispgateway.de[80.67.18.53]:
21 mx43.ispgateway.de[80.67.29.52]:
x 22 unknown[222.124.11.83]:
24 mx31.ispgateway.de[80.67.29.35]:
x 28 smtp-out.orange.net[193.252.22.118]:

The hosts marked x can be found in other RBLs (I used openrbl.org to
check).

--
Ralf Hildebrandt (i.A. des GB IT) ***@charite.de
Charite - Universitätsmedizin Berlin Tel. [phone]
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. [phone]
Geschäftsbereich IT Standort CBF I'm looking for a job!

[Joseph Brennan]

> My top rejections for today are:
>
> % fgrep www.barracudanetworks.com/reputation /var/log/mail.log |
> awk '{print $10}' | sort |uniq -c | sort -n | tail
>
> 18 mx35.ispgateway.de[80.67.29.41]:
. . .
> 21 mx20.ispgateway.de[80.67.18.53]:
> 21 mx43.ispgateway.de[80.67.29.52]:
. . .
> 24 mx31.ispgateway.de[80.67.29.35]:


We see those too. Hosts in this domain are sending mail FROM:<>
to recipients that do not exist, subject "Mail delivery failed:
returning message to sender".

It's ironic for Barracuda to blacklist hosts for backscatter.

Joseph Brennan
Columbia University Information Technology

[Ralf Hildebrandt]

* Joseph Brennan <***@columbia.edu>:
>
>
>> My top rejections for today are:
>>
>> % fgrep www.barracudanetworks.com/reputation /var/log/mail.log |
>> awk '{print $10}' | sort |uniq -c | sort -n | tail
>>
>> 18 mx35.ispgateway.de[80.67.29.41]:
> . . .
>> 21 mx20.ispgateway.de[80.67.18.53]:
>> 21 mx43.ispgateway.de[80.67.29.52]:
> . . .
>> 24 mx31.ispgateway.de[80.67.29.35]:
>
>
> We see those too. Hosts in this domain are sending mail FROM:<>
> to recipients that do not exist, subject "Mail delivery failed:
> returning message to sender".

They send mail with fake senders to fake recipients here. So, that's
another point.

--
Ralf Hildebrandt (i.A. des GB IT) ***@charite.de
Charite - Universitätsmedizin Berlin Tel. [phone]
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. [phone]
Geschäftsbereich IT Standort CBF I'm looking for a job!

[Joseph Brennan]

Ralf Hildebrandt <***@charite.de> wrote:

My top rejections for today are:


x 28 smtp-out.orange.net[193.252.22.118]:



Orange is a major ISP. Their mail-sending hosts are in 193.252.22 and
80.12.242. Mail from Orange runs about 85 to 90% spam here. The
minority remaining are legit users, some sending from cell phones.
Mail to abuse or postmaster is not answered.

http://openrbl.org/client/#193.252.22.118 shows it blacklisted only
on lists I'm not familiar with. Blocking it will block legit mail,
if people in Europe send mail to your system.

Joseph Brennan
Columbia University Information Technology

[mouss]

Joseph Brennan wrote:
>
> Ralf Hildebrandt <***@charite.de> wrote:
>
> My top rejections for today are:
>
>
> x 28 smtp-out.orange.net[193.252.22.118]:
>
>
>
> Orange is a major ISP. Their mail-sending hosts are in 193.252.22 and
> 80.12.242. Mail from Orange runs about 85 to 90% spam here. The
> minority remaining are legit users, some sending from cell phones.
> Mail to abuse or postmaster is not answered.
>
> http://openrbl.org/client/#193.252.22.118 shows it blacklisted only
> on lists I'm not familiar with. Blocking it will block legit mail,
> if people in Europe send mail to your system.
>

orange have become a lot better than they were. since they started
blocking port 25, I no more need to block their "residential" users.
while I still get junk via their relay, it's less than before. not as we
would like, but let's see. (their postmaster address is still a Dave
Null...).

[Michael Scheidell]

>> The problem is in false positives - you won't get any mail with it
>
> I've had servers listed on Barracuda before, despite 17 emails to their
> support systems we never had any response, and had to change a customers
> mail architecture to compensate.
>
> Very wary of them ..
>
> Chris
>
SOUNDS LIKE MY FREE BLACKLIST: blocked.secnap.net (google for it), lists
all ipv4 addresses in the world.
(and for some reason, one of the perl maintainers used it)

--
Michael Scheidell, CTO
>|SECNAP Network Security
Winner 2008 Network Products Guide Hot Companies
FreeBSD SpamAssassin Ports maintainer


_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com
_________________________________________________________________________

[Ralf Hildebrandt]

* Michael Scheidell <***@secnap.net>:

> SOUNDS LIKE MY FREE BLACKLIST: blocked.secnap.net (google for it), lists
> all ipv4 addresses in the world.
> (and for some reason, one of the perl maintainers used it)

Finally. No. More. Spam.

--
Ralf Hildebrandt (i.A. des GB IT) ***@charite.de
Charite - Universitätsmedizin Berlin Tel. [phone]
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. [phone]
Geschäftsbereich IT Standort CBF I'm looking for a job!

[Michael Scheidell]

> * Michael Scheidell <***@secnap.net>:
>
>> SOUNDS LIKE MY FREE BLACKLIST: blocked.secnap.net (google for it), lists
>> all ipv4 addresses in the world.
>> (and for some reason, one of the perl maintainers used it)
>
> Finally. No. More. Spam.

Now lets see how many idiots start using it.

For the next 6 months, I will get 'legal department' phone calls demanding I
remove them from our blacklist. I send the a zone transfer, ask them to
identify their netblock and never hear from them again.


--
Michael Scheidell, CTO
>|SECNAP Network Security
Winner 2008 Network Products Guide Hot Companies
FreeBSD SpamAssassin Ports maintainer


_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com
_________________________________________________________________________

[Ralf Hildebrandt]

* Michael Scheidell <***@secnap.net>:
> > * Michael Scheidell <***@secnap.net>:
> >
> >> SOUNDS LIKE MY FREE BLACKLIST: blocked.secnap.net (google for it), lists
> >> all ipv4 addresses in the world.
> >> (and for some reason, one of the perl maintainers used it)
> >
> > Finally. No. More. Spam.
>
> Now lets see how many idiots start using it.

:)

> For the next 6 months, I will get 'legal department' phone calls demanding I
> remove them from our blacklist. I send the a zone transfer, ask them to
> identify their netblock and never hear from them again.

Is this hypothetical or does this happen to you in real life?

--
Ralf Hildebrandt (i.A. des GB IT) ***@charite.de
Charite - Universitätsmedizin Berlin Tel. [phone]
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. [phone]
Geschäftsbereich IT Standort CBF I'm looking for a job!

[Michael Scheidell]

identify their netblock and never hear from them again.
>
> Is this hypothetical or does this happen to you in real life?

Real life. Some 'rbl testing' companies make money by monitoring rb's.
Some rbl testing software includes blocked.secnap.net
Seems to come in spurts. Won't hear from anyone for months and months, then
for about two months will start getting emails and calls 'you are blocking
my email'. And, yes, we get pretend lawyers call. I assume pretend because
I can't imagine any lawyer actually taking the time to call about something
so stupid:

host -t a 131.70.175.193.blocked.secnap.net
131.70.175.193.blocked.secnap.net has address 127.0.0.2

host -t txt 131.70.175.193.blocked.secnap.net
131.70.175.193.blocked.secnap.net descriptive text "Private list. secnap.com
use only Not licensed for public use. Anyone using this DNS zone as a
blacklist did not do their homework"


--
Michael Scheidell, CTO
>|SECNAP Network Security
Winner 2008 Network Products Guide Hot Companies
FreeBSD SpamAssassin Ports maintainer


_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com
_________________________________________________________________________

[support]

On Mon, 2008-09-22 at 11:24 +0100, Chris Russell wrote:
> > The problem is in false positives - you won't get any mail with it
>
> I've had servers listed on Barracuda before, despite 17 emails to their
> support systems we never had any response, and had to change a customers
> mail architecture to compensate.
>
> Very wary of them ..
>
> Chris
>
>
That would be because they were spamming then. Shame on you.

[Chris Russell]

> I've had servers listed on Barracuda before, despite 17 emails to
their
> support systems we never had any response, and had to change a
customers
> mail architecture to compensate.
>
> Very wary of them ..
>
> Chris
>
>
> That would be because they were spamming then. Shame on you.

Thats right, an opt-in website with email verification. Where the
"updates via email" is clearly signposted.

Being listed didn't bother me really, the fact that we had no response
from 17 requests to be delisted and their support refused to take our
call as we weren't a customer is the bit that annoyed me.

Cheers

Chris

[Daniel J McDonald]

On Sun, 2008-09-21 at 18:18 -0500, Len Conrad wrote:
> We're trying it today.
>
> For the same period of about 4.5 hours, zen had about 110 hits, while b.barracuda had about 165.

In about 26 hours I had 885 hits on b.barracuda, and 309 hits on the
various zen lists.

Zen had only 18 unique hits,

$ grep -c BRBL /var/log/mail/info
885
$ grep -c XBL /var/log/mail/info
270
$ grep -c -P BRBL.+XBL /var/log/mail/info
260
$ grep -c PBL /var/log/mail/info
4
$ grep -c -P BRBL.+PBL /var/log/mail/info
4
$ grep -c SBL /var/log/mail/info
35
$ grep -c -P BRBL.+SBL /var/log/mail/info
27

The numbers might be slightly worse for zen, since I had a couple of
multiple-zen hits:
$ grep -c -P BRBL.+[PSX]BL.+[PSX]BL /var/log/mail/info
3

I'm currently scoring it a 1.00, if it really is accurate I would like
to increase it.
--
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com

[Justin Piszcz]

On Mon, 22 Sep 2008, Daniel J McDonald wrote:

> On Sun, 2008-09-21 at 18:18 -0500, Len Conrad wrote:
>> We're trying it today.
>>
>> For the same period of about 4.5 hours, zen had about 110 hits, while b.barracuda had about 165.
>
> In about 26 hours I had 885 hits on b.barracuda, and 309 hits on the
> various zen lists.
>
> Zen had only 18 unique hits,
>
> $ grep -c BRBL /var/log/mail/info
> 885
> $ grep -c XBL /var/log/mail/info
> 270
> $ grep -c -P BRBL.+XBL /var/log/mail/info
> 260
> $ grep -c PBL /var/log/mail/info
> 4
> $ grep -c -P BRBL.+PBL /var/log/mail/info
> 4
> $ grep -c SBL /var/log/mail/info
> 35
> $ grep -c -P BRBL.+SBL /var/log/mail/info
> 27
>
> The numbers might be slightly worse for zen, since I had a couple of
> multiple-zen hits:
> $ grep -c -P BRBL.+[PSX]BL.+[PSX]BL /var/log/mail/info
> 3
>
> I'm currently scoring it a 1.00, if it really is accurate I would like
> to increase it.
> --
> Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
> Austin Energy
> http://www.austinenergy.com
>

Hmm I signed up for this 1-2 days ago but never got a confirmation e-mail
from them? What is the RBL name?

Justin.

[Daniel J McDonald]

On Mon, 2008-09-22 at 10:14 -0400, Justin Piszcz wrote:
>
> On Mon, 22 Sep 2008, Daniel J McDonald wrote:
>
> > On Sun, 2008-09-21 at 18:18 -0500, Len Conrad wrote:
> >> We're trying it today.
> >
>
> Hmm I signed up for this 1-2 days ago but never got a confirmation e-mail
> from them? What is the RBL name?

Here are the rules I'm using:
# URL: http://www.barracudacentral.org/rbl/
header __RCVD_IN_BRBL eval:check_rbl('brbl', 'b.barracudacentral.org')
describe __RCVD_IN_BRBL received via a relay in b.barracudacentral.org
header RCVD_IN_BRBL_RELAY eval:check_rbl_sub('brbl', '127.0.0.2')
tflags RCVD_IN_BRBL_RELAY net
describe RCVD_IN_BRBL_RELAY received via a relay rated as poor by Barracuda
score RCVD_IN_BRBL_RELAY 1.00


--
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com

[Henrik K]

On Mon, Sep 22, 2008 at 09:23:45AM -0500, Daniel J McDonald wrote:
> On Mon, 2008-09-22 at 10:14 -0400, Justin Piszcz wrote:
> >
> > On Mon, 22 Sep 2008, Daniel J McDonald wrote:
> >
> > > On Sun, 2008-09-21 at 18:18 -0500, Len Conrad wrote:
> > >> We're trying it today.
> > >
> >
> > Hmm I signed up for this 1-2 days ago but never got a confirmation e-mail
> > from them? What is the RBL name?
>
> Here are the rules I'm using:
> # URL: http://www.barracudacentral.org/rbl/
> header __RCVD_IN_BRBL eval:check_rbl('brbl', 'b.barracudacentral.org')
> describe __RCVD_IN_BRBL received via a relay in b.barracudacentral.org
> header RCVD_IN_BRBL_RELAY eval:check_rbl_sub('brbl', '127.0.0.2')
> tflags RCVD_IN_BRBL_RELAY net
> describe RCVD_IN_BRBL_RELAY received via a relay rated as poor by Barracuda
> score RCVD_IN_BRBL_RELAY 1.00

Note that this checks all Received headers, I'm seeing lots of FPs for
dynamic clients sending through ISP hosts etc. Try 'brbl-lastexternal' for
connecting clients only. If you keep on comparing hits, do tell which method
you are using.

[mouss]

Henrik K wrote:
> On Mon, Sep 22, 2008 at 09:23:45AM -0500, Daniel J McDonald wrote:
>> On Mon, 2008-09-22 at 10:14 -0400, Justin Piszcz wrote:
>>> On Mon, 22 Sep 2008, Daniel J McDonald wrote:
>>>
>>>> On Sun, 2008-09-21 at 18:18 -0500, Len Conrad wrote:
>>>>> We're trying it today.
>>> Hmm I signed up for this 1-2 days ago but never got a confirmation e-mail
>>> from them? What is the RBL name?
>> Here are the rules I'm using:
>> # URL: http://www.barracudacentral.org/rbl/
>> header __RCVD_IN_BRBL eval:check_rbl('brbl', 'b.barracudacentral.org')
>> describe __RCVD_IN_BRBL received via a relay in b.barracudacentral.org
>> header RCVD_IN_BRBL_RELAY eval:check_rbl_sub('brbl', '127.0.0.2')
>> tflags RCVD_IN_BRBL_RELAY net
>> describe RCVD_IN_BRBL_RELAY received via a relay rated as poor by Barracuda
>> score RCVD_IN_BRBL_RELAY 1.00
>
> Note that this checks all Received headers, I'm seeing lots of FPs for
> dynamic clients sending through ISP hosts etc. Try 'brbl-lastexternal' for
> connecting clients only. If you keep on comparing hits, do tell which method
> you are using.
>

I confirm tis. it seems like the brbl includes a "pbl" like list.

it's too bad Barracuda don't give nough infos and we have to dicover
this by ourselves...

[McDonald, Dan]

> Henrik K wrote:
> > On Mon, Sep 22, 2008 at 09:23:45AM -0500, Daniel J McDonald wrote:
> >> On Mon, 2008-09-22 at 10:14 -0400, Justin Piszcz wrote:
> >>> On Mon, 22 Sep 2008, Daniel J McDonald wrote:
> >>>
> >>>> On Sun, 2008-09-21 at 18:18 -0500, Len Conrad wrote:
> >>>>> We're trying it today.
> >>> Hmm I signed up for this 1-2 days ago but never got a confirmation e-mail
> >>> from them? What is the RBL name?
> >> Here are the rules I'm using:
> >> # URL: http://www.barracudacentral.org/rbl/
> >> header __RCVD_IN_BRBL eval:check_rbl('brbl', 'b.barracudacentral.org')
> >> describe __RCVD_IN_BRBL received via a relay in b.barracudacentral.org
> >> header RCVD_IN_BRBL_RELAY eval:check_rbl_sub('brbl', '127.0.0.2')
> >> tflags RCVD_IN_BRBL_RELAY net
> >> describe RCVD_IN_BRBL_RELAY received via a relay rated as poor by Barracuda
> >> score RCVD_IN_BRBL_RELAY 1.00
> >
> > Note that this checks all Received headers, I'm seeing lots of FPs for
> > dynamic clients sending through ISP hosts etc. Try 'brbl-lastexternal' for
> > connecting clients only. If you keep on comparing hits, do tell which method
> > you are using.

Ok, using -lastexternal for about 5 hours
$ grep -P '^Sep 22 1[34567]' /var/log/mail/info | grep -P [^M][SPX]BL | grep -c -v BRBL
55 # on Zen not on BRBL
$ grep -P '^Sep 22 1[34567]' /var/log/mail/info | grep -v -P [^M][SPX]BL | grep -c BRBL
352 # on BRBL not on Zen
$ grep -P '^Sep 22 1[34567]' /var/log/mail/info | grep -P [^M][SPX]BL | grep -c BRBL
122 # on both


--
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com

[Marc Perkel]

McDonald, Dan wrote:
>> Henrik K wrote:
>>
>>> On Mon, Sep 22, 2008 at 09:23:45AM -0500, Daniel J McDonald wrote:
>>>
>>>> On Mon, 2008-09-22 at 10:14 -0400, Justin Piszcz wrote:
>>>>
>>>>> On Mon, 22 Sep 2008, Daniel J McDonald wrote:
>>>>>
>>>>>
>>>>>> On Sun, 2008-09-21 at 18:18 -0500, Len Conrad wrote:
>>>>>>
>>>>>>> We're trying it today.
>>>>>>>
>>>>> Hmm I signed up for this 1-2 days ago but never got a confirmation e-mail
>>>>> from them? What is the RBL name?
>>>>>
>>>> Here are the rules I'm using:
>>>> # URL: http://www.barracudacentral.org/rbl/
>>>> header __RCVD_IN_BRBL eval:check_rbl('brbl', 'b.barracudacentral.org')
>>>> describe __RCVD_IN_BRBL received via a relay in b.barracudacentral.org
>>>> header RCVD_IN_BRBL_RELAY eval:check_rbl_sub('brbl', '127.0.0.2')
>>>> tflags RCVD_IN_BRBL_RELAY net
>>>> describe RCVD_IN_BRBL_RELAY received via a relay rated as poor by Barracuda
>>>> score RCVD_IN_BRBL_RELAY 1.00
>>>>
>>> Note that this checks all Received headers, I'm seeing lots of FPs for
>>> dynamic clients sending through ISP hosts etc. Try 'brbl-lastexternal' for
>>> connecting clients only. If you keep on comparing hits, do tell which method
>>> you are using.
>>>
>
> Ok, using -lastexternal for about 5 hours
> $ grep -P '^Sep 22 1[34567]' /var/log/mail/info | grep -P [^M][SPX]BL | grep -c -v BRBL
> 55 # on Zen not on BRBL
> $ grep -P '^Sep 22 1[34567]' /var/log/mail/info | grep -v -P [^M][SPX]BL | grep -c BRBL
> 352 # on BRBL not on Zen
> $ grep -P '^Sep 22 1[34567]' /var/log/mail/info | grep -P [^M][SPX]BL | grep -c BRBL
> 122 # on both
>
>
>

Hi Dan,

Can you throw my black list into the mix. I want to see how it scores.

hostkarma.junkemailfilter.com = 127.0.0.2 black
hostkarma.junkemailfilter.com = 127.0.0.1 white

[Rose, Bobby]

I had the same issue and found that the system that's relaying
(216.129.105.40) those confirmation emails doesn't have a PTR record.
You'd think someone selling a antispam/email appliance would be familiar
with the RFCs.

-----Original Message-----
From: Justin Piszcz [mailto:***@lucidpixels.com]
Sent: Monday, September 22, 2008 10:15 AM
To: Daniel J McDonald
Cc: ***@spamassassin.apache.org
Subject: Re: New free blacklist: BRBL - Barracuda Reputation Block List



On Mon, 22 Sep 2008, Daniel J McDonald wrote:



Hmm I signed up for this 1-2 days ago but never got a confirmation
e-mail
from them? What is the RBL name?

Justin.

[Ken A]

Rose, Bobby wrote:
> I had the same issue and found that the system that's relaying
> (216.129.105.40) those confirmation emails doesn't have a PTR record.
> You'd think someone selling a antispam/email appliance would be familiar
> with the RFCs.
>
> -----Original Message-----
> From: Justin Piszcz [mailto:***@lucidpixels.com]
> Sent: Monday, September 22, 2008 10:15 AM
> To: Daniel J McDonald
> Cc: ***@spamassassin.apache.org
> Subject: Re: New free blacklist: BRBL - Barracuda Reputation Block List
>
>
>
> On Mon, 22 Sep 2008, Daniel J McDonald wrote:
>
>
>
> Hmm I signed up for this 1-2 days ago but never got a confirmation
> e-mail
> from them? What is the RBL name?
>
> Justin.
>

It hit botnet rules here too, just now.
Ken


--
Ken Anderson
Pacific.Net

[Dave Koontz]

Rose, Bobby wrote ... (9/22/2008 10:24 AM):
> I had the same issue and found that the system that's relaying
> (216.129.105.40) those confirmation emails doesn't have a PTR record.
> You'd think someone selling a antispam/email appliance would be familiar
> with the RFCs.
>
That would explain why I got no confirmation, we do not accept email
from IP's without a PTR record.

I agree, if true this looks pretty bad for a so called antispam
company. I will check our logs when I return from vacation and verify
what you are seeing. Can anyone else confirm in the mean time?

[Duane Hill]

On Mon, 22 Sep 2008, Dave Koontz wrote:

> Rose, Bobby wrote ... (9/22/2008 10:24 AM):
>> I had the same issue and found that the system that's relaying
>> (216.129.105.40) those confirmation emails doesn't have a PTR record.
>> You'd think someone selling a antispam/email appliance would be familiar
>> with the RFCs.
>>
> That would explain why I got no confirmation, we do not accept email
> from IP's without a PTR record.
>
> I agree, if true this looks pretty bad for a so called antispam
> company. I will check our logs when I return from vacation and verify
> what you are seeing. Can anyone else confirm in the mean time?

Yep.

Sep 21 23:52:53 smtpgate postfix/smtpd[84422]: connect from unknown[216.129.105.40]:48748
Sep 21 23:52:53 smtpgate postfix/smtpd[84422]: NOQUEUE: reject: RCPT from unknown[216.129.105.40]:48748: 550 5.7.1 Client host rejected: cannot find your reverse hostname, [216.129.105.40]; from=<***@barracudacentral.org> to=<***@yournetplus.com> proto=ESMTP helo=<barracudacentral.org>
Sep 21 23:52:53 smtpgate postfix/smtpd[84422]: disconnect from unknown[216.129.105.40]:48748

-d

[Justin Mason]

Dave Koontz writes:
> Rose, Bobby wrote ... (9/22/2008 10:24 AM):
> > I had the same issue and found that the system that's relaying
> > (216.129.105.40) those confirmation emails doesn't have a PTR record.
> > You'd think someone selling a antispam/email appliance would be familiar
> > with the RFCs.
> >
> That would explain why I got no confirmation, we do not accept email
> from IP's without a PTR record.
>
> I agree, if true this looks pretty bad for a so called antispam
> company.

In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
legit email in general, going by the test results for our RDNS_NONE
rule... ;)

--j.

[Matt]

>> > I had the same issue and found that the system that's relaying
>> > (216.129.105.40) those confirmation emails doesn't have a PTR record.
>> > You'd think someone selling a antispam/email appliance would be familiar
>> > with the RFCs.
>> >
>> That would explain why I got no confirmation, we do not accept email
>> from IP's without a PTR record.
>>
>> I agree, if true this looks pretty bad for a so called antispam
>> company.
>
> In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
> legit email in general, going by the test results for our RDNS_NONE
> rule... ;)

Everyone should block/defer ALL email with no reverse DNS. Then maybe
those email admins would get a clue.

Matt

[Ralf Hildebrandt]

* Matt <***@gmail.com>:

> > In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
> > legit email in general, going by the test results for our RDNS_NONE
> > rule... ;)
>
> Everyone should block/defer ALL email with no reverse DNS. Then maybe
> those email admins would get a clue.

AOL.com does just that.

--
Ralf Hildebrandt (i.A. des GB IT) ***@charite.de
Charite - Universitätsmedizin Berlin Tel. [phone]
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. [phone]
Geschäftsbereich IT Standort CBF I'm looking for a job!

[Joseph Brennan]

>> Everyone should block/defer ALL email with no reverse DNS. Then maybe
>> those email admins would get a clue.
>
> AOL.com does just that.


No, they don't, really. They 'may' do that (see below). Try it.

Effective immediately: AOL
220- may no longer accept connections from IP addresses which
220 have no reverse-DNS (PTR record) assigned.



Joseph Brennan
Columbia University Information Technology

[Karl Pearson]

On Tue, 23 Sep 2008, Joseph Brennan wrote:

>
>>> Everyone should block/defer ALL email with no reverse DNS. Then maybe
>>> those email admins would get a clue.
>>
>> AOL.com does just that.
>
>
> No, they don't, really. They 'may' do that (see below). Try it.
>
> Effective immediately: AOL
> 220- may no longer accept connections from IP addresses which
> 220 have no reverse-DNS (PTR record) assigned.

As the administrator of a couple email servers, I have personal experience
with AOL's 'may no longer' 'policy'... Sometimes it worked, and sometimes
it didn't. Why didn't we have rDNS working? Because technically it's the
responsibility of your ISP and ours, at the time, didn't think they had to
do it because we were hosting our own webpages and they thought they were
only responsible when THEY hosted the pages. That's not true, and after a
dozen or so calls, I finally got to a person who believed me, and it was
fixed, finally...

Karl

>
>
>
> Joseph Brennan
> Columbia University Information Technology
>

---
_/ _/ _/ _/_/_/ ____________ __o
_/ _/ _/ _/ _/ ____________ _-\\<._
_/_/ _/ _/_/_/ (_)/ (_)
_/ _/ _/ _/ ......................
_/ _/ arl _/_/_/ _/ earson ***@ourldsfamily.com
---
http://consulting.ourldsfamily.com
---

[Dave Koontz]

Joseph Brennan wrote ... (9/23/2008 2:37 PM):
> No, they don't, really. They 'may' do that (see below). Try it.
>
> Effective immediately: AOL
> 220- may no longer accept connections from IP addresses which
> 220 have no reverse-DNS (PTR record) assigned.
According to AOL's Policy page, they say they WILL block connections
with no rDNS.
See http://postmaster.aol.com/guidelines/standards.html

* AOL's mail servers will reject connections from any IP address
that does not have reverse DNS (a PTR record).

[Chris Hoogendyk]

Matt wrote:
>>>> I had the same issue and found that the system that's relaying
>>>> (216.129.105.40) those confirmation emails doesn't have a PTR record.
>>>> You'd think someone selling a antispam/email appliance would be familiar
>>>> with the RFCs.
>>>>
>>>>
>>> That would explain why I got no confirmation, we do not accept email
>>> from IP's without a PTR record.
>>>
>>> I agree, if true this looks pretty bad for a so called antispam
>>> company.
>>>
>> In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
>> legit email in general, going by the test results for our RDNS_NONE
>> rule... ;)
>>
>
> Everyone should block/defer ALL email with no reverse DNS. Then maybe
> those email admins would get a clue.

Unfortunately, they won't (get a clue).

There are too many of them, and some are major players. For example, we
periodically have hassles with faculty and staff who have Verizon as
their ISP at home. Verizon will mess up its configurations so that our
server's paranoid settings start rejecting connections from our faculty
and staff when they are at home. We get no end of complaints. Then
Verizon will fix it. Then a few weeks later, it will be broken again.


--
---------------

Chris Hoogendyk

-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst

<***@bio.umass.edu>

---------------

Erdös 4

[SM]

At 08:58 22-09-2008, Matt wrote:
>Everyone should block/defer ALL email with no reverse DNS. Then maybe
>those email admins would get a clue.

Assuming you have signed up for that service, would you whitelist the
sending host or wait for the postmaster to get a clue?

Regards,
-sm

[Ralf Hildebrandt]

* SM <***@resistor.net>:
> At 08:58 22-09-2008, Matt wrote:
>> Everyone should block/defer ALL email with no reverse DNS. Then maybe
>> those email admins would get a clue.
>
> Assuming you have signed up for that service,

Service? Sign up? It's a simple setting in the MTA.

> would you whitelist the sending host or wait for the postmaster to get
> a clue?

I personally wait.

--
Ralf Hildebrandt (i.A. des GB IT) ***@charite.de
Charite - Universitätsmedizin Berlin Tel. [phone]
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. [phone]
Geschäftsbereich IT Standort CBF I'm looking for a job!

[mouss]

Matt wrote:
>>>> I had the same issue and found that the system that's relaying
>>>> (216.129.105.40) those confirmation emails doesn't have a PTR record.
>>>> You'd think someone selling a antispam/email appliance would be familiar
>>>> with the RFCs.
>>>>
>>> That would explain why I got no confirmation, we do not accept email
>>> from IP's without a PTR record.
>>>
>>> I agree, if true this looks pretty bad for a so called antispam
>>> company.
>> In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
>> legit email in general, going by the test results for our RDNS_NONE
>> rule... ;)
>
> Everyone should block/defer ALL email with no reverse DNS. Then maybe
> those email admins would get a clue.
>

when you say "they", you mean who? there are N new domains every day.
you think rejecting mail will affect the domains that will be created
tomorrow?

If everybody blocks such mail, then I'd say let's do it. but I don't
want to get an "everybody but you accepts our mail".

besides, this FcrDNS thing can hardly be applied to IPv6, which is
apparently the future...

or to say it in another way: yes, there is a problem, but the solution
is not in DNS.

[ram]

On Mon, 2008-09-22 at 10:58 -0500, Matt wrote:
> >> > I had the same issue and found that the system that's relaying
> >> > (216.129.105.40) those confirmation emails doesn't have a PTR record.
> >> > You'd think someone selling a antispam/email appliance would be familiar
> >> > with the RFCs.
> >> >
> >> That would explain why I got no confirmation, we do not accept email
> >> from IP's without a PTR record.
> >>
> >> I agree, if true this looks pretty bad for a so called antispam
> >> company.
> >
> > In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
> > legit email in general, going by the test results for our RDNS_NONE
> > rule... ;)
>
> Everyone should block/defer ALL email with no reverse DNS. Then maybe
> those email admins would get a clue.
>

We tried,
But when the client yells "I am losing my mails", you got to change
your rules

[Matt]

>> Everyone should block/defer ALL email with no reverse DNS. Then maybe
>> those email admins would get a clue.
>>
>
> We tried,
> But when the client yells "I am losing my mails", you got to change
> your rules

We had same experience as well. But I still think it should be done,
even though we do not do it.

Matt

[Benny Pedersen]

On Tue, September 23, 2008 09:00, ram wrote:
> On Mon, 2008-09-22 at 10:58 -0500, Matt wrote:
>> Everyone should block/defer ALL email with no reverse DNS. Then maybe
>> those email admins would get a clue.
> We tried, But when the client yells "I am losing my mails", you got to
> change your rules

or sender need to find a more less incompetent mailserver, most users are
clueless and it hurts them back !


--
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098

[Jesse Stroik]

Matt wrote:
>>>> I had the same issue and found that the system that's relaying
>>>> (216.129.105.40) those confirmation emails doesn't have a PTR record.
>>>> You'd think someone selling a antispam/email appliance would be familiar
>>>> with the RFCs.
>>>>
>>> That would explain why I got no confirmation, we do not accept email
>>> from IP's without a PTR record.
>>>
>>> I agree, if true this looks pretty bad for a so called antispam
>>> company.
>> In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
>> legit email in general, going by the test results for our RDNS_NONE
>> rule... ;)
>
> Everyone should block/defer ALL email with no reverse DNS. Then maybe
> those email admins would get a clue.


No, they shouldn't.

There are plenty of places still using mail gateways where the mail
server used for sending is still on an internal network, for a variety
of legitimate reasons, and those mail servers may resolve to a private
address. If you discard all mail with no appropriate reverse DNS,
you'll be discarding a lot of legitimate mail too from a lot of
legitimate mail configurations.

By discarding mail with no reverse DNS you are making assumptions about
SMTP that aren't necessarily true. There is only so much you can assume
about the protocol before you start breaking things. I don't have a
problem with saying that no reverse DNS means we should suspect this a
little more -- add a point or two -- but discarding mail because there
is no reverse DNS is broken behavior.

We are making many assumptions about how things /should/ be under SMTP
even though the RFC has no requirements for some of these things. When
you make assumptions like this, you have to be careful. Tossing mail
out because you don't like how another system is configured makes spam
filtering potentially more damaging to email than spam itself.

Best,
Jesse Stroik

[Kris Deugau]

Jesse Stroik wrote:
> There are plenty of places still using mail gateways where the mail
> server used for sending is still on an internal network, for a variety
> of legitimate reasons, and those mail servers may resolve to a private
> address. If you discard all mail with no appropriate reverse DNS,
> you'll be discarding a lot of legitimate mail too from a lot of
> legitimate mail configurations.

Um, no; the argument is for rejecting mail with **NO** rDNS at all.
Malformed or mismatched rDNS is still a nasty misconfiguration for a
number of reasons.

I can't think of ANY reasons (beyond sysadmin and/or ISP incompentence)
that a public IP originating legitimate SMTP traffic should not have a
reverse DNS entry. (Never mind a properly-formed one, a whole other
argument on its own.)

Unfortunately, as Justin Mason pointed out, there are a fair number of
systems out there that *don't* have any rDNS on their outbound SMTP
server IP(s). :( This makes it hard for anyone (particularly ISPs!) in
bigger than a private server owner and smaller than AOL to really try to
"enforce" this without seriously impacting legitimate traffic.

-kgd

[SM]

At 11:24 23-09-2008, Kris Deugau wrote:
>I can't think of ANY reasons (beyond sysadmin and/or ISP
>incompentence) that a public IP originating legitimate SMTP traffic
>should not have a reverse DNS entry. (Never mind a properly-formed
>one, a whole other argument on its own.)

There was a mailing list for a well-known open source project
originating legitimate SMTP traffic for a few days from a host
without reverse DNS. The reason was not sysadmin or ISP incompetence.

Regards,
-sm

[Kris Deugau]

SM wrote:
> At 11:24 23-09-2008, Kris Deugau wrote:
>> I can't think of ANY reasons (beyond sysadmin and/or ISP
>> incompentence) that a public IP originating legitimate SMTP traffic
>> should not have a reverse DNS entry. (Never mind a properly-formed
>> one, a whole other argument on its own.)
>
> There was a mailing list for a well-known open source project
> originating legitimate SMTP traffic for a few days from a host without
> reverse DNS. The reason was not sysadmin or ISP incompetence.

I probably should have qualified that with "for an extended period".

-kgd

[Jesse Stroik]

Kris Deugau wrote:
> Jesse Stroik wrote:
>> There are plenty of places still using mail gateways where the mail
>> server used for sending is still on an internal network, for a variety
>> of legitimate reasons, and those mail servers may resolve to a private
>> address. If you discard all mail with no appropriate reverse DNS,
>> you'll be discarding a lot of legitimate mail too from a lot of
>> legitimate mail configurations.
>
> Um, no; the argument is for rejecting mail with **NO** rDNS at all.
> Malformed or mismatched rDNS is still a nasty misconfiguration for a
> number of reasons.
>
> I can't think of ANY reasons (beyond sysadmin and/or ISP incompentence)
> that a public IP originating legitimate SMTP traffic should not have a
> reverse DNS entry. (Never mind a properly-formed one, a whole other
> argument on its own.)


In my experience, I've come across exchange servers in private networks
behind mail gateways that were the originating server. In this case,
whether or not you and I think it is a poor configuration, it is a
legitimate SMTP configuration via the RFC and it will have no
reverse-DNS entry for the originating server.

And that sort of thing requires impetus and resources to change, neither
of which you and I control for remote networks. Dropping mail because
the originating server has no reverse DNS record is making bad
assumptions about SMTP. And, as I've said, we have to be careful which
assumptions we make. The rDNS assumption is particularly tempting
because it is particularly effective but that doesn't make it a good
assumption.

Best,
Jesse

[Kris Deugau]

Jesse Stroik wrote:
> In my experience, I've come across exchange servers in private networks
> behind mail gateways that were the originating server. In this case,
> whether or not you and I think it is a poor configuration, it is a
> legitimate SMTP configuration via the RFC and it will have no
> reverse-DNS entry for the originating server.
^^^^^^^^^^^^^^^^^^^^^^^^^^
Quite possible, but the original argument, as I'll point out again, is
for rejecting mail with **NO** rDNS *at all*. This *is* a different
case than malformed or mismatched rDNS information.

Eg, "host <sending IP according to you mail server>" returns NXDOMAIN.

Try it with 209.91.179.65 - if the device on that IP were a NAT/firewall
(it isn't) with a device generating legitimate SMTP traffic behind it
somewhere, that IP should have rDNS (it doesn't right now - should
probably fix that anyway).

To be excessively pedantic even network and broadcast IPs should have
rDNS - IMO there's little excuse not to have *some* kind of rDNS on
every single IP delegated from ARIN, RIPE &c. ("We just got assigned a
new /20 and we haven't set them up yet" is one such valid excuse. <g>)

If it's contacting your mail server, it's either a local private
network, your ISP's network is sufficiently mismanaged as to allow
private-IP network traffic to reach public IP space, or there is a
publicly-routeable IP associated with that connection. I can't think of
any cases in which that public IP should NOT have *something* in rDNS -
whether it's valid, well-formed, properly closed-loop, or related in any
way to the SMTP traffic is another question.

(As an ISP mail administrator I see a lot of "ooh, that looks neat..
but..." ideas go across this list; most of them have enough potential
to cause customer phone calls that I don't look very far into the
details of implementing them. *sigh* My own personal machine receives
so little traffic I don't mind the cost of running SA - and in fact I
run it largely the way I do the systems at work to keep things simple.)

-kgd

[Jason Bertoch]

> -----Original Message-----
> From: Kris Deugau [mailto:***@vianet.ca]
> Sent: Tuesday, September 23, 2008 3:27 PM
> To: users
> Subject: Re: New free blacklist: BRBL - Barracuda Reputation Block List
>
> IMO there's little excuse not to have *some* kind of rDNS on
> every single IP delegated from ARIN, RIPE &c. ("We just got assigned a
> new /20 and we haven't set them up yet" is one such valid excuse. <g>)

I must disagree on this note. I look forward to the day when we can
confidently use the absence of rDNS to identify hosts not authorized to send
mail directly to external hosts. As a result of this belief, I do not
assign rDNS to any of my customers' IP's until they request one for mail
hosting or other legitimate reasons. My hope is that if any of my customers
get infected they will trigger Botnet or other rules that target the absence
of rDNS.

Jason A. Bertoch
Network Administrator
***@electronet.net
Electronet Broadband Communications
3411 Capital Medical Blvd.
Tallahassee, FL 32308
(V) 850.222.0229 (F) 850.222.8771

[mouss]

Jason Bertoch wrote:
>> -----Original Message-----
>> From: Kris Deugau [mailto:***@vianet.ca]
>> Sent: Tuesday, September 23, 2008 3:27 PM
>> To: users
>> Subject: Re: New free blacklist: BRBL - Barracuda Reputation Block List
>>
>> IMO there's little excuse not to have *some* kind of rDNS on
>> every single IP delegated from ARIN, RIPE &c. ("We just got assigned a
>> new /20 and we haven't set them up yet" is one such valid excuse. <g>)
>
> I must disagree on this note. I look forward to the day when we can
> confidently use the absence of rDNS to identify hosts not authorized to send
> mail directly to external hosts.

This is not going to happen.

> As a result of this belief, I do not
> assign rDNS to any of my customers' IP's until they request one for mail
> hosting or other legitimate reasons. My hope is that if any of my customers
> get infected they will trigger Botnet or other rules that target the absence
> of rDNS.
>

It is better to assign an easily distinguished rDNS. something like
4-3-2-1.user.example.com
so that people can simply block .user.example.com if they want (don't
use complex forms. make it easy to block a domain and its subdomains).

[u***@3.am]

Getting back to the subject...can anyone enlighten us to the efficacy of
this DNSBL? For example, how does it compare to zen.spamhaus.org, varius
DUL type lists, etc. I would love to reject more before SA gets involved.

James Smallacombe PlantageNet, Inc. CEO and Janitor
***@3.am http://3.am
=========================================================================

[McDonald, Dan]

On Tue, 2008-09-23 at 17:21 -0400, ***@3.am wrote:
> Getting back to the subject...can anyone enlighten us to the efficacy of
> this DNSBL? For example, how does it compare to zen.spamhaus.org,

It hits significantly more spam than zen.spamhaus.org

On my primary mx, today I had 94 mails that hit a zen list but not brbl,
591 that hit a zen list and brbl, and 8042 that hit brbl but not zen.

I am checking -lastexternal addresses only.

Looking through the 2400 or so domains that were marked as spam, I
didn't see any obvious false positives. Looking through the 631 domains
that did not have enough points to be classed as spam, I didn't see more
than one or two that shouldn't have been blocked. granted, i did not
look through the emails themselves, just the domain name.

I'm currently scoring it 1.0, and might raise it up to 2.0 in a couple
of days if nobody starts squawking....



--
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com

[RobertH]

\
> It hits significantly more spam than zen.spamhaus.org
>
> On my primary mx, today I had 94 mails that hit a zen list but not brbl,
> 591 that hit a zen list and brbl, and 8042 that hit brbl but not zen.
>
> I am checking -lastexternal addresses only.
>
> Looking through the 2400 or so domains that were marked as spam, I
> didn't see any obvious false positives. Looking through the 631 domains
> that did not have enough points to be classed as spam, I didn't see more
> than one or two that shouldn't have been blocked. granted, i did not
> look through the emails themselves, just the domain name.
>
> I'm currently scoring it 1.0, and might raise it up to 2.0 in a couple
> of days if nobody starts squawking....
> --
> Daniel J McDonald,

Would someone consider and post the final somewhat agreed upon rule(s) and
scoring that you are using please?

I saw one or two yet they were picked a bit by the list for scoring theory
and syntax.

I think not using last external was one of the reasons the others were not
recommended or used.

Thanks

- rh

[Jeremy]

"RobertH" <***@abbacomm.net> wrote in message news:***@msys1...
> \
>> It hits significantly more spam than zen.spamhaus.org
>>
>> On my primary mx, today I had 94 mails that hit a zen list but not brbl,
>> 591 that hit a zen list and brbl, and 8042 that hit brbl but not zen.
>>
>> I am checking -lastexternal addresses only.
>>
>> Looking through the 2400 or so domains that were marked as spam, I
>> didn't see any obvious false positives. Looking through the 631 domains
>> that did not have enough points to be classed as spam, I didn't see more
>> than one or two that shouldn't have been blocked. granted, i did not
>> look through the emails themselves, just the domain name.
>>
>> I'm currently scoring it 1.0, and might raise it up to 2.0 in a couple
>> of days if nobody starts squawking....
>> --
>> Daniel J McDonald,
>
> Would someone consider and post the final somewhat agreed upon rule(s) and
> scoring that you are using please?
>
> I saw one or two yet they were picked a bit by the list for scoring theory
> and syntax.
>
> I think not using last external was one of the reasons the others were not
> recommended or used.
>
> Thanks
>
> - rh
>

I'm using the following (be mindful of any line wrapping - there should be four lines below)...

header RCVD_IN_BRBL eval:check_rbl('brbl-lastexternal', 'b.barracudacentral.org.', '127.0.0.2')
describe RCVD_IN_BRBL Received via relay listed in Barracuda RBL
score RCVD_IN_BRBL 1.0
tflags RCVD_IN_BRBL net


Cheers,
Jeremy

[Dave Koontz]

Just an update. I contacted Barracuda and they have resolved their rDNS
issue. They also provided a link so that those that did not receive
their original confirmation emails can have it resent.


-------- Original Message --------
Subject: RE: BarracudaCentral Contact
Date: Tue, 23 Sep 2008 15:13:23 -0700
From: BCOrgInfo_Team


Hi Dave,

Thank you for contacting BarracudaCentral.org. We have resolved the
rDNS/PTR record issue.

Since you did not receive the initial confirmation email, you can
request a second email to be sent here:

http://www.barracudacentral.org/account/resend-vcode

Or if you’ve forgotten your password, you can also request that it be
resent here:

http://www.barracudacentral.org/account/login

If you have any additional questions, please feel free to contact us
again at ***@barracudacentral.org.

Thank you for signing up for the BRBL service! We do appreciate your
support.


Regards,
BarracudaCentral.org Team

[u***@3.am]

On Tue, 23 Sep 2008, McDonald, Dan wrote:

> On Tue, 2008-09-23 at 17:21 -0400, ***@3.am wrote:
>> Getting back to the subject...can anyone enlighten us to the efficacy of
>> this DNSBL? For example, how does it compare to zen.spamhaus.org,
>
> It hits significantly more spam than zen.spamhaus.org
>
> On my primary mx, today I had 94 mails that hit a zen list but not brbl,
> 591 that hit a zen list and brbl, and 8042 that hit brbl but not zen.
>
> I am checking -lastexternal addresses only.
>
> Looking through the 2400 or so domains that were marked as spam, I
> didn't see any obvious false positives. Looking through the 631 domains
> that did not have enough points to be classed as spam, I didn't see more
> than one or two that shouldn't have been blocked. granted, i did not
> look through the emails themselves, just the domain name.
>
> I'm currently scoring it 1.0, and might raise it up to 2.0 in a couple
> of days if nobody starts squawking....

I was actually hoping to use it like I use zen.spamhaus.org and
dul.sorbs.net and just reject emails listed on those. It is very rare
that I get a false positive from either, but their efficacy isn't what it
used to be, either. So, I just configured my tcpserver to invoke rblsmtpd
using b.barracudacentral.org as well as the other two, and after only a
few seconds, the difference was astounding. Here is perhaps 2 minutes
worth of stats:

$ grep -c sorbs bl_stats
9

$ grep -c spamh bl_stats
228

$ grep -c barracud bl_stats
1321

I thought maybe something was broken and it was rejecting everything, but
that doesn't appear to be the case.

However, it may take a day or more to find out of the false positive
ratio of this dnsbl is too high to use it like this.

Has anyone else done this? If so, what does the FP situation look like?

James Smallacombe PlantageNet, Inc. CEO and Janitor
***@3.am http://3.am
=========================================================================

[Aaron Wolfe]

On Wed, Sep 24, 2008 at 5:41 PM, <***@3.am> wrote:
> On Tue, 23 Sep 2008, McDonald, Dan wrote:
>
>> On Tue, 2008-09-23 at 17:21 -0400, ***@3.am wrote:
>>>
>>> Getting back to the subject...can anyone enlighten us to the efficacy of
>>> this DNSBL? For example, how does it compare to zen.spamhaus.org,
>>
>> It hits significantly more spam than zen.spamhaus.org
>>
>> On my primary mx, today I had 94 mails that hit a zen list but not brbl,
>> 591 that hit a zen list and brbl, and 8042 that hit brbl but not zen.
>>
>> I am checking -lastexternal addresses only.
>>
>> Looking through the 2400 or so domains that were marked as spam, I
>> didn't see any obvious false positives. Looking through the 631 domains
>> that did not have enough points to be classed as spam, I didn't see more
>> than one or two that shouldn't have been blocked. granted, i did not
>> look through the emails themselves, just the domain name.
>>
>> I'm currently scoring it 1.0, and might raise it up to 2.0 in a couple
>> of days if nobody starts squawking....
>
> I was actually hoping to use it like I use zen.spamhaus.org and
> dul.sorbs.net and just reject emails listed on those. It is very rare that
> I get a false positive from either, but their efficacy isn't what it used to
> be, either. So, I just configured my tcpserver to invoke rblsmtpd using
> b.barracudacentral.org as well as the other two, and after only a few
> seconds, the difference was astounding. Here is perhaps 2 minutes worth of
> stats:
>
> $ grep -c sorbs bl_stats
> 9
>
> $ grep -c spamh bl_stats
> 228
>
> $ grep -c barracud bl_stats
> 1321
>
> I thought maybe something was broken and it was rejecting everything, but
> that doesn't appear to be the case.
>
> However, it may take a day or more to find out of the false positive ratio
> of this dnsbl is too high to use it like this.
>
> Has anyone else done this? If so, what does the FP situation look like?

We've been testing here for over a week. The FP rate is very low but
higher than that of zen or invaluement (which have practically none).
I'd guess you might be able to use it as a blocklist depending on your
site and user's expectations.. If you want a "set it and forget it",
probably just add a decent score in SA.


>
> James Smallacombe PlantageNet, Inc. CEO and Janitor
> ***@3.am http://3.am
> =========================================================================
>

[u***@3.am]

On Wed, 24 Sep 2008, ***@3.am wrote:

> I was actually hoping to use it like I use zen.spamhaus.org and dul.sorbs.net
> and just reject emails listed on those. It is very rare that I get a false
> positive from either, but their efficacy isn't what it used to be, either.
> So, I just configured my tcpserver to invoke rblsmtpd using
> b.barracudacentral.org as well as the other two, and after only a few
> seconds, the difference was astounding. Here is perhaps 2 minutes worth of
> stats:
>
> $ grep -c sorbs bl_stats
> 9
>
> $ grep -c spamh bl_stats
> 228
>
> $ grep -c barracud bl_stats
> 1321

Replying to myself, after I sent this, it occurred to me that the query
order is a huge factor...rblsmtpd stops scanning after the first hit.
Here is what I got when I put zen in front of barracuda and ran it for
maybe 30 seconds:

$ grep -c barracud bl_stats2
22

$ grep -c spamh bl_stats2
355

$ grep -c sorbs bl_stats2
3

In other words, zen is probably actually more effective by itself than
barracudacentral. Nonetheless, it helps a lot.

James Smallacombe PlantageNet, Inc. CEO and Janitor
***@3.am http://3.am
=========================================================================

[mouss]

***@3.am wrote:
> On Wed, 24 Sep 2008, ***@3.am wrote:
>
>> I was actually hoping to use it like I use zen.spamhaus.org and
>> dul.sorbs.net and just reject emails listed on those. It is very rare
>> that I get a false positive from either, but their efficacy isn't what
>> it used to be, either. So, I just configured my tcpserver to invoke
>> rblsmtpd using b.barracudacentral.org as well as the other two, and
>> after only a few seconds, the difference was astounding. Here is
>> perhaps 2 minutes worth of stats:
>>
>> $ grep -c sorbs bl_stats
>> 9
>>
>> $ grep -c spamh bl_stats
>> 228
>>
>> $ grep -c barracud bl_stats
>> 1321
>
> Replying to myself, after I sent this, it occurred to me that the query
> order is a huge factor...rblsmtpd stops scanning after the first hit.
> Here is what I got when I put zen in front of barracuda and ran it for
> maybe 30 seconds:
>
> $ grep -c barracud bl_stats2
> 22
>
> $ grep -c spamh bl_stats2
> 355
>
> $ grep -c sorbs bl_stats2
> 3
>
> In other words, zen is probably actually more effective by itself than
> barracudacentral. Nonetheless, it helps a lot.
>

I see aproximately the same numbers, with a little more hits for zen (I
use a warn_if_reject for the BRBL). In percents (B & !Z)/(B+Z) ~= 10%,
and (Z & !B)/(B+Z) ~= 13%).

anyway,
- zen is widely used. so even if it has an FP, the originator will have
problems sending to a lot of places, and has enough incentives to get
delisted. In other words, the FPs caused by zen are "passed to the
originator" and are no more "our FPs"! (I hope you see what I mean).
- we don't have enough infos (yet?) about BRBL.

[Rasmus Haslund]

>anyway,
>- zen is widely used. so even if it has an FP, the originator will have
problems sending to >a lot of places, and has enough incentives to get
delisted. In other words, the FPs caused by zen are "passed to the
originator" and are no more "our FPs"! (I hope you see what I mean).
> - we don't have enough infos (yet?) about BRBL.

I don't really agree about your statement about our FPs turning into the
originators FPs.
We do business all over the world and I see a lot of fp's on Zen. Most
of the companies we deal with that are fp's on Zen have no IT people
working there and hence they have NO idea what to do about it - could
even be in a 3rd world country.

Usually I will let them know as best I can what happened and request
they contact their ISP. In the end of the day we end up manually
whitelisting these - hence it is still our FP's.

Best Regards
NOWACO A/S
Rasmus Haslund

[mouss]

Rasmus Haslund wrote:
>> anyway,
>> - zen is widely used. so even if it has an FP, the originator will have
> problems sending to >a lot of places, and has enough incentives to get
> delisted. In other words, the FPs caused by zen are "passed to the
> originator" and are no more "our FPs"! (I hope you see what I mean).
>> - we don't have enough infos (yet?) about BRBL.
>
> I don't really agree about your statement about our FPs turning into the
> originators FPs.

Your mail, your policies, your rules.


> We do business all over the world and I see a lot of fp's on Zen.

in which sublist? xbl, sbl or pbl? and when you say "a lot", how many?
can you show an example of an IP that you consider as an FP?

> Most
> of the companies we deal with that are fp's on Zen have no IT people
> working there and hence they have NO idea what to do about it - could
> even be in a 3rd world country.
>
> Usually I will let them know as best I can what happened and request
> they contact their ISP. In the end of the day we end up manually
> whitelisting these - hence it is still our FP's.

[James Wilkinson]

mouss wrote:
> in which sublist? xbl, sbl or pbl? and when you say "a lot", how many?
> can you show an example of an IP that you consider as an FP?

Well, since you asked…

I’m not the Original Poster, but I consider most of
http://www.spamhaus.org/sbl/sbl.lasso?query=SBL60174 to be a FP *when
used with SpamAssassin rules*.

This is a /19 range of VSNL dynamic addresses, which had (correctly)
been put on the PBL. I understand that many smaller Indian companies can
only get a dynamic IP, want to run an internal mail server (often
Exchange), and forget to relay outgoing e-mail through an appropriate
external mailserver.

At least one VSNL customer ran into trouble sending e-mail due to the
PBL listing, and rather than using a suitable relay, systematically (and
repeatedly) removed the entire /19 from the PBL! Spamhaus then stuck the
whole range into the SBL.

This is fine when the SBL is merely used against the last external
relay, but SpamAssassin will test *all* IP addresses in the headers
against the SBL. So non-spamming Indian companies get hit even if they
relay through a good mailserver.

I consider it a stretch putting this range under the SBL: the “Policy &
Listing Criteria” says that the range “appear[s] to Spamhaus to be under
the control of, or made available for the use of, senders of Unsolicited
Bulk Email (“spammers”).” This doesn’t seem to be the reason in this
case: there doesn’t seem to be any evidence that the individuals who
removed the range from the PBL intended to send unsolicited bulk e-mail.
It’s abuse of the Spamhaus web site, not directly abuse of e-mail, and
would better be handled by a PBL range which can’t be edited through the
website.

I wrote to Spamhaus querying the listing, but have heard nothing
(probably not surprisingly, since I’m not VSNL. Thank goodness!) I
haven’t raised a SpamAssassin bug, since I don’t think it *is* a
SpamAssassin bug.

James.

--
E-mail: james@ | 'Short for "Sic Transit Gloria Humanorum", which is Latin
aprilcottage.co.uk | for "There goes the neighbourhood!"'
| -- Menno Willemse

[Michael Hutchinson]

Hello All,

There were so many messages regarding this new Block List, I have to
admit I have not read them all. I get the general idea that this new
Barracuda Reputation Block List isn't all that hot.

For instance, how do Barracuda generate their Block List? I don't think
this has been answered yet, and I doubt it is the same method(s) as
Spamcop or Spamhaus, as there appears to be a lot more hits on Spam with
the Barracuda RBL enabled. This suggests to me that False Positives are
going to be numerously present.

I've also read that the Barracuda's NetApp's score hard on Backscatter,
but yet are a source of Backscatter themselves - I hear a ball of twine
unravelling here.. enough that would stop me even trying the new RBL -
Especially with the recent de-listing saga, I've been put right off.
Anyone with good news about the Barracuda RBL to combat that?

2cents.
Cheers,
Mike

[Justin Mason]

Michael Hutchinson writes:
> Hello All,
>
> There were so many messages regarding this new Block List, I have to
> admit I have not read them all. I get the general idea that this new
> Barracuda Reputation Block List isn't all that hot.

You should read them all, then ;)

--j.

[Jason Bertoch]

> -----Original Message-----
> From: Michael Hutchinson [mailto:***@manux.co.nz]
> Sent: Monday, September 29, 2008 5:53 PM
> To: ***@spamassassin.apache.org
> Subject: RE: New free blacklist: BRBL - Barracuda Reputation Block List
>
> For instance, how do Barracuda generate their Block List? I don't think
> this has been answered yet, and I doubt it is the same method(s) as
> Spamcop or Spamhaus, as there appears to be a lot more hits on Spam
> with the Barracuda RBL enabled. This suggests to me that False Positives >
> are going to be numerously present.
>
> I've also read that the Barracuda's NetApp's score hard on Backscatter,
> but yet are a source of Backscatter themselves - I hear a ball of twine
> unravelling here.. enough that would stop me even trying the new RBL -
> Especially with the recent de-listing saga, I've been put right off.
> Anyone with good news about the Barracuda RBL to combat that?
>

I'd like answers to many of the same questions, although I've already
implemented the list. So far, I've only had one complaint though it wasn't
much of a false positive. I'd started receiving junk from a legitimate
server that normally sent ham. The server was blocked long enough for me to
get one call. Several hours later, it was removed and was no longer spewing
spam.

Since using this list as an RBL, I've noticed the number of messages
processed by SA has dropped a minimum of 30%. I've never been a fan of
Barracuda's appliance, but I'm keeping the list.


Jason A. Bertoch
Network Administrator
***@electronet.net
Electronet Broadband Communications
3411 Capital Medical Blvd.
Tallahassee, FL 32308
(V) 850.222.0229 (F) 850.222.8771

[Rasmus Haslund]

> -----Original Message-----
> From: Jason Bertoch [mailto:***@electronet.net]
> Sent: 30. september 2008 15:01
> To: ***@spamassassin.apache.org
> Subject: RE: New free blacklist: BRBL - Barracuda Reputation
> Block List

> I'd like answers to many of the same questions, although I've
> already implemented the list. So far, I've only had one
> complaint though it wasn't much of a false positive. I'd
> started receiving junk from a legitimate server that normally
> sent ham. The server was blocked long enough for me to get
> one call. Several hours later, it was removed and was no
> longer spewing spam.

For us, the only FP we have seen are some servers in Argentina, Brazil
and 2 legit fish newsletters from Russia.
Otherwise it is looking very good here.

Best regards,
NOWACO A/S
Rasmus Haslund

[Justin Mason]

Jason Bertoch writes:
> > -----Original Message-----
> > From: Michael Hutchinson [mailto:***@manux.co.nz]
> > Sent: Monday, September 29, 2008 5:53 PM
> > To: ***@spamassassin.apache.org
> > Subject: RE: New free blacklist: BRBL - Barracuda Reputation Block List
> >
> > For instance, how do Barracuda generate their Block List? I don't think
> > this has been answered yet, and I doubt it is the same method(s) as
> > Spamcop or Spamhaus, as there appears to be a lot more hits on Spam
> > with the Barracuda RBL enabled. This suggests to me that False Positives >
> > are going to be numerously present.
> >
> > I've also read that the Barracuda's NetApp's score hard on Backscatter,
> > but yet are a source of Backscatter themselves - I hear a ball of twine
> > unravelling here.. enough that would stop me even trying the new RBL -
> > Especially with the recent de-listing saga, I've been put right off.
> > Anyone with good news about the Barracuda RBL to combat that?
> >
>
> I'd like answers to many of the same questions, although I've already
> implemented the list. So far, I've only had one complaint though it wasn't
> much of a false positive. I'd started receiving junk from a legitimate
> server that normally sent ham. The server was blocked long enough for me to
> get one call. Several hours later, it was removed and was no longer spewing
> spam.

Well, for what it's worth, in our testing it appears to be very reliable,
with few FPs and a good hit-rate. All its hits on my ham corpus have
proven to be misfiled spams. It looks very promising as a new
SpamAssassin rule so far...

--j.

[mouss]

Jesse Stroik wrote:
> Kris Deugau wrote:
>> Jesse Stroik wrote:
>>> There are plenty of places still using mail gateways where the mail
>>> server used for sending is still on an internal network, for a
>>> variety of legitimate reasons, and those mail servers may resolve to
>>> a private address. If you discard all mail with no appropriate
>>> reverse DNS, you'll be discarding a lot of legitimate mail too from a
>>> lot of legitimate mail configurations.
>>
>> Um, no; the argument is for rejecting mail with **NO** rDNS at all.
>> Malformed or mismatched rDNS is still a nasty misconfiguration for a
>> number of reasons.
>>
>> I can't think of ANY reasons (beyond sysadmin and/or ISP
>> incompentence) that a public IP originating legitimate SMTP traffic
>> should not have a reverse DNS entry. (Never mind a properly-formed
>> one, a whole other argument on its own.)
>
>
> In my experience, I've come across exchange servers in private networks
> behind mail gateways that were the originating server. In this case,
> whether or not you and I think it is a poor configuration, it is a
> legitimate SMTP configuration via the RFC and it will have no
> reverse-DNS entry for the originating server.

we don't really care about private networks. the connection comes from a
public IP (with or without NAT) and it is considered good practice to
have a PTR record for every IP. RFC 1912 (section 2.1) states
"
Every Internet-reachable host should have a name. The consequences
of this are becoming more and more obvious. Many services available
on the Internet will not talk to you if you aren't correctly
registered in the DNS.
"

yes, this is an informational RFC, but many people believe that this
should be followed.


Anyway, some ISPs in some countries do not set a PTR for their networks,
so blocking on absence of PTR may cause FPs as Justin said. but if you
don't get legitimate mail from such places, you can reject.

>
> And that sort of thing requires impetus and resources to change, neither
> of which you and I control for remote networks. Dropping mail because
> the originating server has no reverse DNS record is making bad
> assumptions about SMTP.

It is not restricted to SMTP. for example, gandi.net whois server
doesn't accept connections for IPs without rDNS.

> And, as I've said, we have to be careful which
> assumptions we make. The rDNS assumption is particularly tempting
> because it is particularly effective but that doesn't make it a good
> assumption.
>
> Best,
> Jesse

[Dave Koontz]

Justin Mason wrote ... (9/22/2008 11:29 AM):
> In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
> legit email in general, going by the test results for our RDNS_NONE
> rule... ;)
>
> --j.
>

Thanks for that stat Justin. I was always curious what others were
seeing here. As you know, many major ISP's like AOL have similar
policies to not accept email from IP's with no PTR record. For us, it
blocks well over 50% of spam right out of the gate, with very little to
no false positives. (nowhere close to 1/10th a percent, much less the 3+
percent you cite). We have more issues with RBL and URIBL issues than
no PRT records... those they too are extremely minimal.

That said, you would think a company making their living selling
antispam software/devices would understand the importance of rDNS
records and other RFC rules.

It would appear once you sign up and their email is blocked, you can not
edit your own site information nor ask for another confirmation email.
I have sent the following message on to Barracuda: I filled in their
support form, and got an email back asking to respond to
***@barracuda.com. Let's see how they respond.

------------------------------------------------------------------------
*From:* Dave Koontz
*Sent:* Monday, September 22, 2008 11:56 AM
*To:* ***@barracuda.com
*Subject:* RE: Thank you for contacting BarracudaCentral.org

I just signed up over the weekend for your new BRBL service.

I never got a confirmation email (primary email ***@tld.dom ).

From the Apache SpamAssassin list, it looks like your confirmation
server sending emails has no rDNS, so like many organizations our server
does not accept such messages.

I have tried to add your sending IP 216.129.105.40 to our whitelist,
but if I try to sign up again, it say's it already setup. There is no link
to EDIT our settings or ask for another confirmation email.

Please advise. THANKS!

PS: It looks rather bad when an AntiSpam company like yourself doesn't
follow RFC and setup proper rDNS entries!

[Lars Ebeling]

This would probably only reach the list??? I have a dynamic IP-address and
no reverse DNS. I use Outlook Express as client.

--
Regards
Lars Ebeling

http://leopg9.no-ip.org
Hobbithobbyist

"It is better to keep your mouth shut and appear stupid than to open it and
remove all doubt."
-- Mark Twain



----- Original Message -----
From: "Dave Koontz" <***@mbc.edu>
To: "Justin Mason" <***@jmason.org>
Cc: <***@spamassassin.apache.org>
Sent: Monday, September 22, 2008 6:59 PM
Subject: Re: New free blacklist: BRBL - Barracuda Reputation Block List


> Justin Mason wrote ... (9/22/2008 11:29 AM):
>> In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
>> legit email in general, going by the test results for our RDNS_NONE
>> rule... ;)
>>
>> --j.
>>
>
> Thanks for that stat Justin. I was always curious what others were
> seeing here. As you know, many major ISP's like AOL have similar
> policies to not accept email from IP's with no PTR record. For us, it
> blocks well over 50% of spam right out of the gate, with very little to
> no false positives. (nowhere close to 1/10th a percent, much less the 3+
> percent you cite). We have more issues with RBL and URIBL issues than
> no PRT records... those they too are extremely minimal.
>
> That said, you would think a company making their living selling
> antispam software/devices would understand the importance of rDNS
> records and other RFC rules.
>
> It would appear once you sign up and their email is blocked, you can not
> edit your own site information nor ask for another confirmation email.
> I have sent the following message on to Barracuda: I filled in their
> support form, and got an email back asking to respond to
> ***@barracuda.com. Let's see how they respond.
>
> ------------------------------------------------------------------------
> *From:* Dave Koontz
> *Sent:* Monday, September 22, 2008 11:56 AM
> *To:* ***@barracuda.com
> *Subject:* RE: Thank you for contacting BarracudaCentral.org
>
> I just signed up over the weekend for your new BRBL service.
>
> I never got a confirmation email (primary email ***@tld.dom ).
>
>>From the Apache SpamAssassin list, it looks like your confirmation
> server sending emails has no rDNS, so like many organizations our server
> does not accept such messages.
>
> I have tried to add your sending IP 216.129.105.40 to our whitelist,
> but if I try to sign up again, it say's it already setup. There is no
> link
> to EDIT our settings or ask for another confirmation email.
>
> Please advise. THANKS!
>
> PS: It looks rather bad when an AntiSpam company like yourself doesn't
> follow RFC and setup proper rDNS entries!
>
>
>
>
>

[Jari Fredriksson]

> This would probably only reach the list??? I have a
> dynamic IP-address and no reverse DNS. I use Outlook
> Express as client.

Your smart host (mc.sverige.net (Sverige.Net Mail server v2.1.3)) has a rDNS, so no problems.

My SA did not report missing rDNS from this mail.




>
>
>> Justin Mason wrote ... (9/22/2008 11:29 AM):
>>> In fairness -- if you drop mail with no rDNS, you are
>>> dropping 3.6% of legit email in general, going by the
>>> test results for our RDNS_NONE rule... ;)
>>>
>>> --j.
>>>
>>
>> Thanks for that stat Justin. I was always curious what
>> others were seeing here. As you know, many major ISP's
>> like AOL have similar policies to not accept email from
>> IP's with no PTR record. For us, it blocks well over
>> 50% of spam right out of the gate, with very little to
>> no false positives. (nowhere close to 1/10th a percent,
>> much less the 3+ percent you cite). We have more issues
>> with RBL and URIBL issues than no PRT records... those
>> they too are extremely minimal.
>>
>> That said, you would think a company making their living
>> selling antispam software/devices would understand the
>> importance of rDNS records and other RFC rules.
>>
>> It would appear once you sign up and their email is
>> blocked, you can not edit your own site information nor
>> ask for another confirmation email. I have sent the
>> following message on to Barracuda: I filled in their
>> support form, and got an email back asking to respond to
>> ***@barracuda.com. Let's see how they respond.
>>
>> ------------------------------------------------------------------------
>> *From:* Dave Koontz
>> *Sent:* Monday, September 22, 2008 11:56 AM
>> *To:* ***@barracuda.com
>> *Subject:* RE: Thank you for contacting
>> BarracudaCentral.org
>>
>> I just signed up over the weekend for your new BRBL
>> service.
>>
>> I never got a confirmation email (primary email
>> ***@tld.dom ).
>>
>>> From the Apache SpamAssassin list, it looks like your
>>> confirmation
>> server sending emails has no rDNS, so like many
>> organizations our server does not accept such messages.
>>
>> I have tried to add your sending IP 216.129.105.40 to
>> our whitelist, but if I try to sign up again, it say's
>> it already setup. There is no link
>> to EDIT our settings or ask for another confirmation
>> email.
>>
>> Please advise. THANKS!
>>
>> PS: It looks rather bad when an AntiSpam company like
>> yourself doesn't follow RFC and setup proper rDNS
>> entries!

[Ralf Hildebrandt]

* Dave Koontz <***@mbc.edu>:
> Rose, Bobby wrote ... (9/22/2008 10:24 AM):
> > I had the same issue and found that the system that's relaying
> > (216.129.105.40) those confirmation emails doesn't have a PTR record.
> > You'd think someone selling a antispam/email appliance would be familiar
> > with the RFCs.
> >
> That would explain why I got no confirmation, we do not accept email
> from IP's without a PTR record.

Same here, never got a mail, but it worked anyway.

--
Ralf Hildebrandt (i.A. des GB IT) ***@charite.de
Charite - Universitätsmedizin Berlin Tel. [phone]
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. [phone]
Geschäftsbereich IT Standort CBF I'm looking for a job!

[Dave Koontz]

Justin Piszcz wrote ... (9/22/2008 10:14 AM):
> Hmm I signed up for this 1-2 days ago but never got a confirmation
> e-mail from them? What is the RBL name?
>
> Justin.
Same here. For those currently running this, how long did it take to
get confirmation email and setup?

~ Sparky ~

[Curtis LaMasters]

About 10 minutes. I've had it up and running for about 30 minutes now and
I've gotten 127 hits. Pretty impressive. Now we will need to see what
fallout occurs. :)

Curtis LaMasters
http://www.curtis-lamasters.com
http://www.builtnetworks.com

[Martin.Hepworth]

Dave

I got mine in seconds this morning.

--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: [phone]

> -----Original Message-----
> From: Dave Koontz [mailto:***@mbc.edu]
> Sent: 22 September 2008 15:30
> To: Justin Piszcz
> Cc: ***@spamassassin.apache.org
> Subject: Re: New free blacklist: BRBL - Barracuda Reputation
> Block List
>
> Justin Piszcz wrote ... (9/22/2008 10:14 AM):
> > Hmm I signed up for this 1-2 days ago but never got a confirmation
> > e-mail from them? What is the RBL name?
> >
> > Justin.
> Same here. For those currently running this, how long did it
> take to get confirmation email and setup?
>
> ~ Sparky ~
>
>




**********************************************************************
Confidentiality : This e-mail and any attachments are intended for the
addressee only and may be confidential. If they come to you in error
you must take no action based on them, nor must you copy or show them
to anyone. Please advise the sender by replying to this e-mail
immediately and then delete the original from your computer.
Opinion : Any opinions expressed in this e-mail are entirely those of
the author and unless specifically stated to the contrary, are not
necessarily those of the author's employer.
Security Warning : Internet e-mail is not necessarily a secure
communications medium and can be subject to data corruption. We advise
that you consider this fact when e-mailing us.
Viruses : We have taken steps to ensure that this e-mail and any
attachments are free from known viruses but in keeping with good
computing practice, you should ensure that they are virus free.

Red Lion 49 Ltd T/A Solid State Logic
Registered as a limited company in England and Wales
(Company No:5362730)
Registered Office: 25 Spring Hill Road, Begbroke, Oxford OX5 1RU,
United Kingdom
**********************************************************************

[Robert LeBlanc]

Dave Koontz wrote:
> Justin Piszcz wrote ... (9/22/2008 10:14 AM):
>> Hmm I signed up for this 1-2 days ago but never got a confirmation
>> e-mail from them? What is the RBL name?
>>
>> Justin.
> Same here. For those currently running this, how long did it take to
> get confirmation email and setup?

I ran into that problem myself, but checking the logs I noticed that
Barracuda was sending the confirmation mail from an IP address with no
rDNS, so it was being rejected. To receive the confirmation email,
either whitelist 216.129.105.40 or disable your MTA's rDNS verification
temporarily.

As an aside, if you're using the Barracuda RBL with SpamAssassin, I
understand that it's not technically necessary to register your IPs with
them, you just need to use a slightly different RBL address. Instead of
"b.barracudacentral.org", use "bb.barracudacentral.org", which has
supposedly been reserved for SpamAssassin users.

--
Robert LeBlanc <***@renaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamailguard.com/>

[mouss]

Justin Piszcz wrote:
>
> Hmm I signed up for this 1-2 days ago but never got a confirmation
> e-mail from them? What is the RBL name?
>


They send from an IP without rDNS.

Received: from barracudacentral.org (unknown [216.129.105.40])

you may have rejected or quarantined it.

[mouss]

mouss wrote:
> Justin Piszcz wrote:
>>
>> Hmm I signed up for this 1-2 days ago but never got a confirmation
>> e-mail from them? What is the RBL name?
>>
>
>
> They send from an IP without rDNS.
>
> Received: from barracudacentral.org (unknown [216.129.105.40])
>
> you may have rejected or quarantined it.
>

and by the way, it hits

HTML_MESSAGE, MIME_HEADER_CTYPE_ONLY, MIME_HTML_ONLY

[fchan]

You can set up Barracuda to not to reply to spam which is default
behavior, which I hate. This is the backscatter we all experienced
from Barracuda devices. I set one up for a friend but it does take
awhile to look for the instructions and to get this setting correct
which I don't understand why they do that.

Frank

>On Sat, 2008-09-20 at 23:51 -0700, Jeff Chan wrote:
>> Haven't tried it myself but thought it may be of interest.
>
>I wonder if it will include the barracuda devices that are set to
>backscatter?
>--
>-Andy
>
>Philosophy is a battle against the bewitchment
>of our intelligence by means of language.
> - Ludwig Wittgenstein

[support]

Err, the default behaviour is NDR's are off, in fact.

On Mon, 2008-09-22 at 10:08 -0700, fchan wrote:
> You can set up Barracuda to not to reply to spam which is default
> behavior, which I hate. This is the backscatter we all experienced
> from Barracuda devices. I set one up for a friend but it does take
> awhile to look for the instructions and to get this setting correct
> which I don't understand why they do that.
>
> Frank
>
> >On Sat, 2008-09-20 at 23:51 -0700, Jeff Chan wrote:
> >> Haven't tried it myself but thought it may be of interest.
> >
> >I wonder if it will include the barracuda devices that are set to
> >backscatter?
> >--
> >-Andy
> >
> >Philosophy is a battle against the bewitchment
> >of our intelligence by means of language.
> > - Ludwig Wittgenstein
>
>

[DAve]

Jeff Chan wrote:
> [Pardon the spam; thought this new blacklist might be worth at
> least trying.]
>
> Apparently Barracuda will be publishing a free-to-use sender
> blacklist called BRBL:
>
> http://www.barracudacentral.org/rbl
>
> Haven't tried it myself but thought it may be of interest.

We have a system in use for members of a specific group within the
state. The system takes a list of ID numbers from an email and returns a
result for each number back to the sender. It requires a paid membership
and a manual verification by a human to sign up for the service. The
result emails are very structured, no images, plain text, proper and
complete headers. We have several clients who have the result emails
captured by the Barracuda Reputation System, they cannot seem to get the
result emails past their Barracuda. Other clients have no issues at all.

I have three other clients who we do spam filtering for, they have a
Barracuda between our spam filtering server and their Exchange servers.
They often trap their own intra office mail. Frank in LA emails Bob in
Atlanta, the Atlanta Barracuda says "spam" and bounces the message back
to Frank, then Frank's Barracuda says "spam" and bounces the message
back to Bob. They do not seem to be able to make it stop doing so and
will not pay for a tech to come onsite and investigate. I have a special
"slow" mail queue I dump their traffic into.

If the reputation is based on spam tagged from client managed systems I
would think it not much to count on.

DAve


--
Don't tell me I'm driving the cart!

[Ken A]

DAve wrote:
> Jeff Chan wrote:
>> [Pardon the spam; thought this new blacklist might be worth at
>> least trying.]
>>
>> Apparently Barracuda will be publishing a free-to-use sender
>> blacklist called BRBL:
>>
>> http://www.barracudacentral.org/rbl
>>
>> Haven't tried it myself but thought it may be of interest.
>
> We have a system in use for members of a specific group within the
> state. The system takes a list of ID numbers from an email and returns a
> result for each number back to the sender. It requires a paid membership
> and a manual verification by a human to sign up for the service. The
> result emails are very structured, no images, plain text, proper and
> complete headers. We have several clients who have the result emails
> captured by the Barracuda Reputation System, they cannot seem to get the
> result emails past their Barracuda. Other clients have no issues at all.
>
> I have three other clients who we do spam filtering for, they have a
> Barracuda between our spam filtering server and their Exchange servers.
> They often trap their own intra office mail. Frank in LA emails Bob in
> Atlanta, the Atlanta Barracuda says "spam" and bounces the message back
> to Frank, then Frank's Barracuda says "spam" and bounces the message
> back to Bob. They do not seem to be able to make it stop doing so and
> will not pay for a tech to come onsite and investigate. I have a special
> "slow" mail queue I dump their traffic into.
>
> If the reputation is based on spam tagged from client managed systems I
> would think it not much to count on.

I hope that's not how it's managed! We regularly see barracudas bounce
email with PBL listed IPs in the received headers (NOT the connecting
server). MailMarshall does this too, if properly misconfigured. :-(
Ken

>
> DAve
>
>


--
Ken Anderson
Pacific.Net

[Yet Another Ninja]

On 9/21/2008 8:51 AM, Jeff Chan wrote:
> [Pardon the spam; thought this new blacklist might be worth at
> least trying.]
>
> Apparently Barracuda will be publishing a free-to-use sender
> blacklist called BRBL:
>
> http://www.barracudacentral.org/rbl
>
> Haven't tried it myself but thought it may be of interest.
>

FIW:

12 hr stats / tiny traffic trap box - no ham
I use a couple of DNSWLs to reject traffic from potential hammy IPs

RANK RULE NAME COUNT %OFMAIL %OFSPAM %OFHAM
1 RCVD_BARRACUDA 19721 83.30 83.46 8.00
2 HTML_MESSAGE 19480 82.35 82.44 40.00
3 URIBL_BLACK 19457 82.17 82.34 2.00
4 RCVD_IN_XBL 18429 77.83 77.99 0.00
5 RCVD_IN_BL_SPAMCOP_NET 17009 71.83 71.98 0.00
6 URIBL_IVMURI 15851 66.94 67.08 0.00
7 URIBL_JP_SURBL 15090 63.73 63.86 0.00
8 RCVD_IN_PBL 14382 60.74 60.87 0.00
9 LOCAL_PYZOR_CHECK 13881 58.62 58.75 0.00
10 RDNS_NONE 13790 58.28 58.36 18.00
11 DOS_OE_TO_MX 11351 47.94 48.04 2.00
12 GENERIC_IXHASH 10772 45.49 45.59 0.00
13 URIBL_OB_SURBL 10705 45.21 45.30 0.00
14 URIBL_AB_SURBL 9125 38.54 38.62 0.00
15 URIBL_SC_SURBL 8882 37.51 37.59 0.00
16 URIBL_RHS_DOB 8880 37.50 37.58 0.00
17 LOCAL_IXHASH 7897 33.35 33.42 0.00
18 MIME_HTML_ONLY 6936 29.33 29.35 16.00
19 RDNS_DYNAMIC 6924 29.24 29.30 0.00
20 RCVD_IN_SORBS_DUL 6905 29.17 29.22 2.00


Spam detection seems good - no idea how it does with HAM

[Johnny Stork]

Yet Another Ninja wrote:
> On 9/21/2008 8:51 AM, Jeff Chan wrote:
>> [Pardon the spam; thought this new blacklist might be worth at
>> least trying.]
>>
>> Apparently Barracuda will be publishing a free-to-use sender
>> blacklist called BRBL:
>>
>> http://www.barracudacentral.org/rbl
>>
>> Haven't tried it myself but thought it may be of interest.
>>
>
> FIW:
>
> 12 hr stats / tiny traffic trap box - no ham
> I use a couple of DNSWLs to reject traffic from potential hammy IPs
>
> RANK RULE NAME COUNT %OFMAIL %OFSPAM %OFHAM
> 1 RCVD_BARRACUDA 19721 83.30 83.46 8.00
> 2 HTML_MESSAGE 19480 82.35 82.44 40.00
> 3 URIBL_BLACK 19457 82.17 82.34 2.00
> 4 RCVD_IN_XBL 18429 77.83 77.99 0.00
> 5 RCVD_IN_BL_SPAMCOP_NET 17009 71.83 71.98 0.00
> 6 URIBL_IVMURI 15851 66.94 67.08 0.00
> 7 URIBL_JP_SURBL 15090 63.73 63.86 0.00
> 8 RCVD_IN_PBL 14382 60.74 60.87 0.00
> 9 LOCAL_PYZOR_CHECK 13881 58.62 58.75 0.00
> 10 RDNS_NONE 13790 58.28 58.36 18.00
> 11 DOS_OE_TO_MX 11351 47.94 48.04 2.00
> 12 GENERIC_IXHASH 10772 45.49 45.59 0.00
> 13 URIBL_OB_SURBL 10705 45.21 45.30 0.00
> 14 URIBL_AB_SURBL 9125 38.54 38.62 0.00
> 15 URIBL_SC_SURBL 8882 37.51 37.59 0.00
> 16 URIBL_RHS_DOB 8880 37.50 37.58 0.00
> 17 LOCAL_IXHASH 7897 33.35 33.42 0.00
> 18 MIME_HTML_ONLY 6936 29.33 29.35 16.00
> 19 RDNS_DYNAMIC 6924 29.24 29.30 0.00
> 20 RCVD_IN_SORBS_DUL 6905 29.17 29.22 2.00
>
>
> Spam detection seems good - no idea how it does with HAM
>
>
>

How did you get this list ?

[Rob McEwen]

Yet Another Ninja wrote:
> FIW:
>
> 12 hr stats / tiny traffic trap box - no ham
> I use a couple of DNSWLs to reject traffic from potential hammy IPs
>
> RANK RULE NAME COUNT %OFMAIL %OFSPAM %OFHAM
> 1 RCVD_BARRACUDA 19721 83.30 83.46 8.00
> <SNIP>
>
> Spam detection seems good - no idea how it does with HAM

What I'm about to say is probably part of the reason that Alex started
those stats out with "fwiw", but when running stats like that, the "ham"
column is tricky.

Why? Because these are either False Positives--which is a very bad thing.

Or, these could be "False-False Positives"... which is a very good thing
because that would mean that those were really spams that would have
scored "below threshold" without use of the new list. (or, some mix of
these two)

For that reason, it is always helpful (if possible) if the tester can
examine some of the messages which make up the "ham" % on the new list
that is being evaluated. Recently, I had a user testing my own
blacklists who sent me such stats and I panicked. I sent an e-mail back
saying, surely I'm not blocking THAT many hams? He replied back stating
that, upon examination of the messages that made up the HAM category, he
couldn't find a single actual ham. They were all spam. (I breathed a big
sigh of relief!)

But I'd guess that most of that 8% of ham for Barracuda is probably
spam? Even if the barracuda list has too many FPs, I doubt it would be
that high!!?? I've seen such stats posted on anti-spam lists like SA,
but I don't recall anyone ever making that distinction.

--
Rob McEwen
http://dnsbl.invaluement.com/
***@invaluement.com
[phone]

[John Hardin]

On Tue, 23 Sep 2008, Rob McEwen wrote:

> Or, these could be "False-False Positives"... which is a very good thing
> because that would mean that those were really spams that would have
> scored "below threshold" without use of the new list. (or, some mix of
> these two)

So, for the purposes of an analysis like this, perhaps the results should
be broken into *three* categories: obviously spam, obviously ham, and
borderline.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
***@impsec.org FALaholic #11174 pgpk -a ***@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
It is not the business of government to make men virtuous or
religious, or to preserve the fool from the consequences of his own
folly. -- Henry George
-----------------------------------------------------------------------
42 days until the Presidential Election

[Rob McEwen]

John Hardin wrote:
> On Tue, 23 Sep 2008, Rob McEwen wrote:
>> Or, these could be "False-False Positives"... which is a very good
>> thing because that would mean that those were really spams that would
>> have scored "below threshold" without use of the new list. (or, some
>> mix of these two)
> So, for the purposes of an analysis like this, perhaps the results
> should be broken into *three* categories: obviously spam, obviously
> ham, and borderline.

Those initial stats are computer generated. Any follow-up analysis
should be more human-generated. There is definitely a "borderline"
category but I'd suggest that computer generated stats be left alone.
Trying to get a "borderline" by the spam filter's scoring alone is a bad
idea. Why? Because, simply put, some DNSBLs are able to catch spam that,
quite frankly, scores very low in many systems when that DNSBL is absent
(think of "first responder" dnsbls!). So splitting out into
subcategories based on computer-generated-scoring only muddies the
waters further.

Instead, the person running the stats could examine the actual messages
(that is, those classified by the spam filter as "ham") more closely and
then follow up the computer generated stats with their own personal
opinion about what was seen in those messages. Even a cursory analysis
would be far better than nothing. Few are going to have the time or
inclination to get get extremely detailed in such analysis. But hey,
that would be great too. But just a little analysis of that "ham" pile
is far better than nothing. (NOT complaining about Alex's post, btw...
again, that is why he said "fwiw"... this is more of a general
suggestion for everyone about such stats.)

--
Rob McEwen
http://dnsbl.invaluement.com/
***@invaluement.com
[phone]

[Justin Mason]

John Hardin writes:
> On Tue, 23 Sep 2008, Rob McEwen wrote:
>
> > Or, these could be "False-False Positives"... which is a very good thing
> > because that would mean that those were really spams that would have
> > scored "below threshold" without use of the new list. (or, some mix of
> > these two)
>
> So, for the purposes of an analysis like this, perhaps the results should
> be broken into *three* categories: obviously spam, obviously ham, and
> borderline.

nah. Rob's "False-False Positives" are more commonly called "spam".
his user just needed a better corpus ;)

--j.

[Yet Another Ninja]

On 9/23/2008 5:25 PM, Rob McEwen wrote:
> Yet Another Ninja wrote:
>> FIW:
>>
>> 12 hr stats / tiny traffic trap box - no ham
>> I use a couple of DNSWLs to reject traffic from potential hammy IPs
>>
>> RANK RULE NAME COUNT %OFMAIL %OFSPAM %OFHAM
>> 1 RCVD_BARRACUDA 19721 83.30 83.46 8.00
>> <SNIP>
>>
>> Spam detection seems good - no idea how it does with HAM
>
> What I'm about to say is probably part of the reason that Alex started
> those stats out with "fwiw", but when running stats like that, the "ham"
> column is tricky.
>
> Why? Because these are either False Positives--which is a very bad thing.
>
> Or, these could be "False-False Positives"... which is a very good thing
> because that would mean that those were really spams that would have
> scored "below threshold" without use of the new list. (or, some mix of
> these two)

They're *false negatives*.

this box only accepts mail for *4* harvested tagged rcpt addresses.
NO real users who would have ever filled a form, etc.

[Yet Another Ninja]

On 9/23/2008 5:12 PM, Johnny Stork wrote:
> Yet Another Ninja wrote:
>> On 9/21/2008 8:51 AM, Jeff Chan wrote:
>>> [Pardon the spam; thought this new blacklist might be worth at
>>> least trying.]
>>>
>>> Apparently Barracuda will be publishing a free-to-use sender
>>> blacklist called BRBL:
>>>
>>> http://www.barracudacentral.org/rbl
>>>
>>> Haven't tried it myself but thought it may be of interest.
>>>
>>
>> FIW:
>>
>> 12 hr stats / tiny traffic trap box - no ham
>> I use a couple of DNSWLs to reject traffic from potential hammy IPs
>>
>> RANK RULE NAME COUNT %OFMAIL %OFSPAM %OFHAM
>> 1 RCVD_BARRACUDA 19721 83.30 83.46 8.00
>> 2 HTML_MESSAGE 19480 82.35 82.44 40.00
>> 3 URIBL_BLACK 19457 82.17 82.34 2.00
>> 4 RCVD_IN_XBL 18429 77.83 77.99 0.00
>> 5 RCVD_IN_BL_SPAMCOP_NET 17009 71.83 71.98 0.00
>> 6 URIBL_IVMURI 15851 66.94 67.08 0.00
>> 7 URIBL_JP_SURBL 15090 63.73 63.86 0.00
>> 8 RCVD_IN_PBL 14382 60.74 60.87 0.00
>> 9 LOCAL_PYZOR_CHECK 13881 58.62 58.75 0.00
>> 10 RDNS_NONE 13790 58.28 58.36 18.00
>> 11 DOS_OE_TO_MX 11351 47.94 48.04 2.00
>> 12 GENERIC_IXHASH 10772 45.49 45.59 0.00
>> 13 URIBL_OB_SURBL 10705 45.21 45.30 0.00
>> 14 URIBL_AB_SURBL 9125 38.54 38.62 0.00
>> 15 URIBL_SC_SURBL 8882 37.51 37.59 0.00
>> 16 URIBL_RHS_DOB 8880 37.50 37.58 0.00
>> 17 LOCAL_IXHASH 7897 33.35 33.42 0.00
>> 18 MIME_HTML_ONLY 6936 29.33 29.35 16.00
>> 19 RDNS_DYNAMIC 6924 29.24 29.30 0.00
>> 20 RCVD_IN_SORBS_DUL 6905 29.17 29.22 2.00
>>
>>
>> Spam detection seems good - no idea how it does with HAM
>>
>>
>>
>
> How did you get this list ?

http://www.rulesemporium.com/programs/sa-stats-1.0.txt

[Bowie Bailey]

Jesse Stroik wrote:
> Matt wrote:
> >
> > Everyone should block/defer ALL email with no reverse DNS. Then
> > maybe those email admins would get a clue.
>
> No, they shouldn't.
>
> There are plenty of places still using mail gateways where the mail
> server used for sending is still on an internal network, for a variety
> of legitimate reasons, and those mail servers may resolve to a private
> address. If you discard all mail with no appropriate reverse DNS,
> you'll be discarding a lot of legitimate mail too from a lot of
> legitimate mail configurations.

What does having the mail gateway on an internal network have to do with
anything? If it is going to send mail to the Internet, then it must
have a public IP address in order to do so. This address may be local
to the machine or it may be translated by a router or firewall, but
either way there must be a public IP address used by the mailserver.
All the rDNS test cares about is that this public IP address resolve
back to a name...ANY name. This should not be a problem for any mail
gateway installation.

--
Bowie

[Jesse Stroik]

Bowie,


> What does having the mail gateway on an internal network have to do with
> anything? If it is going to send mail to the Internet, then it must
> have a public IP address in order to do so. This address may be local
> to the machine or it may be translated by a router or firewall, but
> either way there must be a public IP address used by the mailserver.
> All the rDNS test cares about is that this public IP address resolve
> back to a name...ANY name. This should not be a problem for any mail
> gateway installation.


The originating mail server could have a private address of, for
example, 172.17.1.60, for exmaple. It could then send that message
through another SMTP server that trusts the internal server. And now
you've got 172.17.1.60 in your headers as the originating server and
that doesn't (and shouldn't) reverse resolve.

You could argue that the mail gateway should strip that line from the
header but you can also come up with a variety of reasons not to. The
fact remains that this setup is perfectly legitimate within the SMTP RFC
and people use it.

If you want to start enforcing new rules that people should follow there
are proper channels to employ. Dropping your users' legitimate mail
isn't in your users' interest and as a professional sysadmin you are
compensated to protect your users' interest. Punishing people for
having configurations you believe to be odd, old or obsolete is a
differently line of work entirely ;)

Best,
Jesse

[Dave Pooser]

> The originating mail server could have a private address of, for
> example, 172.17.1.60, for exmaple. It could then send that message
> through another SMTP server that trusts the internal server. And now
> you've got 172.17.1.60 in your headers as the originating server and
> that doesn't (and shouldn't) reverse resolve.

I don't know anyone who's arguing that every hop in the header needs rDNS,
but best practice *does* require that the host that makes the connection to
an outside server should have full-circle DNS. THAT'S the server I want to
check rDNS on, not the workstation that submitted the original message
somewhere in the bowels of an RFC1918 network.
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna

[mouss]

Jesse Stroik wrote:
> Bowie,
>
>
>> What does having the mail gateway on an internal network have to do with
>> anything? If it is going to send mail to the Internet, then it must
>> have a public IP address in order to do so. This address may be local
>> to the machine or it may be translated by a router or firewall, but
>> either way there must be a public IP address used by the mailserver.
>> All the rDNS test cares about is that this public IP address resolve
>> back to a name...ANY name. This should not be a problem for any mail
>> gateway installation.
>
>
> The originating mail server could have a private address of, for
> example, 172.17.1.60, for exmaple. It could then send that message
> through another SMTP server that trusts the internal server. And now
> you've got 172.17.1.60 in your headers as the originating server and
> that doesn't (and shouldn't) reverse resolve.
>
> You could argue that the mail gateway should strip that line from the
> header but you can also come up with a variety of reasons not to. The
> fact remains that this setup is perfectly legitimate within the SMTP RFC
> and people use it.

I don't know why you are talking about _headers_. we are talking about
the IP address in the IP packet. This IP address must be routable.

>
> If you want to start enforcing new rules that people should follow there
> are proper channels to employ. Dropping your users' legitimate mail
> isn't in your users' interest and as a professional sysadmin you are
> compensated to protect your users' interest. Punishing people for
> having configurations you believe to be odd, old or obsolete is a
> differently line of work entirely ;)
>

people who block on absence of rDNS do so to combat spam. Many IPs
without PTR are residential and should not send mail directly.
Unfortunately, there are MTAs in the same situation. so the check is
unsafe for the general public (but may be ok for some sites).

[Bowie Bailey]

Jesse Stroik wrote:
> Bowie,
>
>
> > What does having the mail gateway on an internal network have to do
> > with anything? If it is going to send mail to the Internet, then
> > it must have a public IP address in order to do so. This address
> > may be local to the machine or it may be translated by a router or
> > firewall, but either way there must be a public IP address used by
> > the mailserver. All the rDNS test cares about is that this public
> > IP address resolve back to a name...ANY name. This should not be a
> > problem for any mail gateway installation.
>
>
> The originating mail server could have a private address of, for
> example, 172.17.1.60, for exmaple. It could then send that message
> through another SMTP server that trusts the internal server. And now
> you've got 172.17.1.60 in your headers as the originating server and
> that doesn't (and shouldn't) reverse resolve.
>
> You could argue that the mail gateway should strip that line from the
> header but you can also come up with a variety of reasons not to. The
> fact remains that this setup is perfectly legitimate within the SMTP
> RFC and people use it.
>
> If you want to start enforcing new rules that people should follow
> there are proper channels to employ. Dropping your users' legitimate
> mail isn't in your users' interest and as a professional sysadmin you
> are compensated to protect your users' interest. Punishing people for
> having configurations you believe to be odd, old or obsolete is a
> differently line of work entirely ;)

As I understand the discussion here, the problem is not the ORIGINATING
server, the problem is the server that finally delivers the mail to the
destination. I don't care how many servers the mail bounces around
internally. All that matters is the server that does the final delivery
out of your network.

In other words... Whatever mailserver or forwarding gateway connects to
my mailserver should have a reverse DNS entry for its IP address.

--
Bowie

[Vidar Tyldum Hansen]

On Sat, Sep 20, 2008 at 11:51:37PM -0700, Jeff Chan wrote:
> [Pardon the spam; thought this new blacklist might be worth at
> least trying.]
>
> Apparently Barracuda will be publishing a free-to-use sender
> blacklist called BRBL:
>
> http://www.barracudacentral.org/rbl

In case someone shares my interest in hitrates, here are the stats I
gathered from yesterdays email:

Spam in XBL:
66%

Spam in BRBL:
35%

Spam in both:
29%

Corpus:
My users are norwegian, server located in Norway.
2212 emails was tagged as spam. None of the emails passed as ham was hit
by either XEN or BRBL.

--
Vidar Tyldum Hansen