if blocked by a DNSBL then try another host for delivery instead of bouncing
Dr. Rolf Jansen
I am new to the list and I beg for pardon, if the following question
was already discussed - in this case please simply point me back to
the archive with some hints on finding the answer.
My Question:
Only in the CASE that the postfix smtpd receives some
sort of a 55x response from the remote host, e.g. because
of a DNSBL blocking at the remote site, is it then possible
to relay a message by another host, instead of bouncing it?
I am pretty good in shell scripting and C programming, so if somebody
gives me a kick into the right direction, I might be able to write a
script or a tool, which hooks itself into the bounce mechanism.
For those who are curious on why I might want this, here is the story:
We operate 3 mail servers, one in Germany, one in Brasil, and on in
China running Postfix as the SMTP server. Spammers become more and
more aggressive and the operators of DNSBLs follow-up, and there
seems to be an increasing tendency for black listing complete IP
blocks instead of single addresses.
In the moment our mail service in Brazil is since several days
collaterally damaged by a sbl.spamhaus.org listing of a whole
address block, and I was urged to relay all outgoing mails over the
server in Germany. Our mail service in China is collaterally damaged
by a black listing of a whole address block by MAPS, and I have to
redirect all mails to AOL users over our German mail server. There
are some other black lists, that block this and that address for some
reasons.
I spent hours with delisting requests, and it seems that the DNSBL
operators become increasingly incooperative, and they seem anyway to
assume that there is no valid mail service from China and Brazil. I
am a little bit frustrated about the situation, and I fear that given
the above mentioned tendencies the problems will increase in the
future, since we will add servers to our network in India and Serbia.
I think that it would help a lot in our situation if we could do some
automatic load balancing depending on 55x responses from remote
servers. So, if a remote server does not accept a message from the
server in Brazil it should be redirected over the server in Germany
or China. If somebody blocks the server in Germany, then the message
will be delivered by one of the other servers. I assume, that this
will reduce my headaches because of unresponsive DNSBL operators by far.
Many thanks for any help.
Best regards
Dr. Rolf Jansen
Director R&D
SurTec International GmbH
Zwingenberg Bergstrasse
Germany
Noel Jones
>Hi,
>
>I am new to the list and I beg for pardon, if the
>following question
>was already discussed - in this case please simply point
>me back to
>the archive with some hints on finding the answer.
>
>My Question:
>
> Only in the CASE that the postfix smtpd receives some
> sort of a 55x response from the remote host, e.g. because
> of a DNSBL blocking at the remote site, is it then possible
> to relay a message by another host, instead of bouncing it?
Sorry, not at this time. Right now the only solution is to
define a relayhost and send all your mail there - typically
your ISP or in your case maybe your server in Germany.
http://www.postfix.org/postconf.5.html#relayhost
Some unspecified future postfix may have a feature that
requeues mail for an alternate destination after a
rejection; such a feature is frequently requested by users
running mail servers on dynamic or residential connections.
--
Noel Jones
Sandy Drobic
I am one of those morons that is operating a small mailserver on a dynamic
line. As long as most of the traffic is only caused by me it is no trouble
to set a transport to my relayserver if a server was refusing mail
directly from a dynamic ip. Then I set up an account for a friend and
immediately saw the problem that I couldn't know what servers he would
mail to. So I sat up sender_dependent_relay_host and everything was solved
again.
In your case it is even worse, you have got several servers and many more
receiving servers that are using different blacklists. Even if it is
bitter, I think you would be better served to set up fixed relayhosts for
your Brasilian and Chinese server (and the future servers). Depending on
the traffic you can use a virtual server for 10-20 dollar per month, or,
if the traffic is substancial, us a dedicated server from a reliable
hoster. The money is cheap compared to the screams of your annoyed
customers or the hours you spend cursing dnsbl admins and inflexible
server admins.
The trouble will only get worse with the number of servers you administer,
I am afraid. It just isn't cost-effective to tinker with routes and
bounces and daily changing blacklists and server that use different
blacklists now and again. You would have to maintain a database with the
data what server is rejecting mails by using which dnsbl and then again
another database listing which blacklist is listing which of your servers
and then set up routes for your server according to that data, and finally
propagating these databases to all of your servers.
Add to that the effort to patch your system so it can distinguish between
bounces caused by dnsbl rejects and "normal" permanent rejects.
Sandy
--
List replies only please!
Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
Robert Felber
> I think that it would help a lot in our situation if we could
> do some automatic load balancing depending on 55x responses
> from remote servers. So, if a remote server does not accept a
In this case pro-active load balancing is required.
I guess you can maintain a database of your SMTP IPs. Check these IPs regulary
against known RBLs (rbls.org is a good starting point).
As soon as a IP/Block is listed there you can announce either via uucp or some
similiar approach to the listed hosts to set or change their relayhost.
Also you should announce when an IP is unlisted. You could also set up an
automated delist request as soon as an IP is listed.
To not rely on rbls.org you should write a script which does the RBL lookups
for your servers on its own.
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
mouss
> In this case pro-active load balancing is required.
> I guess you can maintain a database of your SMTP IPs. Check these IPs regulary
> against known RBLs (rbls.org is a good starting point).
>
> As soon as a IP/Block is listed there you can announce either via uucp or some
> similiar approach to the listed hosts to set or change their relayhost.
> Also you should announce when an IP is unlisted. You could also set up an
> automated delist request as soon as an IP is listed.
>
adds transport entries in case of these rejects. some collaboration
between the relays is needed to avoid a loop. also, one may consider
these entries as temporary (remove'em after some time).
Devdas Bhagat
> Hi,
>
> I am new to the list and I beg for pardon, if the following question
> was already discussed - in this case please simply point me back to
> the archive with some hints on finding the answer.
>
> My Question:
>
> Only in the CASE that the postfix smtpd receives some
> sort of a 55x response from the remote host, e.g. because
> of a DNSBL blocking at the remote site, is it then possible
> to relay a message by another host, instead of bouncing it?
>
deal with.
Anyway, the dirty trick is to set soft_bounce = yes in main.cf, and set
the IP address of your other server as fallback_relay.
Devdas Bhagat
Victor Duchovni
> Hmmm, If you are being blocked by the SBL, you have bigger issues to
> deal with.
>
> Anyway, the dirty trick is to set soft_bounce = yes in main.cf, and set
> the IP address of your other server as fallback_relay.
This does not work quite as well as might be expected, one wants to avoid
soft_bounce for mail sent to the fallback_relay...
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Dr. Rolf Jansen
I tried the suggestion of Devdas Bhagat, and it seems that it comes
close to what I need. So, special thanks to Devdas.
Anyway, there are some issues left. Also the comment of Viktor seems
to need some discussions. So, I will continue within the lines of the
messages of Devdas and Viktor.
Am 18.10.2006 um 14:59 schrieb Victor Duchovni:
> Am 18.10.2006 um 07:09 schrieb Devdas Bhagat:
>
>> On 17/10/06 14:14 -0200, Dr. Rolf Jansen wrote:
>>
>>> My Question:
>>>
>>> Only in the CASE that the postfix smtpd receives some
>>> sort of a 55x response from the remote host, e.g. because
>>> of a DNSBL blocking at the remote site, is it then possible
>>> to relay a message by another host, instead of bouncing it?
>>
>> Hmmm, If you are being blocked by the SBL, you have bigger issues to
>> deal with.
The sbl does not block exactly the IP of our server, but a whole IP
range of more than 1 million addresses of the brazilian telecom and
our address is one of that. So, our mail service in Brazil is
collaterally damaged by an action of spamhaus against a ROKSO spammer
- who by the way according to the spamhaus evidence is no more active
in the blocked net range.
So it is not exactly me, who has "bigger issues", but it is for sure
spamhaus and possibly the brazilian telecom who have to clean up
their act. I keep sending both of them reminders - without any
response since 72 h.
In the meantime, I am looking for solutions which reduces the relay
traffic from our server in Brazil to the server in Germany to only
the necessary minimum, since in the moment all outbound traffic goes
from Brazil to Germany.
>> Anyway, the dirty trick is to set soft_bounce = yes in main.cf,
>> and set
>> the IP address of your other server as fallback_relay.
>>
>> Devdas Bhagat
As mentioned already this seems to work, but unfortunately not in
every case. It does not work in those cases where the MX host of the
recipient has the same domain name as the e-mail address. It does
also not work in those cases when our server receives already 4xx and
not 5xx code because of the spamhaus blocking.
Does anyone have any ideas on this?
A minor issue is, that with the setting "soft_bounce = yes" also our
server no more reports 5xx but only 4xx error codes.
Am 18.10.2006 um 14:59 schrieb Victor Duchovni:
> This does not work quite as well as might be expected, one wants to
> avoid
> soft_bounce for mail sent to the fallback_relay...
>
> --
> Viktor.
Viktor, please can you explain this a little bit. Is there a danger
of mail loops because of this?
OTHER POSSIBLE SOLUTION???
Before I received the very promising suggestion from Devdas, I
programmed in C a SMTProbe command line tool, which tries to connect
to the 1st MX of a mail domain and initiates a SMTP session with the
HELO - MAIL FROM: - RCPT TO: sequence, but instead of DATA it sends
an early QUIT. This SMTProbe tool indeed receives very reliable the
error codes from the foreign hosts.
I was going to use this tool together with our filter shell script
which is invoked before any SMTP transport actually happens. The idea
is to SMTProbe every single recipient before actually sending out the
mail. If there is no error, then the script should simply go ahead as
usual:
sendmail -i "$@" // $@ expands to -f $(sender) -- $(recipient)
But what should I script in the case of an error. Can I by any means
use the sendmail command at the brazilian host for redirecting the
mail to the server in Germany - man sendmail does not give any clue
for this. Are there other tools instead of sendmail which can be
called from a shell script and which can be used for this?
Many thanks for spending your time with my issues.
Best regards
Rolf
Jim C. Nasby
> >>Hmmm, If you are being blocked by the SBL, you have bigger issues to
> >>deal with.
issues...
> So it is not exactly me, who has "bigger issues", but it is for sure
> spamhaus and possibly the brazilian telecom who have to clean up
> their act. I keep sending both of them reminders - without any
> response since 72 h.
Sounds like it might be time for a new provider... :)
> Before I received the very promising suggestion from Devdas, I
> programmed in C a SMTProbe command line tool, which tries to connect
> to the 1st MX of a mail domain and initiates a SMTP session with the
> HELO - MAIL FROM: - RCPT TO: sequence, but instead of DATA it sends
> an early QUIT. This SMTProbe tool indeed receives very reliable the
> error codes from the foreign hosts.
If that means every outbound address requires 2 connections to the
destination MTA, that doesn't sound very net-friendly...
> I was going to use this tool together with our filter shell script
> which is invoked before any SMTP transport actually happens. The idea
> is to SMTProbe every single recipient before actually sending out the
> mail. If there is no error, then the script should simply go ahead as
> usual:
>
> sendmail -i "$@" // $@ expands to -f $(sender) -- $(recipient)
>
> But what should I script in the case of an error. Can I by any means
> use the sendmail command at the brazilian host for redirecting the
> mail to the server in Germany - man sendmail does not give any clue
> for this. Are there other tools instead of sendmail which can be
> called from a shell script and which can be used for this?
--
Jim C. Nasby, Database Architect dec...@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
Dr. Rolf Jansen
> On Wed, Oct 18, 2006 at 05:08:46PM -0200, Dr. Rolf Jansen wrote:
>>>> Hmmm, If you are being blocked by the SBL, you have bigger
>>>> issues to
>>>> deal with.
>
> IMO, anyone who blocks email based on a single RBL test is the one
> with
> issues...
>
>> So it is not exactly me, who has "bigger issues", but it is for sure
>> spamhaus and possibly the brazilian telecom who have to clean up
>> their act. I keep sending both of them reminders - without any
>> response since 72 h.
>
> Sounds like it might be time for a new provider... :)
Sure, we are looking around. However, the infrastructure in Brazil is
not at the same level as in Germany or in the U.S., where you can
easily find 10 or more providers who do exactly what you want.
Another point is that the spamhaus action of blocking whole net
blocks of a national telecom company is somewhat arrogant. If they
would do this in Europe, for example blocking 1 million addresses of
the Deutsche Telekom or in U.S. blocking 1 million addresses of AT&T...
>> Before I received the very promising suggestion from Devdas, I
>> programmed in C a SMTProbe command line tool, which tries to connect
>> to the 1st MX of a mail domain and initiates a SMTP session with the
>> HELO - MAIL FROM: - RCPT TO: sequence, but instead of DATA it sends
>> an early QUIT. This SMTProbe tool indeed receives very reliable the
>> error codes from the foreign hosts.
>
> If that means every outbound address requires 2 connections to the
> destination MTA, that doesn't sound very net-friendly...
We are talking about much less than 1 kB additional traffic. IMO, it
is much less net freindly to send first everything to the German
server which is about 11000 km away and then let this send 90 % of
the mails back to Brazil. Anyway, if spamhaus stops their arrogant
action before I am ready with my programming, then I will go for the
more net friendly option.
>> I was going to use this tool together with our filter shell script
>> which is invoked before any SMTP transport actually happens. The idea
>> is to SMTProbe every single recipient before actually sending out the
>> mail. If there is no error, then the script should simply go ahead as
>> usual:
>>
>> sendmail -i "$@" // $@ expands to -f $(sender) -- $(recipient)
>>
>> But what should I script in the case of an error. Can I by any means
>> use the sendmail command at the brazilian host for redirecting the
>> mail to the server in Germany - man sendmail does not give any clue
>> for this. Are there other tools instead of sendmail which can be
>> called from a shell script and which can be used for this?
Any suggestions to this technical question?
Jim C. Nasby
> Le Wed 18/10/2006, Jim C. Nasby disait
> >On Wed, Oct 18, 2006 at 05:08:46PM -0200, Dr. Rolf Jansen wrote:
> >>>>Hmmm, If you are being blocked by the SBL, you have bigger issues to
> >>>>deal with.
> >
> >IMO, anyone who blocks email based on a single RBL test is the one with
> >issues...
>
> my ISP... (static addresses)
Yup, exactly why not to block based on them. Though, you should complain
to your ISP as well...
Victor Duchovni
> Another point is that the spamhaus action of blocking whole net
> blocks of a national telecom company is somewhat arrogant. If they
> would do this in Europe, for example blocking 1 million addresses of
> the Deutsche Telekom or in U.S. blocking 1 million addresses of AT&T...
>
Which SBL listing are your referring to?
Dr. Rolf Jansen
> On Wed, Oct 18, 2006 at 06:01:09PM -0200, Dr. Rolf Jansen wrote:
>
>> Another point is that the spamhaus action of blocking whole net
>> blocks of a national telecom company is somewhat arrogant. If they
>> would do this in Europe, for example blocking 1 million addresses of
>> the Deutsche Telekom or in U.S. blocking 1 million addresses of
>> AT&T...
>>
>
> Which SBL listing are your referring to?
>
> --
> Viktor.
http://www.spamhaus.org/sbl/sbl.lasso?query=SBL47434
They no more block 200.161.0.0/20 which is 1 million addresses but
200.161.0.0/16 which is "only" 2^16 = 65536 addresses. Anyway, our
server stays among the range.
In the meantime, I got some response from spamhaus, and this turns
almost everything they state at the given web page above into a lie.
The response states:
"Telesp has written to us in fluent English..."
I am by far to angry in the moment, to comment this any further.
The reason why they block a whole netblock is:
dig @200.161.7.15 send-safe.com
This means somebody hosts at the IP 200.161.7.15 a private name
server which has a zone record for send-safe.com. So what? I can also
install with bind at my notebook at home a zone record for spamhaus.org.
My experience tells me, that spamhaus finally turned to be another
SPEWS.
Anyway, I am fed up, with this kind of Nazism, and I am going to
change it.
Rolf
John Peach
Steven F Siirila <s...@tc.umn.edu> wrote:
> On Thu, Oct 19, 2006 at 01:28:41AM -0200, Dr. Rolf Jansen wrote:
> > Am 18.10.2006 um 22:45 schrieb Victor Duchovni:
> >
> > >On Wed, Oct 18, 2006 at 06:01:09PM -0200, Dr. Rolf Jansen wrote:
> > >
> > >>Another point is that the spamhaus action of blocking whole net
> > >>blocks of a national telecom company is somewhat arrogant. If they
> > >>would do this in Europe, for example blocking 1 million addresses
> > >>of the Deutsche Telekom or in U.S. blocking 1 million addresses
> > >>of AT&T...
> > >>
> > >
> > >Which SBL listing are your referring to?
> > >
> > >--
> > > Viktor.
> >
> > http://www.spamhaus.org/sbl/sbl.lasso?query=SBL47434
> > , instead
> > They no more block 200.161.0.0/20 which is 1 million addresses but
> > 200.161.0.0/16 which is "only" 2^16 = 65536 addresses. Anyway, our
> > server stays among the range.
>
> There were 453 IP addresses that attempted to send us e-mail from the
> 200.161.0.0/16 net in the past 3 days alone. Every single one was
> either marked dynamic (by MAPS or SORBS or both) or was marked
> insecure (by the CBL as well as the XBL). Note that if we did not
> use Spamhaus, every last one of these IP addresses would still have
> been blocked.
>
> So what's the problem? These sure look like zombie bots to me.
>
The problem is that he's blaming Spamhaus for putting pressure on
telesp.net.br, instead of going to telesp.net.br, whom he is presumably
paying for "service" and beating them up about not fixing THEIR
problem.
Steven F Siirila
> Am 18.10.2006 um 22:45 schrieb Victor Duchovni:
>
> >On Wed, Oct 18, 2006 at 06:01:09PM -0200, Dr. Rolf Jansen wrote:
> >
> >>Another point is that the spamhaus action of blocking whole net
> >>blocks of a national telecom company is somewhat arrogant. If they
> >>would do this in Europe, for example blocking 1 million addresses of
> >>the Deutsche Telekom or in U.S. blocking 1 million addresses of
> >>AT&T...
> >>
> >
> >Which SBL listing are your referring to?
> >
> >--
> > Viktor.
>
> http://www.spamhaus.org/sbl/sbl.lasso?query=SBL47434
>
> They no more block 200.161.0.0/20 which is 1 million addresses but
> 200.161.0.0/16 which is "only" 2^16 = 65536 addresses. Anyway, our
> server stays among the range.
There were 453 IP addresses that attempted to send us e-mail from the
200.161.0.0/16 net in the past 3 days alone. Every single one was
either marked dynamic (by MAPS or SORBS or both) or was marked insecure
(by the CBL as well as the XBL). Note that if we did not use Spamhaus,
every last one of these IP addresses would still have been blocked.
So what's the problem? These sure look like zombie bots to me.
> In the meantime, I got some response from spamhaus, and this turns
> almost everything they state at the given web page above into a lie.
> The response states:
>
> "Telesp has written to us in fluent English..."
>
> I am by far to angry in the moment, to comment this any further.
>
> The reason why they block a whole netblock is:
>
> dig @200.161.7.15 send-safe.com
>
> This means somebody hosts at the IP 200.161.7.15 a private name
> server which has a zone record for send-safe.com. So what? I can also
> install with bind at my notebook at home a zone record for spamhaus.org.
>
> My experience tells me, that spamhaus finally turned to be another
> SPEWS.
>
>
> Anyway, I am fed up, with this kind of Nazism, and I am going to
> change it.
>
> Rolf
>
>
>
>
--
Steven F. Siirila Office: Lind Hall, Room 130B
Internet Services E-mail: s...@umn.edu
Office of Information Technology Voice: (612) 626-0244
University of Minnesota Fax: (612) 626-7593
mouss
>> And I cannot post to postfiox ML because MAPS lists whole /16 networks of
>> my ISP... (static addresses)
>>
>
> Yup, exactly why not to block based on them. Though, you should complain
> to your ISP as well...
>
Complain like what? maps/trendnet is not a neutral organization that we
can trust. and if they can't whitelist specific IPs or ranges inside a
blocked network, then they are either incompetent (which I doubt) or ...
Anyway, up so far, I thought spamhaus was a safe list, but it now seems
less obvious.
Victor Duchovni
> Anyway, up so far, I thought spamhaus was a safe list, but it now seems
> less obvious.
It still is.
/dev/rob0
> On Fri, Oct 20, 2006 at 12:28:49AM +0200, mouss wrote:
> > Anyway, up so far, I thought spamhaus was a safe list, but it now
> > seems less obvious.
>
> It still is.
http://www.spamhaus.org/sbl/listings.lasso?isp=telesp.net.br
... lists only 8 /32's at the time of this writing. But 3 of those are
ROKSO, not good. Oh well, my home ISP is worse.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
/dev/rob0
> On Thursday 19 October 2006 18:56, Victor Duchovni wrote:
> > On Fri, Oct 20, 2006 at 12:28:49AM +0200, mouss wrote:
> > > Anyway, up so far, I thought spamhaus was a safe list, but it now
> > > seems less obvious.
> >
> > It still is.
>
> http://www.spamhaus.org/sbl/listings.lasso?isp=telesp.net.br
>
> ... lists only 8 /32's at the time of this writing. But 3 of those
Sorry, I meant to make a point with that. The point being that
Spamhaus' good reputation was earned by being responsive to collateral
damage issues. So another avenue of action in cases like this is to
talk to Spamhaus (perhaps via SPAM-L or NANAE.)
Victor Duchovni
> On Wednesday 25 October 2006 21:34, I wrote:
> > On Thursday 19 October 2006 18:56, Victor Duchovni wrote:
> > > On Fri, Oct 20, 2006 at 12:28:49AM +0200, mouss wrote:
> > > > Anyway, up so far, I thought spamhaus was a safe list, but it now
> > > > seems less obvious.
> > >
> > > It still is.
> >
> > http://www.spamhaus.org/sbl/listings.lasso?isp=telesp.net.br
> >
> > ... lists only 8 /32's at the time of this writing. But 3 of those
>
> Sorry, I meant to make a point with that. The point being that
> Spamhaus' good reputation was earned by being responsive to collateral
> damage issues. So another avenue of action in cases like this is to
> talk to Spamhaus (perhaps via SPAM-L or NANAE.)
The OP's SBL listing is no longer active...
http://www.spamhaus.org/sbl/sbl.lasso?query=SBL47434
is there still an issue here?
Andrew I Baznikin
"Dr. Rolf Jansen" <R...@SurTec.com> wrote:
> > Sounds like it might be time for a new provider... :)
> Another point is that the spamhaus action of blocking whole net
> blocks of a national telecom company is somewhat arrogant. If they
> would do this in Europe, for example blocking 1 million addresses of
> the Deutsche Telekom or in U.S. blocking 1 million addresses of AT&T...
They did it in Russia - all nets of national operator RosTelecom was blocked (eventually, now its delisted)
--
Andrew I Baznikin
# /\ ASCII ribbon
# \/ campaign
# /\ against
# / \ HTML email
Dr. Rolf Jansen
> On Wed, Oct 25, 2006 at 09:39:14PM -0500, /dev/rob0 wrote:
>> On Wednesday 25 October 2006 21:34, I wrote:
>>> On Thursday 19 October 2006 18:56, Victor Duchovni wrote:
>>>> On Fri, Oct 20, 2006 at 12:28:49AM +0200, mouss wrote:
>>>>> Anyway, up so far, I thought spamhaus was a safe list, but it now
>>>>> seems less obvious.
>>>>
>>>> It still is.
>>>
>>> http://www.spamhaus.org/sbl/listings.lasso?isp=telesp.net.br
>>>
>>> ... lists only 8 /32's at the time of this writing. But 3 of those
>>
>> Sorry, I meant to make a point with that. The point being that
>> Spamhaus' good reputation was earned by being responsive to
>> collateral
>> damage issues. So another avenue of action in cases like this is to
>> talk to Spamhaus (perhaps via SPAM-L or NANAE.)
>
> The OP's SBL listing is no longer active...
>
> http://www.spamhaus.org/sbl/sbl.lasso?query=SBL47434
>
> is there still an issue here?
Indeed, Spamhaus stopped their action against the netrange
200.161.0.0/16 without further notice at the last weekend, and with
that also our innocent single IP address is no more blocked by the
SBL. So, from the Spamhaus point of view, there is no issue anymore.
Anyway, I took this SBL incident as a signal for working on counter
measures, and therefore I do still have an issue here:
1. I am still working an a technical solution for the problem
named in the subject line of this thread:
"if blocked by a DNSBL then try another host for
delivery instead of bouncing"
I expect to have this finished and working by the
end of this weekend.
2. I am in the process on establishing a network of fallback
SMTP relays. In the moment we have already 4 and I am
now very sure that another incident like the Spamhaus one
will have by far much less impact on our mail services.
3. Once finished with (1) and (2) I will abandon the utilisation
of RBL's from our mail servers in favour of grey listing. This
is my conclusion from the SBL issue and the non responsive
and irresponsible behaviour of Spamhaus. Please note, that
this was totally out of my expectation, and before that incident
I was also under the impression that Spamhaus is a reliable
service.
My conclusion is, that we "Postmasters" give the operators
of RBL's by far too much power, AND the old wisdom
"Power corrupts" is definitely true.
Best regards
Rolf Jansen
Robert Felber
> 3. Once finished with (1) and (2) I will abandon the
> utilisation
> of RBL's from our mail servers in favour of grey listing.
> This
> is my conclusion from the SBL issue and the non responsive
> and irresponsible behaviour of Spamhaus. Please note, that
> this was totally out of my expectation, and before that
> incident
> I was also under the impression that Spamhaus is a reliable
> service.
>
> My conclusion is, that we "Postmasters" give the operators
> of RBL's by far too much power, AND the old wisdom
> "Power corrupts" is definitely true.
Please remove all RBL checks from SpamAssassin and other Filters, too.
Dr. Rolf Jansen
> On Thu, Oct 26, 2006 at 03:18:49PM -0200, Dr. Rolf Jansen wrote:
>> 3. Once finished with (1) and (2) I will abandon the
>
> Please remove all RBL checks from SpamAssassin and other Filters, too.
Of course, you made a point here.
However at our servers I installed CRM114 for side-wide content
filtering.
CRM114 does not make use of RBL checks.
Best regards
Rolf Jansen
Robert Felber
And now imagine a rather loaded ESP. An MX which has to accept each and every
mail (to existent users) in order to figure out whether it is spam has some
disadvances:
1) Bandwidth loss
2) Process-slot resource loss
3) Excessive CPU resource loss due to expensive regular expression
analysing of after-queue spam/virus filters.
3) Queueing resource loss
4) Memory resource loss
5) Quarantine Space resource loss
6) Must generate notifications or bounces (by law in some countries)
7) 6) may lead to a backscatter - thus such a system may become an
attack amplifier towards other systems
8) massive attacks can only be beaten with a) better hardware and
connectivity and b) quick appropriate header/body checks before
END OF DATA.
Remember, a rather large ESP may handle mail by factor 100 to 1000 of your
volume.
As such ESP may tend to utilize RBLs in order to avoid up to 70% of obvious
spammy mails. The wrong way would be to use _one_ RBL hit for a spam/ham
decision.
A more appropriate way may be to take more than two RBLs into account and
define a weight for each RBL. If the sum of that weight exceeds your criteria
the mail may be rejected. This can happen before DATA - which results in:
1) No queuing
2) No resource loss due to after queue content scanning
3) No notifications to be sent, no backscatter
4) All in all better scalability of existing systems
If desired you could use 4xx as rejectcode, to increase the chance that in case
of a (rather unlikely, yet possible) false positive the client may be delisted
automatically from a RBL while he tries to re-deliver (spamcop for instance
delists an address after 24 hours
(http://www.spamcop.net/fom-serve/cache/297.html).
However, to condemn RBLs per se is inappropriate. You should rather address your
rant against the postmaster which doesn't check appropriate.
Dr. Rolf Jansen
> On Thu, Oct 26, 2006 at 03:40:05PM -0200, Dr. Rolf Jansen wrote:
>> Am 26.10.2006 um 15:21 schrieb Robert Felber:
>>> On Thu, Oct 26, 2006 at 03:18:49PM -0200, Dr. Rolf Jansen
>>> wrote:
>>>> 3. Once finished with (1) and (2) I will abandon the
>>>> utilisation of RBL's from our mail servers...
>>>
>>> Please remove all RBL checks from SpamAssassin and other
>>> Filters, too.
>>
>> Of course, you made a point here.
>>
>> However at our servers I installed CRM114 for side-wide content
>> filtering.
>> CRM114 does not make use of RBL checks.
>
Possibly you misunderstood my intention. It is not to replace RBL
checks by content filtering. This would of course have all the side
effects you mentioned.
My intention is to replace RBL checks by the Grey Listing mechanism.
So I will switch from:
RBL checks during SMTP time (before DATA)
+ standard Postfix UCE checks during SMTP time
+ statistical content analysis using CRM114
after the SMTP session after DATA
To:
Grey Listing during SMTP time (before DATA)
+ standard Postfix UCE checks during SMTP time (before DATA)
+ statistical content analysis using CRM114
after the SMTP session after DATA
> However, to condemn RBLs per se is inappropriate.
I will see myself, how far I come when I replace RBL checks by the
grey listing mechanism.
> You should rather address your rant against the postmaster which
> doesn't check appropriate.
I decide myself, what I should and what not. Seems that others have
time enough for your approach, I do not.
Best regards
Rolf Jansen
mouss
> Am 26.10.2006 um 16:26 schrieb Robert Felber:
>>
>> And now imagine a rather loaded ESP...
>
> Possibly you misunderstood my intention. It is not to replace RBL
> checks by content filtering. This would of course have all the side
> effects you mentioned.
>
> My intention is to replace RBL checks by the Grey Listing mechanism.
> So I will switch from:
greylisting is not enough. if spam is sent via a real MTA, GL will only
delay it (and possibly cause some load overhead on the sending MTA, but
this is not enough to stop spam).
Check Robert's policyd-weight. This takes a decision based on multiple
factors, with configurable weights that you can tune.
Robert Felber
> Dr. Rolf Jansen wrote:
> >Am 26.10.2006 um 16:26 schrieb Robert Felber:
> >>
> >>And now imagine a rather loaded ESP...
> >
> >Possibly you misunderstood my intention. It is not to replace
> >RBL checks by content filtering. This would of course have all
> >the side effects you mentioned.
> >
> >My intention is to replace RBL checks by the Grey Listing
> >mechanism. So I will switch from:
>
> greylisting is not enough. if spam is sent via a real MTA, GL
> will only delay it (and possibly cause some load overhead on
> the sending MTA, but this is not enough to stop spam).
I realize we're too much off-topic. I just tried to make Dr. Jansen realize
that RBLs used wrong of course are a danger. If he has problems to deliver
mail because a whole netblock is listed, then he should have a fallback path.
He can always check whether his IPs are listed hours before he will send mail.
A 5 Minute cronjob is sufficient.
Swearing against RBLs won't help him. For that they have too much value (yet).