UCEPROTECT Blacklists and why callouts are abusive

[UCEPROTECT-Network Blacklistmaster of the day]

As we explained on our website, we consider callouts abusive, because they
can make your system part of an ddos against others.

If someone claimes to be ***@yourdomain and sends out some million spammails

you will get a real feeling, why you should not use callouts.

Ok your system will have to deal with tons of bounces, but additional with
all those lamerz using sender callouts.

The problem is not that ONE connecction which you are doing. The problem is,
that you and millions of others
are trying to verify one address, which leads to a ddos against the targeted
system.

This is the reason why we are blacklisting anyone probing spamtraps of the
project.

The only difference between verifyers and for e.g. TMDA-Abusers is that no
real mail is sent by verifiers.

Anyone using sender callouts shows that he is selfish and it does not matter to him, to be part of a ddos against third parties.

[David Saez Padros]

Hi !!

Post by UCEPROTECT-Network Blacklistmaster of the day
you will get a real feeling, why you should not use callouts.
Ok your system will have to deal with tons of bounces, but additional with
all those lamerz using sender callouts.

we have been on such situation where viruses catched some of our email
addresses and start spreading at great scale. The real problem which
make our servers really busy was to deal with bounces sent by antivirus
to that forged address, but we never had any problem with callouts. We
still receive some bounces for that addreses (which were deactivated
long time ago) and in fact we would prefer that other people use
callouts to avoid receiving such bounces, as handling callouts is more
efficient that having to deal with the whole bounce.

In fact any callout that you receive is another bounce that you avoid
receiving, so if you ever faced that situation you will really prefer
callouts than bounces.
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Eric]

Post by David Saez Padros
In fact any callout that you receive is another bounce that you avoid
receiving, so if you ever faced that situation you will really prefer
callouts than bounces.

Personally I'd prefer that more mail admins learn to reject mail
outright, rather than accept and bounce. Then I wouldn't have to deal
with the bounce or a callout.

[David Saez Padros]

Hi !!

Post by Eric

Post by David Saez Padros
In fact any callout that you receive is another bounce that you avoid
receiving, so if you ever faced that situation you will really prefer
callouts than bounces.

Personally I'd prefer that more mail admins learn to reject mail
outright, rather than accept and bounce. Then I wouldn't have to deal
with the bounce or a callout.

This could be in a perfect world, we always try to reject at smtp time
but not all people could do that. Some very large spanish providers
(and many others around the world) just accept anything on the mx hosts
and then route the message to other hosts that know if the user really
exists so they cannot reject unknown users at smtp time.

I have been thinking for some time to setup a domain based dns list
that will list either domains that do not accept null senders, domains
for which it's mx hosts accept everything at smtp time and domains that
it's postmaster has expressly asked to not receive callouts. This list
will be used to avoid doing callouts on the listed domains because
either it will have no meaningul result or because that domain does not
like callouts.
--
Best regards ....

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Stuart Rowan]

Post by David Saez Padros
Hi !!

Post by Eric

Post by David Saez Padros
In fact any callout that you receive is another bounce that you avoid
receiving, so if you ever faced that situation you will really prefer
callouts than bounces.

Personally I'd prefer that more mail admins learn to reject mail
outright, rather than accept and bounce. Then I wouldn't have to deal
with the bounce or a callout.

This could be in a perfect world, we always try to reject at smtp time
but not all people could do that. Some very large spanish providers
(and many others around the world) just accept anything on the mx hosts
and then route the message to other hosts that know if the user really
exists so they cannot reject unknown users at smtp time.

These providers could (should?) do recipient callouts surely?

Cheers,
Stu.

[David Saez Padros]

Hi !!

Post by Stuart Rowan

Post by David Saez Padros

Post by Eric
Personally I'd prefer that more mail admins learn to reject mail
outright, rather than accept and bounce. Then I wouldn't have to deal
with the bounce or a callout.

This could be in a perfect world, we always try to reject at smtp time
but not all people could do that. Some very large spanish providers
(and many others around the world) just accept anything on the mx hosts
and then route the message to other hosts that know if the user really
exists so they cannot reject unknown users at smtp time.

These providers could (should?) do recipient callouts surely?

yes, they could do many things the right way but it's not easy to
change things in a big provider.
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Marc Perkel]

Post by Eric

Post by David Saez Padros
In fact any callout that you receive is another bounce that you avoid
receiving, so if you ever faced that situation you will really prefer
callouts than bounces.

Personally I'd prefer that more mail admins learn to reject mail
outright, rather than accept and bounce. Then I wouldn't have to deal
with the bounce or a callout.

One of the reasons I use the callout is to reject incomming messages
outright. If the sender verify fails then I drop the connection.

[Zbigniew Szalbot]

Hi,

Post by UCEPROTECT-Network Blacklistmaster of the day
As we explained on our website, we consider callouts abusive, because they
can make your system part of an ddos against others.

That's in theory but I have my system setup in such a way that I do not
use callouts. However, you are blocking my server lists.lc-words.com:

TXT= "Net 83.19.0.0/16 is Level 3 listed at UCEPROTECT-Network. See
http://www.uceprotect.net/en/index.php?m=7&s=8"

Problem is my server is 83.19.156.210 so you are blocking me and a whole
IP range and it has NOTHING to do with callouts, sir.

We have never sent a single spam and yet we have been blocked. Can you
explain? Maybe others in the *.0.0/16 IP range have sent millions of spam
emails, but we have not.

In order to keep in touch with customers who requested information from us
I daily have to deal with people like you, people blocking others without
putting any thought into what you are doing.

Regards,

--
Zbigniew Szalbot

[Ian Eiloart]

--On 17 October 2006 16:42:50 +0200 Zbigniew Szalbot

Post by Zbigniew Szalbot
Hi,

Post by UCEPROTECT-Network Blacklistmaster of the day
As we explained on our website, we consider callouts abusive, because
they can make your system part of an ddos against others.

That's in theory but I have my system setup in such a way that I do not
TXT= "Net 83.19.0.0/16 is Level 3 listed at UCEPROTECT-Network. See
http://www.uceprotect.net/en/index.php?m=7&s=8"

To be fair, they do recommend that users don't block at level 3.

I still think their listing criteria are dumb. The seem to use three
techniques:

1. People who bounce viruses with warning messages (actually, that's fine).

2. People who use SRS. I'd like to use it for local people that ask to get
email forwarded from their local (sussex.ac.uk) address to a personal
address. I don't see how SRS can harm anyone when I do this. Perhaps such
email would never hit their honeypots, though.

3. People using sender verification callouts. They seem to think it's as
bad as sending email, but my sender verification callouts don't fill
mailboxes or server queues. And, they do stop lots of spam.

Post by Zbigniew Szalbot
Problem is my server is 83.19.156.210 so you are blocking me and a whole
IP range and it has NOTHING to do with callouts, sir.
We have never sent a single spam and yet we have been blocked. Can you
explain? Maybe others in the *.0.0/16 IP range have sent millions of spam
emails, but we have not.
In order to keep in touch with customers who requested information from
us I daily have to deal with people like you, people blocking others
without putting any thought into what you are doing.
Regards,
--
Zbigniew Szalbot

[Hill Ruyter]

This all sounds remarkably familiar ...

These UCEPROTECT people don't happen to be in Australia outfit run by a
megalomaniac who's name I forget (sorry)

We had an argument when I worked at a tier 1 network. He blocked a whole
/19 address range because he couldn't use RIPE and refused to back down
so I blocked his entire range on the all advertised points
after his business hosting customers could not get to anywhere in Europe
anymore, he backed down.
I must say it was nice to have BGP argue for me since e-mail wasn't working.
Last I heard he had gone bust

Wish I could remember his name

Sorry for the off topic

Hill

----- Original Message -----
From: "Ian Eiloart" <***@sussex.ac.uk>
To: "Zbigniew Szalbot" <***@szalbot.homedns.org>; "UCEPROTECT-Network
Blacklistmaster of the day" <***@uceprotect.net>
Cc: <exim-***@exim.org>
Sent: Tuesday, October 17, 2006 4:09 PM
Subject: Re: [exim] UCEPROTECT Blacklists and why callouts are abusive

Post by Ian Eiloart
--On 17 October 2006 16:42:50 +0200 Zbigniew Szalbot

Post by Zbigniew Szalbot
Hi,

Post by UCEPROTECT-Network Blacklistmaster of the day
As we explained on our website, we consider callouts abusive, because
they can make your system part of an ddos against others.

That's in theory but I have my system setup in such a way that I do not
TXT= "Net 83.19.0.0/16 is Level 3 listed at UCEPROTECT-Network. See
http://www.uceprotect.net/en/index.php?m=7&s=8"

To be fair, they do recommend that users don't block at level 3.
I still think their listing criteria are dumb. The seem to use three
1. People who bounce viruses with warning messages (actually, that's fine).
2. People who use SRS. I'd like to use it for local people that ask to get
email forwarded from their local (sussex.ac.uk) address to a personal
address. I don't see how SRS can harm anyone when I do this. Perhaps such
email would never hit their honeypots, though.
3. People using sender verification callouts. They seem to think it's as
bad as sending email, but my sender verification callouts don't fill
mailboxes or server queues. And, they do stop lots of spam.

Post by Zbigniew Szalbot
Problem is my server is 83.19.156.210 so you are blocking me and a whole
IP range and it has NOTHING to do with callouts, sir.
We have never sent a single spam and yet we have been blocked. Can you
explain? Maybe others in the *.0.0/16 IP range have sent millions of spam
emails, but we have not.
In order to keep in touch with customers who requested information from
us I daily have to deal with people like you, people blocking others
without putting any thought into what you are doing.
Regards,
--
Zbigniew Szalbot

--
Ian Eiloart
IT Services, University of Sussex
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[David Woodhouse]

Post by Ian Eiloart
1. People who bounce viruses with warning messages (actually, that's fine).

It's not fine to _bounce_ them -- they should be rejected. Generating
bounces in responses to viruses is bad.

Post by Ian Eiloart
2. People who use SRS. I'd like to use it for local people that ask to get
email forwarded from their local (sussex.ac.uk) address to a personal
address. I don't see how SRS can harm anyone when I do this. Perhaps such
email would never hit their honeypots, though.

Why would you do SRS unconditionally? If you really must do SRS because
a recipient's mail is bouncing and they cannot or will not fix the
broken destination to which you're forwarding, _then_ you can enable SRS
on mail forwarded to _that_ host/domain, if you really care to work
around the recipient's brain damage.

But as you say, that would be very unlikely to ever hit the UCEPROTECT
honeypot.

Post by Ian Eiloart
3. People using sender verification callouts. They seem to think it's as
bad as sending email, but my sender verification callouts don't fill
mailboxes or server queues. And, they do stop lots of spam.

Yeah, this is just the UCEPROTECT folks being muppets. I'm with Nigel;
they're best ignored.

[Chris Edwards]

On Tue, 17 Oct 2006, David Woodhouse wrote:

| On Tue, 2006-10-17 at 16:09 +0100, Ian Eiloart wrote:
| > 1. People who bounce viruses with warning messages (actually, that's fine).
|
| It's not fine to _bounce_ them -- they should be rejected. Generating
| bounces in responses to viruses is bad.

I think Ian meant listing of people who bounce viruses is fine.


| Yeah, this is just the UCEPROTECT folks being muppets. I'm with Nigel;
| they're best ignored.

The classic DNSBL argument! Assuming they are muppets, they will
ultimately be ignored, with few mail admins using them to block. If
however enough mail admins are using them to block as to cause pain to
those listed, then one might at least sit and think whether or not their
listing policy has some merit afterall.

[Zbigniew Szalbot]

Hello,

Post by Chris Edwards
The classic DNSBL argument! Assuming they are muppets, they will
ultimately be ignored, with few mail admins using them to block. If
however enough mail admins are using them to block as to cause pain to
those listed, then one might at least sit and think whether or not their
listing policy has some merit afterall.

And has it? I was blocked NOT because I bouced viruses, NOT because I used
callouts and NOT because I spew spam (which I haven't) but only because
they - as many other similar thoughtless RBL folks - have blocked a whole
IP range where I happened to have my IP. Now, why am I being held
responsible for what other clients of the national ISP are doing?

I have already contacted my ISP to act on my behalf but frankly what
chances do I stand of them doing anything if you take into account that
this is the largest national provider?

My mail server is properly configured.
I have never sent a single spam message.
I have a revdns.
I do not use callouts.
I etc., etc.

Merit in their policy? No kidding!

--
Zbigniew Szalbot

[Ian Eiloart]

--On 17 October 2006 20:04:54 +0200 Zbigniew Szalbot

Post by Zbigniew Szalbot
And has it? I was blocked NOT because I bouced viruses, NOT because I
used callouts and NOT because I spew spam (which I haven't) but only
because they - as many other similar thoughtless RBL folks - have
blocked a whole IP range where I happened to have my IP.

No, they didn't block you, they listed you. Someone else chose to use that
list for blocking. UCEPROTECT recommend that their level 3 list should
*NOT* be used for blocking.

[Chad Leigh -- Shire.Net LLC]

Post by Zbigniew Szalbot
Hello,

Post by Chris Edwards
The classic DNSBL argument! Assuming they are muppets, they will
ultimately be ignored, with few mail admins using them to block. If
however enough mail admins are using them to block as to cause pain to
those listed, then one might at least sit and think whether or not their
listing policy has some merit afterall.

And has it? I was blocked NOT because I bouced viruses, NOT because I used
callouts and NOT because I spew spam (which I haven't) but only because
they - as many other similar thoughtless RBL folks - have blocked a whole
IP range where I happened to have my IP. Now, why am I being held
responsible for what other clients of the national ISP are doing?
I have already contacted my ISP to act on my behalf but frankly what
chances do I stand of them doing anything if you take into account that
this is the largest national provider?
My mail server is properly configured.
I have never sent a single spam message.
I have a revdns.
I do not use callouts.
I etc., etc.
Merit in their policy? No kidding!

Complain to the people who are using them to block you. Explain to
them why the UCEPROTECT people are stupid and they should not be
using their system. Enough of that happens and no one will use them
any more.

Chad

---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net

[W B Hacker]

Post by Chris Edwards
| > 1. People who bounce viruses with warning messages (actually, that's fine).
|
| It's not fine to _bounce_ them -- they should be rejected. Generating
| bounces in responses to viruses is bad.
I think Ian meant listing of people who bounce viruses is fine.
| Yeah, this is just the UCEPROTECT folks being muppets. I'm with Nigel;
| they're best ignored.
The classic DNSBL argument! Assuming they are muppets, they will
ultimately be ignored, with few mail admins using them to block. If
however enough mail admins are using them to block as to cause pain to
those listed, then one might at least sit and think whether or not their
listing policy has some merit afterall.

Not as they presently 'package' it. NFW!

One - or even *many* bad-actors in a netblock *cannot* justify listing the
entire block *unless* the block-holder has speciifed that MX shall not be run
from within that block.

Many *DSL / cable residential/SME bandwidth providers pre-emptively DO just that
- see SORBS - as their ToS prohibits operating MX (and/or certain other) servers
from those blocks anyway - (grant firewall rules would be better yet..)

SORBS is, in this case doing both the ISP and the community at large a visibly
useful service.

Jugenbund UCEPROTECT, OTOH, is listing entire netblocks in a very different, and
ultimately harmful, 'Catch-22' manner, as the responsibility for clearing the
problem - and keeping it clear - cannot ordinarily be readily resolved with
single-ISP or central-router firewall rulesets. Too many diverse 'necks' on
their chopping block.

One scheisspot hit every 6 days 23 hrs 59 minutes should take down a netblock
for the next 7 days? Or 50 Euros per each go?

Anybody here ever mis-type an IP?

If you want 'draconian' just drop all rDNS fails, HELO mismatches, and
(remaining) dynamic-IP sources - harming no one but your own user base.

WTH - a bit of delay per each such hit and you won't even have to tell them
*why* - most spambots will drop off the teat on their own.

Bill

[Marc Perkel]

Post by Chris Edwards
| Yeah, this is just the UCEPROTECT folks being muppets. I'm with Nigel;
| they're best ignored.
The classic DNSBL argument! Assuming they are muppets, they will
ultimately be ignored, with few mail admins using them to block. If
however enough mail admins are using them to block as to cause pain to
those listed, then one might at least sit and think whether or not their
listing policy has some merit afterall.

If you are going to run an RBL to list spammers then that's fine. If you
are going to use the same RBL to advance a political ajenda then that's
not fine. If a vendor lists servers in their spam RBL that they know
aren't spammers then they are muppets.

[Chris Lightfoot]

[...]

Post by Marc Perkel

Post by Chris Edwards
| Yeah, this is just the UCEPROTECT folks being muppets. I'm with Nigel;
| they're best ignored.
The classic DNSBL argument! Assuming they are muppets, they will
ultimately be ignored, with few mail admins using them to block. If
however enough mail admins are using them to block as to cause pain to
those listed, then one might at least sit and think whether or not their
listing policy has some merit afterall.

If you are going to run an RBL to list spammers then that's fine. If you
are going to use the same RBL to advance a political ajenda then that's
not fine. If a vendor lists servers in their spam RBL that they know
aren't spammers then they are muppets.

All blacklists are political statements. You are simply
distinguishing between the ones you like and the ones that
occasionally list addresses under your control. Remember
that whatever happens blacklists don't list ``spammers'',
who are people, but IP addresses, which are abstract
entities. At least these UCEPROTECT cretins are stating
what their stupid policies are; usually these are left
unstated or stated only implicitly.

Rather than trying to distinguish between ``permissible''
political statements, by which you mean ones which you
like (`spam is bad', `forwarding email is bad', etc.) and
``not permissible'' political statements, by which you
mean ones you don't like (`sender verification callouts
are bad'), you should be honest about the fact that you
just don't agree with the idiots in this case.

[Peter Bowyer]

Post by Marc Perkel

Post by Chris Edwards
| Yeah, this is just the UCEPROTECT folks being muppets. I'm with Nigel;
| they're best ignored.
The classic DNSBL argument! Assuming they are muppets, they will
ultimately be ignored, with few mail admins using them to block. If
however enough mail admins are using them to block as to cause pain to
those listed, then one might at least sit and think whether or not their
listing policy has some merit afterall.

If you are going to run an RBL to list spammers then that's fine. If you
are going to use the same RBL to advance a political ajenda then that's
not fine. If a vendor lists servers in their spam RBL that they know
aren't spammers then they are muppets.

Correction: As long as UCEPROTECT's policies are published and adhered
to, then the muppets are the people who blindly use their DNSBLs to
block. I could publish a DNSBL which lists all odd-numbered IPs if I
wanted to - only a fool would use that to refuse email.

Peter

[W B Hacker]

Post by Peter Bowyer
Correction: As long as UCEPROTECT's policies are published and adhered
to, then the muppets are the people who blindly use their DNSBLs to
block. I could publish a DNSBL which lists all odd-numbered IPs if I
wanted to - only a fool would use that to refuse email.

- careful!

Some folks would jump onto using that list with 'defer' acl's and try to use it
for server load-balancing....

;-)

Bill

[David Woodhouse]

Post by Chris Edwards
I think Ian meant listing of people who bounce viruses is fine.

Er, yeah. Good point.

Post by Chris Edwards
| Yeah, this is just the UCEPROTECT folks being muppets. I'm with Nigel;
| they're best ignored.
The classic DNSBL argument! Assuming they are muppets, they will
ultimately be ignored, with few mail admins using them to block. If
however enough mail admins are using them to block as to cause pain to
those listed, then one might at least sit and think whether or not their
listing policy has some merit afterall.

s/merit/marketing/ in the above.

There are always enough mail admins out there who are stupid or lazy
enough to use any given blacklist or moronic scheme if it's marketed
well, regardless of the technical merit. If they either can't or don't
want to think sensibly about it for themselves, they'll be taken in.
Just look at SPF, for example.

[Dave Pooser]

Post by David Woodhouse
There are always enough mail admins out there who are stupid or lazy
enough to use any given blacklist [...] if it's marketed well,

Doesn't have to be marketed well. I run a blacklist at $DAYJOB that's a
composite of lots of different regional blacklists based on countries where
we have no business contacts (basically Europe east of Germany, Asia, Africa
and South America). I have never advertised it as suitable for anyone else's
needs, 'cause it's not. However, in one post to a mailing list showing a
report format I failed to obfuscate the name of the blacklist, and the
report showed it blocked a lot of spam. Five years later it's still getting
queries, and I still get emails from people asking me to unblock them so
they can reach some entity I've never heard of before. I usually contact
those postmasters and they have no idea what my listing criteria are or that
there's any problem with their using a randomly selected balcklist they
found somewhere on the Net....
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"NOTHING says love like a monkey. It's a fuzzy screeching
bundle of tenderness!" -- QueenOfWands.net

[Ian Eiloart]

Post by David Woodhouse

Post by Ian Eiloart
1. People who bounce viruses with warning messages (actually, that's fine).

It's not fine to _bounce_ them -- they should be rejected. Generating
bounces in responses to viruses is bad.

Sorry, I meant it's fine to blacklist people who bounce viruses, not that
it's fine to bounce them.

[Chris Lightfoot]

Post by Ian Eiloart

Post by David Woodhouse

Post by Ian Eiloart
1. People who bounce viruses with warning messages (actually, that's fine).

It's not fine to _bounce_ them -- they should be rejected. Generating
bounces in responses to viruses is bad.

Sorry, I meant it's fine to blacklist people who bounce viruses, not that
it's fine to bounce them.

I note that (e.g.) clamav has started generating false
positives now they they try to detect ``phishing'' mail.
However, I imagine that policies like the above are
probably immutable.

[Andrew - Supernews]

Ian> 3. People using sender verification callouts. They seem to think
Ian> it's as bad as sending email,

Because ultimately it is.

Ian> but my sender verification callouts don't fill mailboxes or
Ian> server queues. And, they do stop lots of spam.

Only at the expense of others, which isn't acceptable.

[Renaud Allard]

Post by Andrew - Supernews
Ian> 3. People using sender verification callouts. They seem to think
Ian> it's as bad as sending email,
Because ultimately it is.
Ian> but my sender verification callouts don't fill mailboxes or
Ian> server queues. And, they do stop lots of spam.
Only at the expense of others, which isn't acceptable.

In a perfect world we would need neither callouts neither blacklists as
people wouldn't send spam in the first place. But we are not in a
perfect world.
It is a fact that callouts stop spam, are better than full fledged
bounces (or TMDA) and don't fill mailboxes.
It is also a fact that DNS lists that list IP ranges without any proof
of spam just prevent other people from sending ham. This is also at the
expense of these "others", which is also unacceptable.

So we are just talking on what expense is the worst.
On one hand we have much spam that is stopped at the expense of a small
bandwidth usage.
On the other hand we have ham (maybe urgent one) that is stopped just
because 1 ON on 256 or 65536 did do ONE callout which probably stopped
spam and bounces.

Which one is better?

[Andrew - Supernews]

Ian> but my sender verification callouts don't fill mailboxes or
Ian> server queues. And, they do stop lots of spam.

Post by Andrew - Supernews
Only at the expense of others, which isn't acceptable.

Renaud> In a perfect world we would need neither callouts neither
Renaud> blacklists as people wouldn't send spam in the first
Renaud> place. But we are not in a perfect world.

Spam is bad because it is the use of other people's resources without
permission.

Trying to block spam by using other people's resources without
permission is just as bad as sending spam.

Renaud> It is a fact that callouts stop spam, are better than full
Renaud> fledged bounces (or TMDA) and don't fill mailboxes.

Renaud> It is also a fact that DNS lists that list IP ranges without
Renaud> any proof of spam just prevent other people from sending
Renaud> ham. This is also at the expense of these "others", which is
Renaud> also unacceptable.

No-one's forcing you to use any DNS list. No-one's forcing you to
expend server resources in providing any DNS list. DNS lists can't
interfere with your ability to _receive_ your own mail, or to send
mail to other servers that want to receive your mail.

None of this is true for callouts. We are forced to expend server
resources in handling callouts. Our ability to receive our own
email is impaired by other people's use of callout verification.
(How well would your mailserver stand up to receiving four orders
of magnitude more connections per second than it should?)

Renaud> So we are just talking on what expense is the worst.

No. We're talking about WHOSE EXPENSE IT IS.

Expend your own resources how you choose; but once you start presuming
to think that you have some claim on other people's resources then you
have crossed the line.

[Dean Brooks]

Post by Andrew - Supernews
Renaud> In a perfect world we would need neither callouts neither
Renaud> blacklists as people wouldn't send spam in the first
Renaud> place. But we are not in a perfect world.
Trying to block spam by using other people's resources without
permission is just as bad as sending spam.

Just throwing in my opinion here, but I totally agree with Andrew on
this one. Sender verification callouts without first ensuring the
sender is sourcing from an authorized host (via SPF or other means) is
essentially as bad as spamming. Those callouts are using resources
that provide no benefit to the owner of the resources being used.

Anyone who has run a very active mail server will tell you that
callouts can use *enormous* amounts of resources if amplified
appropriately. Denial of service would be very easy with only a few
sites doing callbacks and an agressive forger. The only reason this
doesn't happen more often is very few sites use callouts (thankfully).

People who use callouts should not complain if they end up getting
blocked. If you use my server resources in a transaction where our
organization or our customers receive no benefit, then you are
commiting essentially the same ethical (if not legal) crime as a spammer.

The opinions of callouts will vary widely, I'm sure, but I think you'll
find a less favorable opinion from admins who run ISP or large corporate
mail servers.

--
Dean Brooks
***@iglou.com

[David Saez Padros]

Hi !!

Post by Dean Brooks
Anyone who has run a very active mail server will tell you that
callouts can use *enormous* amounts of resources if amplified
appropriately.

does this ever happen ??

Post by Dean Brooks
Denial of service would be very easy with only a few
sites doing callbacks and an agressive forger. The only reason this
doesn't happen more often is very few sites use callouts (thankfully).

there are more reasons ... if anyone attempts such this attack it
could be stoped very fast just blocking emails from that domain,
which could either happen because admins just realized of that
domain being widely abused or if the admin uses a domain based
blacklist. The chance of success of such this attack is very limited,
that's why spammers try to use as many domains as possible.
--
Best regards ...

The brain you have reached is out of order at this time.

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Marc Perkel]

Post by David Saez Padros
Hi !!

Post by Dean Brooks
Anyone who has run a very active mail server will tell you that
callouts can use *enormous* amounts of resources if amplified
appropriately.

does this ever happen ??

Nope - it's totally bullshit.

[Eric Kuzniar]

Post by Marc Perkel

Post by David Saez Padros

Post by Dean Brooks
Anyone who has run a very active mail server will tell you that
callouts can use *enormous* amounts of resources if amplified
appropriately.

does this ever happen ??

Nope - it's totally bullshit.

Where bullshit means, "Yes it does really happen, just hasn't
happened to me"

If you've ever been the victim of a massive joejob using one of your
domains as the sender you will understand why people implement SPF
despite it's failings and why people don't much care for sender
verification, C/R or even bounces. Thousands of connections a minute
from unique hosts asking if ***@yourdomain.com is valid user, bounces
and C/R messages all arriving in a brief period of time pushing your
mail server to the point that they can't process legitimate e-mail. The
defers piling up legitimate email on the remote-queues, all adding up
to agony that only prescription medication eases.

It's no fun to be on that end of the fence. How could that all be
avoided? Well if every single mail-server had enough horsepower to spam
and virus scan the message before doing a callout and reject it at SMTP
time then it wouldn't hurt "yourdomain.com", but reality tends to smell
less sweet. So if you accept the message and then decide it's bad you
either generate a bounce, or risk failing in your duty of providing
reliable mail delivery. Bounces will generally take more of the
resources of the victimized domain than the callout. A bounce and a
callout for a non-existant user equals the same pain on my end of the
fence, of course what's even sweeter is when someone uses SPF fails and
SV fails as a reason to bounce the message. "We didn't accept this
message because you told us that no such user exists and that it was
sent from an IP that you say doesn't send messages for you". Gee,
thanks. SMTP is an imperfect protocol for an imperfect world. Receiving
millions of connections as a result of a joejob does happen, it's not
bull, and it sucks. I don't find that the callouts are any worse than
the bounces, doesn't mean I like getting thousands of them a minute,
either. Having said all that, at least I don't have to spam and virus
scan a callout.

[Stuart Gall]

Post by Dean Brooks

Post by Andrew - Supernews
Renaud> In a perfect world we would need neither callouts neither
Renaud> blacklists as people wouldn't send spam in the first
Renaud> place. But we are not in a perfect world.
Trying to block spam by using other people's resources without
permission is just as bad as sending spam.

Just throwing in my opinion here, but I totally agree with Andrew on
this one. Sender verification callouts without first ensuring the
sender is sourcing from an authorized host (via SPF or other means) is
essentially as bad as spamming. Those callouts are using resources
that provide no benefit to the owner of the resources being used.

SPF is fairly useless, most companies will have employees traveling
and using different SMTP servers. I use smtp auth for all my clients
but even then I have come across hotels that have installed
transparent SMTP proxies and so the user has to turn smtp auth off
and use the hotels SMTP server.

Post by Dean Brooks
Anyone who has run a very active mail server will tell you that
callouts can use *enormous* amounts of resources if amplified
appropriately. Denial of service would be very easy with only a few
sites doing callbacks and an agressive forger. The only reason this
doesn't happen more often is very few sites use callouts (thankfully).

How do you know how much of this was callouts and how much was
attempted DSN's ?
So definitely failure to reject on virus, attachment, spam, user or
whatever at SMTP time is much worse than doing callouts - right
(hypothetically coz I do all this at SMTP) I am perfectly within my
rights to bounce a message back to the envelope sender address for
what ever local policy it violates also if it is refused normally I
would do at least 1 or 2 more retries with auto_thaw. This is
perfectly acceptable yet it causes more bandwidth usage than callouts

A callout is what 100 bytes ?
Nowadays using images to avoid pattern matches your average spam is
maybe 5k
So there is really no comparison on the "badness"

HOW ABOUT ...... a public callout cache ?

Post by Dean Brooks
People who use callouts should not complain if they end up getting
blocked. If you use my server resources in a transaction where our
organization or our customers receive no benefit, then you are
commiting essentially the same ethical (if not legal) crime as a spammer.
The opinions of callouts will vary widely, I'm sure, but I think you'll
find a less favorable opinion from admins who run ISP or large
corporate
mail servers.
--
Dean Brooks
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[Ian Eiloart]

Post by Stuart Gall

Post by Dean Brooks
Just throwing in my opinion here, but I totally agree with Andrew on
this one. Sender verification callouts without first ensuring the
sender is sourcing from an authorized host (via SPF or other means) is
essentially as bad as spamming. Those callouts are using resources
that provide no benefit to the owner of the resources being used.

SPF is fairly useless, most companies will have employees traveling
and using different SMTP servers. I use smtp auth for all my clients
but even then I have come across hotels that have installed
transparent SMTP proxies and so the user has to turn smtp auth off
and use the hotels SMTP server.

Yes, but that's what RFC 4409 is for. We don't currently publish SPF
records, but we don't accept email from our own domain unless it was
originally submitted to our MSA server. The policy is almost 100% effective
at keeping internal email (from and to local domains) spam free, and I've
not had many queries about it (though I did for a year or so after
implementation).

[David Saez Padros]

Hi !!

Post by Stuart Gall
SPF is fairly useless, most companies will have employees traveling
and using different SMTP servers. I use smtp auth for all my clients
but even then I have come across hotels that have installed
transparent SMTP proxies and so the user has to turn smtp auth off
and use the hotels SMTP server.

what about using the submission port 587 ?? nowadays there is no
reason why mobile users has to use other smtp servers (which in
turn on my point of view is a security/privacy problem). In the
other hand SPF allows per-user policy publishing
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Chad Leigh -- Shire.Net LLC]

Post by Dean Brooks

Post by Andrew - Supernews
Renaud> In a perfect world we would need neither callouts neither
Renaud> blacklists as people wouldn't send spam in the first
Renaud> place. But we are not in a perfect world.
Trying to block spam by using other people's resources without
permission is just as bad as sending spam.

Just throwing in my opinion here, but I totally agree with Andrew on
this one. Sender verification callouts without first ensuring the
sender is sourcing from an authorized host (via SPF or other means) is
essentially as bad as spamming. Those callouts are using resources
that provide no benefit to the owner of the resources being used.

Yes they do provide benefit. They prevent prevent full-fledged DSNs
in some cases.

And when you advertise an MX record, ie, make yourself responsible to
the world for a specific email address, you are also volunteering to
guarantee that the address is a real address. You cannot have your
cake and eat it too.

Post by Dean Brooks
Anyone who has run a very active mail server will tell you that
callouts can use *enormous* amounts of resources if amplified
appropriately. Denial of service would be very easy with only a few
sites doing callbacks and an agressive forger. The only reason this
doesn't happen more often is very few sites use callouts (thankfully).
People who use callouts should not complain if they end up getting
blocked. If you use my server resources in a transaction where our
organization or our customers receive no benefit, then you are
commiting essentially the same ethical (if not legal) crime as a spammer.

No, that is not true. You are missing the point that you have
volunteered to be responsible for that email address which includes
proving it is a valid one to people who need to know.

YOU are responsible for what happens with your email address. If you
cannot stop spam users from forging it, then you have to provide a
means to verify if it is a legit address and do all you reasonable
can to protect people from mis-use. If you do all that you can to
prevent mis-use, then legitimate mis-use that is impossible to stop
can be excused. But only if you do all that you can.

Like owning a car. If you own a car and do not lock it, leave it
running with the keys in, etc and someone steals it and runs in to
someone else, it is very possible that you can be held responsible
because you did not do everything you could to safeguard your car and
prevent illegal access to it. However, if you leave it locked,
possibly garaged, and it is nevertheless stolen, you can use a valid
defense that you did all that you were expected to do to safeguard it.

That is part of the social compact of the internet.

Chad

---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net

[David Saez Padros]

Hi !!

Post by Andrew - Supernews
Spam is bad because it is the use of other people's resources without
permission.
Trying to block spam by using other people's resources without
permission is just as bad as sending spam.

Does anyone have real statistics about that suposed resource abuse ?
I have never seen in years any of my servers being abused by callouts
and we had some email addresses that were spread in millions of users
around the world and when lots of them get infected we get many more
bounces that callouts. In the case of a server being very busy callouts
can be more a problem for the server doing them and as they are a
resource/time expensive thing to do, i supose that almost everyone
doing callouts are doing them at a last stage in the verification
process.

On our case only 0.17% of the rejections are due to sender
verifycation failures and 99.51% of the rejections are due to tests
done before doing callouts. We do not have statistics on accepted mail
but as long as we have a whitelist with all email addresses that
usually send mail to our users for which we do not do callouts and
also taking in count exim's callout cache i really doubt that callouts
could be a resource problem for other people.
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Andrew - Supernews]

Post by Andrew - Supernews
Spam is bad because it is the use of other people's resources
without permission.
Trying to block spam by using other people's resources without
permission is just as bad as sending spam.

David> Does anyone have real statistics about that suposed resource
David> abuse ?

What sort of statistics do you want?

In the best case (when there isn't a specific spammer actively forging
just our domain) we see about 100 times as many abusive callouts (ones
not in response to mail we sent) as legitimate/excusable callouts
(ones caused by mail that actually came from us), and about 10% of our
incoming SMTP connections are from blowback sources (callouts, C/R and
bounce blowback - we can't reliably distinguish them). In the worst
case, we've seen that 10% figure increase to 99.99% (i.e. around
10,000 times as many blowback connections as real mail connections).

Averaged over the past couple of years, counting all connections that
got as far as RCPT TO, _at least_ 90-95% of connections were caused by
blowback (i.e. 10 to 20 blowback connections for every real one).

(It's not the average that hurts; it's the peak load.)

David> I have never seen in years any of my servers being abused by
David> callouts

Well, lucky you. Those of us who _have_ seen it obviously have
different opinions.

David> and we had some email addresses that were spread in millions
David> of users around the world and when lots of them get infected
David> we get many more bounces that callouts.

Callouts, C/R and accept-and-bounce are all variations on a single
theme (blowback); to the third-party recipient they are mostly
identical (especially when techniques like BATV are used, resulting in
all of them being rejected at RCPT time). The recipient can't tell
them apart without actually letting in a message body (or by applying
external knowledge about the known behaviour of specific servers, such
as "if it's from sv*.verizon.net then it must have been a callout").

Nobody thinks that accept-and-bounce is acceptable any more. So why
the support for callouts and C/R? Obviously, because the people using
them see a benefit to themselves, and are happy to ignore or deny the
costs they are imposing on others -- they are parasites just as the
spammers are.

David> In the case of a server being very busy callouts can be more a
David> problem for the server doing them and as they are a
David> resource/time expensive thing to do, i supose that almost
David> everyone doing callouts are doing them at a last stage in the
David> verification process.

Optimist.

David> On our case only 0.17% of the rejections are due to sender
David> verifycation failures and 99.51% of the rejections are due to
David> tests done before doing callouts. We do not have statistics on
David> accepted mail but as long as we have a whitelist with all
David> email addresses that usually send mail to our users for which
David> we do not do callouts and also taking in count exim's callout
David> cache i really doubt that callouts could be a resource problem
David> for other people.

Having a whitelist for known _legitimate_ senders does not reduce in
any way the number of _abusive_ callouts you do, by definition.

The callout cache doesn't help significantly since spammers rarely
stick with a single sender address.

[David Saez Padros]

Hi !!

Post by Andrew - Supernews
David> Does anyone have real statistics about that suposed resource
David> abuse ?
What sort of statistics do you want?
In the best case (when there isn't a specific spammer actively forging
just our domain) we see about 100 times as many abusive callouts (ones
not in response to mail we sent) as legitimate/excusable callouts
(ones caused by mail that actually came from us), and about 10% of our
incoming SMTP connections are from blowback sources (callouts, C/R and
bounce blowback - we can't reliably distinguish them).

so for this 10% you don't know how many bounces are callouts or real
bounces ? then how you know which are abusive and which not ?

Post by Andrew - Supernews
Having a whitelist for known _legitimate_ senders does not reduce in
any way the number of _abusive_ callouts you do, by definition.

what you perceive as abusive callouts are protective in my point of view.
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Andrew - Supernews]

Post by Andrew - Supernews
In the best case (when there isn't a specific spammer actively
forging just our domain) we see about 100 times as many abusive
callouts (ones not in response to mail we sent) as
legitimate/excusable callouts (ones caused by mail that actually
came from us), and about 10% of our incoming SMTP connections are
from blowback sources (callouts, C/R and bounce blowback - we
can't reliably distinguish them).

David> so for this 10% you don't know how many bounces are callouts
David> or real bounces ? then how you know which are abusive and
David> which not ?

All of them are abusive, because all of them are an attempt to send
either a bounce, a C/R message or a callout in response to mail that
we did not send.

Post by Andrew - Supernews
Having a whitelist for known _legitimate_ senders does not reduce
in any way the number of _abusive_ callouts you do, by definition.

David> what you perceive as abusive callouts are protective in my
David> point of view.

But you're forcing me to devote _my_ resources to protecting _your_
network. How is this not abusive?

[David Saez Padros]

Hi !!

Post by Andrew - Supernews
David> what you perceive as abusive callouts are protective in my
David> point of view.
But you're forcing me to devote _my_ resources to protecting _your_
network. How is this not abusive?

First, i'm not only protecting my network, i'm also protecting your
domain from people who try to send email on your's domain behalf
to my users.

and you are missing one very important point, current smtp schema is by
itself insecure, there is no widely spread way to check that the sender
has relaly sent the message. This is a security problem that obviously
when solved will imply that the receiver host will try to check the
message auhtenticity by connecting to the sender's domain servers
(SPF, DKIM, callout, whatever ...) Will you call this abuse ?? If
you want a secure and reliable email service you will need to spent
some of your resources when other's try to validate any aspect of
any email sent using your domain.
--
Best regard ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Andrew - Supernews]

Post by Andrew - Supernews
But you're forcing me to devote _my_ resources to protecting
_your_ network. How is this not abusive?

David> First, i'm not only protecting my network, i'm also protecting
David> your domain from people who try to send email on your's domain
David> behalf to my users.

Did I ask you to do this?

David> and you are missing one very important point, current smtp
David> schema is by itself insecure, there is no widely spread way to
David> check that the sender has relaly sent the message.

And callout does NOT HELP THIS AT ALL, since the spammers are quite
happy to use sender addresses that exist.

David> This is a security problem that obviously when solved will
David> imply that the receiver host will try to check the message
David> auhtenticity by connecting to the sender's domain servers
David> (SPF, DKIM, callout, whatever ...) Will you call this abuse ??

DNS has both positive and negative caching with TTLs specified by the
publisher; it is commonly cached in ways that allow sharing of caches
over many servers and users; it's a very lightweight protocol from the
point of view of an authoritative server; it is easily scaled up; the
relevent queries for SPF, DKIM, etc., are per-domain rather than
per-user, and it _exists for the purpose of publishing information
about domains_. None of this is true for SMTP-based callouts.

[David Saez Padros]

Hi !!

Post by Andrew - Supernews
David> and you are missing one very important point, current smtp
David> schema is by itself insecure, there is no widely spread way to
David> check that the sender has relaly sent the message.
And callout does NOT HELP THIS AT ALL, since the spammers are quite
happy to use sender addresses that exist.

but they also use random addresses and addresses that no longer exist,
so callouts HELP me in rejecting that messages. Also i do not want to
accept any mail coming from non-existant addresses and the way to check
it is through callouts.

Post by Andrew - Supernews
David> This is a security problem that obviously when solved will
David> imply that the receiver host will try to check the message
David> auhtenticity by connecting to the sender's domain servers
David> (SPF, DKIM, callout, whatever ...) Will you call this abuse ??
DNS has both positive and negative caching with TTLs specified by the
publisher; it is commonly cached in ways that allow sharing of caches
over many servers and users;

callouts ara also cached and regarding dns caching i think that all
providers have their own dns caches and do not use someone else
recursive dns so dns caching is usually the same extent has callout
caching.

Post by Andrew - Supernews
it's a very lightweight protocol from the
point of view of an authoritative server; it is easily scaled up; the
relevent queries for SPF, DKIM, etc., are per-domain rather than
per-user, and it _exists for the purpose of publishing information
about domains_. None of this is true for SMTP-based callouts.

well, that's not what dns experts say, many of them said that dns txt
are being abused, also they are too small for many things (specially
if you want to keep it lighweight at udp without having to go tcp). Also
SPF can be per-user and in middle-complex cases can pass the single
query limit by far.
--
Salu-2 y hasta pronto ...

The brain you have reached is out of order at this time.

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[W B Hacker]

Post by Andrew - Supernews

Post by Andrew - Supernews
In the best case (when there isn't a specific spammer actively
forging just our domain) we see about 100 times as many abusive
callouts (ones not in response to mail we sent) as
legitimate/excusable callouts (ones caused by mail that actually
came from us), and about 10% of our incoming SMTP connections are
from blowback sources (callouts, C/R and bounce blowback - we
can't reliably distinguish them).

David> so for this 10% you don't know how many bounces are callouts
David> or real bounces ? then how you know which are abusive and
David> which not ?
All of them are abusive, because all of them are an attempt to send
either a bounce, a C/R message or a callout in response to mail that
we did not send.

Post by Andrew - Supernews
Having a whitelist for known _legitimate_ senders does not reduce
in any way the number of _abusive_ callouts you do, by definition.

David> what you perceive as abusive callouts are protective in my
David> point of view.
But you're forcing me to devote _my_ resources to protecting _your_
network. How is this not abusive?

Because, dear David, not ONE DAMN BIT of this whole smtp shebang works if we DO
NOT try to help each other within commonly agreed channels!

Handling a few liteweight verifications for others is the quid pro quo for their
also helping *you* by trying to reduce abuse *overall*.

If you are being *overwhelmed* with forgeries, try more intelligent filtering.

How many come from IP's that lack a PTR? rDNS is cached very effectively.

And how hard is it to put some /24 or /8 into your firewall that - per their own
netblock holders, not just some contentious RBL - are NOT SUPPOSED to *ever*
send mail?

Bill

[Andrew - Supernews]

W> Because, dear David, not ONE DAMN BIT of this whole smtp shebang
W> works if we DO NOT try to help each other within commonly agreed
W> channels!

I assume you're addressing me, not David.

What is "commonly agreed" about sender-verification callout? The
opinion I see of it amongst professional mail server administrators is
largely (even overwhelmingly) negative, other than a relatively small
number of smaller sites who for the most part are not finding
themselves the targets of excessive verification attempts, and
therefore don't realize the consequences of their behaviour (or don't
care).

I also don't see any justification for it in the RFCs; the command to
verify addresses is "VRFY", not "RCPT TO". Why do you think people
disable VRFY?

W> Handling a few liteweight verifications for others is the quid pro
W> quo for their also helping *you* by trying to reduce abuse
W> *overall*.

Too many assumptions in this sentence. (1) verification is not
"lightweight". (2) verification does not reduce abuse. (3)
verification does not help me.

W> If you are being *overwhelmed* with forgeries, try more
W> intelligent filtering.

It's not a case of being overwhelmed with forgeries, it's a case of
being overwhelmed by _blowback_ from forgeries sent to _other sites_.

W> How many come from IP's that lack a PTR? rDNS is cached very
W> effectively.

Callout (and other forms of blowback) is coming from _mail servers_,
and therefore the vast majority of the connections are from IPs with
valid rDNS, HELO parameters that look as reasonable as they ever do,
and from IPs that are not listed in any blacklist.

Furthermore, most of the IPs that send us blowback are doing so at
very low individual rates; it's only the aggregate of a very large
number of sources that makes it a problem.

W> And how hard is it to put some /24 or /8 into your firewall that -
W> per their own netblock holders, not just some contentious RBL -
W> are NOT SUPPOSED to *ever* send mail?

Blowback by definition comes from IPs that are supposed to send mail.

[W B Hacker]

Post by Andrew - Supernews
W> Because, dear David, not ONE DAMN BIT of this whole smtp shebang
W> works if we DO NOT try to help each other within commonly agreed
W> channels!
I assume you're addressing me, not David.

Correct! Padoname David! La culpa es mio!

Post by Andrew - Supernews
What is "commonly agreed" about sender-verification callout? The
opinion I see of it amongst professional mail server administrators is
largely (even overwhelmingly) negative, other than a relatively small
number of smaller sites who for the most part are not finding
themselves the targets of excessive verification attempts, and
therefore don't realize the consequences of their behaviour (or don't
care).
I also don't see any justification for it in the RFCs; the command to
verify addresses is "VRFY", not "RCPT TO". Why do you think people
disable VRFY?

Whole 'nuther issue...

Post by Andrew - Supernews
W> Handling a few liteweight verifications for others is the quid pro
W> quo for their also helping *you* by trying to reduce abuse
W> *overall*.
Too many assumptions in this sentence. (1) verification is not
"lightweight".

It is for-sure 'lighter' for the 'aggregate of the 'good guys' involved than
handling the spam.

Post by Andrew - Supernews
(2) verification does not reduce abuse.

In fact, it does. The argument is only over 'is it by enough to matter?' and
'is it at a reasonable cost to the community?' and 'does is place unreasonable
load on a legitimate member?'.

Post by Andrew - Supernews
(3) verification does not help me.

If you measure very narrowly, perhaps not. Neither do many of the things
involved in the 'net.

But having implemented a 60+ country X.400 network, 100% of it on *private
leased circuits*, you might give some thought to what the cost of the
alternatives were/could still be for those who do not expect to help each other.

smtp does not, in and of itself, present an invoice at month's end - but we
should expect to spend time and money to keep a 'free' service as universally
usable as practical.

*snip*

Bill

[David Saez Padros]

Hi !!

.. and about 10% of our
incoming SMTP connections are from blowback sources (callouts, C/R and
bounce blowback - we can't reliably distinguish them).
...
Averaged over the past couple of years, counting all connections that
got as far as RCPT TO, _at least_ 90-95% of connections were caused by
blowback (i.e. 10 to 20 blowback connections for every real one).

looks like you have misspelled something ... blowback connections
could be 10% or 90-95% but not both together (if i didn't miss
anything)
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Ian Eiloart]

Post by David Saez Padros

Post by Andrew - Supernews
Averaged over the past couple of years, counting all connections that
got as far as RCPT TO, _at least_ 90-95% of connections were caused by
blowback (i.e. 10 to 20 blowback connections for every real one).

looks like you have misspelled something ... blowback connections
could be 10% or 90-95% but not both together (if i didn't miss
anything)

You did. 90% blowback is the same thing as 9 blowbacks for every real one.
So, you're both wrong ;^)

[Andrew - Supernews]

.. and about 10% of our
incoming SMTP connections are from blowback sources (callouts, C/R and
bounce blowback - we can't reliably distinguish them).
...
Averaged over the past couple of years, counting all connections that
got as far as RCPT TO, _at least_ 90-95% of connections were caused by
blowback (i.e. 10 to 20 blowback connections for every real one).

David> looks like you have misspelled something ... blowback
David> connections could be 10% or 90-95% but not both together (if i
David> didn't miss anything)

You trimmed out the words "in the best case". i.e. the minimum value
seen recently is 10%, the average (mean) over a period of a couple of
years is 90-95%, and the maximum is 99.99%.

[David Saez Padros]

Hi !!

Post by Andrew - Supernews
David> looks like you have misspelled something ... blowback
David> connections could be 10% or 90-95% but not both together (if i
David> didn't miss anything)
You trimmed out the words "in the best case". i.e. the minimum value
seen recently is 10%, the average (mean) over a period of a couple of
years is 90-95%, and the maximum is 99.99%.

well, i had to say that we reject more than 99.99% of the connections
received but this does not mean that all of them are callouts. How many
of this 90-95% of blowback uses a null sender envelope ?? what do you
mean by C/R ?
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Andrew - Supernews]

Post by Andrew - Supernews
You trimmed out the words "in the best case". i.e. the minimum
value seen recently is 10%, the average (mean) over a period of a
couple of years is 90-95%, and the maximum is 99.99%.

David> well, i had to say that we reject more than 99.99% of the
David> connections received

If you get any real mail at all, then that is nonsense - you'd have to
be getting, say, a half-million connects/day and less than 50 real
emails per day, and you'll have had more than that many just from
today's traffic on exim-users.

That 99.99% peak figure was reached here during a period of a few
hours during which we received more than _10 million_ connection
attempts caused by blowback of all forms, at a domain used only by a
handful of staff which normally gets a few thousand per day.

David> but this does not mean that all of them are callouts.

As I keep saying, if you're rejecting them at RCPT time, callouts,
bounce blowback and C/R are not distinguishable.

David> How many of this 90-95% of blowback uses a null sender
David> envelope ??

Those are connections meeting the following criteria:

1) they got as far as RCPT TO
2) they had a null sender envelope, or one recognisably generated by a
C/R or callout system
3) they were not in response to real mail

Almost all had null senders.

David> what do you mean by C/R ?

Challenge/Response.

[W B Hacker]

*snip*

Post by Andrew - Supernews
That 99.99% peak figure was reached here during a period of a few
hours during which we received more than _10 million_ connection
attempts caused by blowback of all forms, at a domain used only by a
handful of staff which normally gets a few thousand per day.

Am I misreading something, or did you just indicate that a (hopefully rare!)
defect in one of your *own* hosting servers cause *your own* MX the grief?

- and you want to change the *rest* of the world for that?

??

Bill

[Andrew - Supernews]

Post by Andrew - Supernews
That 99.99% peak figure was reached here during a period of a few
hours during which we received more than _10 million_ connection
attempts caused by blowback of all forms, at a domain used only by
a handful of staff which normally gets a few thousand per day.

W> Am I misreading something, or did you just indicate that a
W> (hopefully rare!) defect in one of your *own* hosting servers
W> cause *your own* MX the grief?

Where on earth did you get that idea?

The scenario is this:

1) Some spammer (not anywhere near our network) sends out hundreds of
millions of spams using random forged addresses at our domain as the
envelope sender. These are all sent using the usual compromised
enduser hosts. (I've seen indications that some spammers do this
routinely, picking a different domain every week or so.)

2) These spams go to millions of mail servers around the world.

3) A large fraction of those servers then immediately try and
connect to _our_ MX in order to do one of three things:

a) send a bounce (everyone agrees this is bad)
b) send a challenge
c) do a sender verify callout

All of those things look the same to us. (HELO whatever; MAIL FROM:<>;
RCPT TO:<***@ourdomain>)

Result: we end up receiving 300+ SMTP connections per sec, from
millions of different IPs all of which are actually mailservers.
Blocking by IP is no help (something like 50% of the traffic last time
was from IPs that made only _one_ connection during the extent of the
attack). There is nothing else to block on since the connections are
not otherwise distinguishable from real traffic.

[W B Hacker]

Post by Andrew - Supernews

Post by Andrew - Supernews
That 99.99% peak figure was reached here during a period of a few
hours during which we received more than _10 million_ connection
attempts caused by blowback of all forms, at a domain used only by
a handful of staff which normally gets a few thousand per day.

W> Am I misreading something, or did you just indicate that a
W> (hopefully rare!) defect in one of your *own* hosting servers
W> cause *your own* MX the grief?
Where on earth did you get that idea?

From the paragraph above - w/r 'broken forms...' et al.

Post by Andrew - Supernews
1) Some spammer (not anywhere near our network) sends out hundreds of
millions of spams using random forged addresses at our domain as the
envelope sender.

OK. Story changes (again?)

C'mon! I may have been born at *night*, but it wasn't *last* night.

*snip*

Post by Andrew - Supernews
Result: we end up receiving 300+ SMTP connections per sec, from
millions of different IPs all of which are actually mailservers.
Blocking by IP is no help (something like 50% of the traffic last time
was from IPs that made only _one_ connection during the extent of the
attack). There is nothing else to block on since the connections are
not otherwise distinguishable from real traffic.

300+ /sec, yet 50% of the traffic was on ONE connection?

Dunno if it is your arithmetic, veracity, or understanding of how to configure
an MTA that is lacking - perhaps all of the above.

But I cannot help.

Gone....

Bill

[Andrew - Supernews]

[text including the phrase "blowback of all forms"]

W> Am I misreading something, or did you just indicate that a
W> (hopefully rare!) defect in one of your *own* hosting servers
W> cause *your own* MX the grief?

Post by Andrew - Supernews
Where on earth did you get that idea?

W> From the paragraph above - w/r 'broken forms...' et al.

Is English not your first language? I admit I make few concessions in
my writing to those with poor English skills, but in the above the
word "forms" is used in the general sense, in which it is synonymous
with "types", "kinds", "varieties" etc., rather than in any limited
technical sense.

Post by Andrew - Supernews
1) Some spammer (not anywhere near our network) sends out hundreds
of millions of spams using random forged addresses at our domain
as the envelope sender.

W> OK. Story changes (again?)

W> C'mon! I may have been born at *night*, but it wasn't *last* night.

um, what?

The story stays the same, I'm just explaining it in smaller words (but
obviously not small enough) and more detail.

W> *snip*

Post by Andrew - Supernews
Result: we end up receiving 300+ SMTP connections per sec, from
millions of different IPs all of which are actually mailservers.
Blocking by IP is no help (something like 50% of the traffic last
time was from IPs that made only _one_ connection during the
extent of the attack). There is nothing else to block on since the
connections are not otherwise distinguishable from real traffic.

W> 300+ /sec, yet 50% of the traffic was on ONE connection?

No, 50% of the connections were from IPs that connected only once each.

W> Dunno if it is your arithmetic, veracity, or understanding of how
W> to configure an MTA that is lacking - perhaps all of the above.

Perhaps you should brush up on your language skills?

[Marc Sherman]

Post by W B Hacker
300+ /sec, yet 50% of the traffic was on ONE connection?
Dunno if it is your arithmetic, veracity, or understanding of how to configure
an MTA that is lacking - perhaps all of the above.

Bill, you've got to try to start reading more carefully. 300+
connections per second, 50% of which were from unique sites that only
made one of those connections _each_.

- Marc

[Hill Ruyter]

Hi

I will just throw in a non-SMTP solution here

If you treat this sudden peak in traffic hitting your servers as a DDOS to
your infrastructure then the best place to stop it is at the ingress to your
network. So you have the firewall do one or more of a number of things

Limit the number of concurrent SMTP sessions fro anywhere to your mail
servers
Limit the number of new SMTP sessions per second
Limit the number of SMTP sessions from a single IP
Limit the amount of bandwidth SMTP can consume on the network

Yes I know that this will be indiscriminate. It will drop a large proportion
of legitimate mail
However as you said many of the spam servers only make a single connection
then go away and you can rest assured that if some legitimate mail was
blocked by the firewall it will be re-sent and arrive in due course if not
immediately upon initial transmission

It seems to me that the problem you described is not about resources used by
the particular purpose of the connection made to your servers but rather
the sheer volume of connections so in fact the reason for your servers
failing was not as much the processing overhead in dealing with the messages
but rather the swamped I/O of the servers/OS


What I suggest from a purely agnostic point of view having read the
arguments is that you guys get together and do a little test
One guy sets up a server and all the others first hit it with bounces and
then hit it with callouts and the results of the resource statistics are
published for comment. Otherwise I see this argument going round in circles
until we all figure out that so much time has passed something not yet
thought of has completely replaced SMTP

Yours
Hill Ruyter

----- Original Message -----
From: "Andrew - Supernews" <***@supernews.net>
To: "exim users" <exim-***@exim.org>
Sent: Wednesday, October 18, 2006 3:14 PM
Subject: Re: [exim] UCEPROTECT Blacklists and why callouts are abusive

Post by Andrew - Supernews

Post by Andrew - Supernews
That 99.99% peak figure was reached here during a period of a few
hours during which we received more than _10 million_ connection
attempts caused by blowback of all forms, at a domain used only by
a handful of staff which normally gets a few thousand per day.

W> Am I misreading something, or did you just indicate that a
W> (hopefully rare!) defect in one of your *own* hosting servers
W> cause *your own* MX the grief?
Where on earth did you get that idea?
1) Some spammer (not anywhere near our network) sends out hundreds of
millions of spams using random forged addresses at our domain as the
envelope sender. These are all sent using the usual compromised
enduser hosts. (I've seen indications that some spammers do this
routinely, picking a different domain every week or so.)
2) These spams go to millions of mail servers around the world.
3) A large fraction of those servers then immediately try and
a) send a bounce (everyone agrees this is bad)
b) send a challenge
c) do a sender verify callout
All of those things look the same to us. (HELO whatever; MAIL FROM:<>;
Result: we end up receiving 300+ SMTP connections per sec, from
millions of different IPs all of which are actually mailservers.
Blocking by IP is no help (something like 50% of the traffic last time
was from IPs that made only _one_ connection during the extent of the
attack). There is nothing else to block on since the connections are
not otherwise distinguishable from real traffic.
--
Andrew, Supernews
http://www.supernews.com
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[Andrew - Supernews]

Hill> Hi
Hill> I will just throw in a non-SMTP solution here

I'm guessing you've not experienced this yourself.

Hill> If you treat this sudden peak in traffic hitting your servers
Hill> as a DDOS to your infrastructure then the best place to stop it
Hill> is at the ingress to your network. So you have the firewall do
Hill> one or more of a number of things

Hill> Limit the number of concurrent SMTP sessions fro anywhere to
Hill> your mail servers

This is counterproductive; it makes the delays of real mail _worse_

Hill> Limit the number of new SMTP sessions per second

Same here

Hill> Limit the number of SMTP sessions from a single IP

You should probably have been doing this already

Hill> Limit the amount of bandwidth SMTP can consume on the network

Again, counterproductive

Hill> Yes I know that this will be indiscriminate. It will drop a
Hill> large proportion of legitimate mail However as you said many of
Hill> the spam servers only make a single connection then go away and
Hill> you can rest assured that if some legitimate mail was blocked
Hill> by the firewall it will be re-sent and arrive in due course if
Hill> not immediately upon initial transmission

No, the kinds of limits you suggest simply make it close to impossible
for _any_ legit email to get in until after the attack starts to
subside, which isn't the desired response in most cases.

A better approach when under any sort of blowback flood is:

- _increase_ the limit on number of concurrent SMTP sessions
- keep the limit on concurrent sessions per IP small
- disable any pre-greeting or pre-response delays
- avoid doing any DNS lookups at all (especially DNSBLs) until after
you've seen a non-null MAIL FROM
- reject for nonexistent local users early in the RCPT acl
- if you're getting excessive bounces to users that actually exist,
then employ "discard" with appropriate care

Hill> It seems to me that the problem you described is not about
Hill> resources used by the particular purpose of the connection made
Hill> to your servers but rather the sheer volume of connections so
Hill> in fact the reason for your servers failing was not as much the
Hill> processing overhead in dealing with the messages but rather the
Hill> swamped I/O of the servers/OS

Nope, the I/O overhead is nothing; the problem is the sheer number of
connections.

[David Saez Padros]

Hi !!

Post by Hill Ruyter
I will just throw in a non-SMTP solution here
If you treat this sudden peak in traffic hitting your servers as a DDOS to
your infrastructure then the best place to stop it is at the ingress to your
network. So you have the firewall do one or more of a number of things
Limit the number of concurrent SMTP sessions fro anywhere to your mail
servers
Limit the number of new SMTP sessions per second
Limit the number of SMTP sessions from a single IP
Limit the amount of bandwidth SMTP can consume on the network

exim can done most of this itself, also we use a cdb based white/blacklist
at smtp_connect so we can delay non-whitelisted hosts on peak times
and accept mail comming from whitelisted ones. On a really bad situation
this allows to get mail working (at least for whitelisted hosts) and
fast reject anything else
--
Best regards ...

The brain you have reached is out of order at this time.

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[David Saez Padros]

Hi !!

Post by Andrew - Supernews
1) Some spammer (not anywhere near our network) sends out hundreds of
millions of spams using random forged addresses at our domain as the
envelope sender. These are all sent using the usual compromised
enduser hosts. (I've seen indications that some spammers do this
routinely, picking a different domain every week or so.)

from the spammer's point of view this is very stupid as that spams
could be easely rejected. I never seen this behaviour, which does
not mean that it does not exist, but sure is very uncommon.

In the reciver point of view that kind of spam could be easely detected
without having to do callouts (helo checks, rdns, dsl/cable rbl's, even
regex detecting random parts)

From your point of view you could publish spf records so the most
strict of us could reject any spf != pass comming from a dsl/cable
zone without having to do callouts.
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[David Saez Padros]

Hi !!

Post by Andrew - Supernews
David> well, i had to say that we reject more than 99.99% of the
David> connections received
If you get any real mail at all, then that is nonsense

this is just a way to tell that we are continuosly rejecting mails
(from 300k to 1M per day) while we get only a residual number of
good emails

Post by Andrew - Supernews
and you'll have had more than that many just from
today's traffic on exim-users.

well, today is a busy day in the list

Post by Andrew - Supernews
David> but this does not mean that all of them are callouts.
As I keep saying, if you're rejecting them at RCPT time, callouts,
bounce blowback and C/R are not distinguishable.

so you are complaining that callouts are abuse but you don't even
know how many do you receive ?

Post by Andrew - Supernews
David> How many of this 90-95% of blowback uses a null sender
David> envelope ??
1) they got as far as RCPT TO
2) they had a null sender envelope, or one recognisably generated by a
C/R or callout system

how many have null envelope sender ?? this is very strange as we
rarely see any mail being rejected having a null envelope sender
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Marc Perkel]

Post by David Saez Padros
Hi !!

Post by Andrew - Supernews
Spam is bad because it is the use of other people's resources without
permission.
Trying to block spam by using other people's resources without
permission is just as bad as sending spam.

Does anyone have real statistics about that suposed resource abuse ?

Nope - those who are talking about it have no basis for that in reality
at all. It's just a fantasy reason.

[Jack Bailey]

Post by Andrew - Supernews
None of this is true for callouts. We are forced to expend server
resources in handling callouts. Our ability to receive our own
email is impaired by other people's use of callout verification.
(How well would your mailserver stand up to receiving four orders
of magnitude more connections per second than it should?)

Verizon did this to me once. A spammer was forging one of my domainnames
in a spam run so VZ was issuing 70-100 callouts/second to my server. I
had no usable mail service for hours, so I blacklisted their callout
farm. Then they blacklisted me for blacklisting their callouts.

[David Saez Padros]

Hi !!

Post by Jack Bailey

Post by Andrew - Supernews
None of this is true for callouts. We are forced to expend server
resources in handling callouts. Our ability to receive our own
email is impaired by other people's use of callout verification.
(How well would your mailserver stand up to receiving four orders
of magnitude more connections per second than it should?)

Verizon did this to me once. A spammer was forging one of my domainnames
in a spam run so VZ was issuing 70-100 callouts/second to my server. I
had no usable mail service for hours, so I blacklisted their callout
farm. Then they blacklisted me for blacklisting their callouts.

this looks like a faulty implementation, i'm sure that this 70-100
callouts/second to your server where also a problem for Verizon

all of this drives to no place ... wouldn't it be more practical to
recommend good callout practices ? in fact callouts are probably more
expensive at the sending side that at the receiving side so it's good
for both sides to reduce it's use to the minimum. Not doing callouts
for whitelisted senders/hosts, not doing them when spf=pass and doing
them at the last stage, etc ...

as callouts are good to stop spam, to enhace email realibility by
ensuring that no invalid return-path is used (also as part of BATV),
to prevent receiving bounces for invalid users, etc ... people won't
stop using them and blacklisting each other only degrades email more
than just being smart at sending/receiving callouts.
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Renaud Allard]

Post by David Saez Padros
all of this drives to no place ... wouldn't it be more practical to
recommend good callout practices ? in fact callouts are probably more
expensive at the sending side that at the receiving side so it's good
for both sides to reduce it's use to the minimum. Not doing callouts
for whitelisted senders/hosts, not doing them when spf=pass and doing
them at the last stage, etc ...

That's probably better to actually _do_ callout when spf=pass, because
you are "sure" that one the authorized IPs for the domain has sent the
mail, so you have rights to verify the address exists.
The problem with spf is that it should have been implemented from the
beggining. Now, the people who really care about setting spf are
spammers by putting an spf telling all IPs can send from their domain names.

(and, well, to be honest, I do block all mails coming from Verizon owned
domains because they just happen to blacklist everyone except the US, so
I can't answer or do callouts anyway. Verizon also recommends to use
another email provider if you really want to send mails... How amazing...)

[David Saez Padros]

Hi !!

Post by Renaud Allard
That's probably better to actually _do_ callout when spf=pass, because
you are "sure" that one the authorized IPs for the domain has sent the
mail, so you have rights to verify the address exists.

yes, but then the tested address is likely to exist so the callout will
almost always succeed. If you do the callout when spf != pass you will
honour batv (if used by the remote domain) and/or check that at least
the remote address exists.
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Renaud Allard]

Post by David Saez Padros
Hi !!

Post by Renaud Allard
That's probably better to actually _do_ callout when spf=pass, because
you are "sure" that one the authorized IPs for the domain has sent the
mail, so you have rights to verify the address exists.

yes, but then the tested address is likely to exist so the callout will
almost always succeed. If you do the callout when spf != pass you will
honour batv (if used by the remote domain) and/or check that at least
the remote address exists.

Indeed, but, as mentioned before, some will argue that if the spf is
false you have no right to use their resources to verify things as it is
probably a spam. And if spf != pass && spf != false (IE: not defined)
you still have no right to do a callout as you could be a player in a ddos.
So there is no real solution to this, the best practice would be that
the callout should be your last line of defense (just before data
session). And also that it should be avoided if the host is trusted (but
this last one is probably nearly unmaintainable for large environments).

[Chris Lightfoot]

[ attribution lost ]

Post by Renaud Allard

Post by David Saez Padros

Post by Renaud Allard
That's probably better to actually _do_ callout when spf=pass, because
you are "sure" that one the authorized IPs for the domain has sent the
mail, so you have rights to verify the address exists.

yes, but then the tested address is likely to exist so the callout will
almost always succeed. If you do the callout when spf != pass you will
honour batv (if used by the remote domain) and/or check that at least
the remote address exists.

Indeed, but, as mentioned before, some will argue that if the spf is
false you have no right to use their resources to verify things as it is
probably a spam. And if spf != pass && spf != false (IE: not defined)

This is a misconception. the fact that, say, a large ISP
publishes SPF records for some set of machines does not
mean that their customers may not send mail via other
servers. If I pay, say, AOL cash money for an AOL email
address, I'm entitled to use it however I like; and in
particular, if their outgoing email servers are broken or
are inaccessible to me at any given moment, then I'm
likely to send email via whatever server I can use, for
instance the outgoing smarthost of the ISP I'm using right
now.

[Renaud Allard]

Post by Chris Lightfoot
This is a misconception. the fact that, say, a large ISP
publishes SPF records for some set of machines does not
mean that their customers may not send mail via other
servers. If I pay, say, AOL cash money for an AOL email
address, I'm entitled to use it however I like; and in
particular, if their outgoing email servers are broken or
are inaccessible to me at any given moment, then I'm
likely to send email via whatever server I can use, for
instance the outgoing smarthost of the ISP I'm using right
now.

Indeed, however it may be blocked by servers which check spf because you
are not using AOL servers. It may also break AOL terms of service if you
send mail from another ISP (I don't know what their terms are). Many ISP
seem to say it's a breach of contract if you try to use port 25 from
your home dynamic IP (although you paid real money for internet access
as a whole).
The spf problem has already been discussed here many times. SPF should
have been mandatory in the SMTP protocol from the beginning to be efficient.

[Ian Eiloart]

Post by Chris Lightfoot

Post by Renaud Allard
Indeed, but, as mentioned before, some will argue that if the spf is
false you have no right to use their resources to verify things as it is
probably a spam. And if spf != pass && spf != false (IE: not defined)

This is a misconception. the fact that, say, a large ISP
publishes SPF records for some set of machines does not
mean that their customers may not send mail via other
servers. If I pay, say, AOL cash money for an AOL email
address, I'm entitled to use it however I like;

Except in violation of their terms of use. Presumably that means that you
can't use it in violation of their SPF policy.

[Chris Lightfoot]

[...]

Post by Ian Eiloart

Post by Chris Lightfoot

Post by Renaud Allard
Indeed, but, as mentioned before, some will argue that if the spf is
false you have no right to use their resources to verify things as it is
probably a spam. And if spf != pass && spf != false (IE: not defined)

This is a misconception. the fact that, say, a large ISP
publishes SPF records for some set of machines does not
mean that their customers may not send mail via other
servers. If I pay, say, AOL cash money for an AOL email
address, I'm entitled to use it however I like;

Except in violation of their terms of use. Presumably that means that you
can't use it in violation of their SPF policy.

it's not obvious to me that a contract written between me
and an ISP could prevent me from sending email that
doesn't go through their network at all. Has this
principle been tested?

(For reference, a quick look at AOL UK's site doesn't
suggest that they apply such a condition to their
service.)

[Ian Eiloart]

Post by Chris Lightfoot

Post by Ian Eiloart
Except in violation of their terms of use. Presumably that means that
you can't use it in violation of their SPF policy.

it's not obvious to me that a contract written between me
and an ISP could prevent me from sending email that
doesn't go through their network at all.

Well, the contract could forbid you but that might not prevent you - that's
what SPF is for. I don't know whether AOL's contract does forbid you. Even
if it doesn't explicitly forbid you, publication of SPF records implies a
policy, and your contract may require you to abide by that implied policy.

In practice, publication of SPF records will prevent you from reaching some
recipients when you violate the SPF policy. Whether AOL can be held
accountable for that, I don't know, after all AOL are only publishing
advice to the recipient's postmaster.

Post by Chris Lightfoot
Has this
principle been tested?
(For reference, a quick look at AOL UK's site doesn't
suggest that they apply such a condition to their
service.)

[David Saez Padros]

Hi !!

Post by Renaud Allard
Indeed, but, as mentioned before, some will argue that if the spf is
false you have no right to use their resources to verify things as it is
probably a spam.

this is right if the domain publishes spf, but not if it does not use
spf. Anyway, others could also argue that as the return path must be
valid they have the right to check if it's valid or not before accepting
the message.
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Ian Eiloart]

Post by Renaud Allard
Indeed, but, as mentioned before, some will argue that if the spf is
false you have no right to use their resources to verify things as it is
probably a spam. And if spf != pass && spf != false (IE: not defined)
you still have no right to do a callout as you could be a player in a ddos.

If a spammer has registered a domain, and is using that domain for sender
addresses, then there are a few possibilities:

1. They provide accurate MX records pointing to a host that they have
access to. In this case, callouts aren't going to hurt anyone - except
perhaps other users of that host.

2. They provide fake MX records, pointing to some other SMTP host. In this
case, the old arguments apply - the callouts will block spam, at some cost
to the host's owner, but at less cost than bouncing messages. Marc Perkel's
idea about rate limiting callouts per domain could be useful here.

3. They provide fake MX records, pointing to a host that is NOT an SMTP
host. In this case - I think - Exim will cache the connection failures for
the domain, and all the spam directed at a particular host will be blocked
at the cost of a single dropped connection per
callout_domain_negative_expire (which defaults to 3 hours). At least, I
think that's true. Section 39.34 says this is true of rejects before RCPT
TO, but doesn't say what happens when the connection fails.

[Stuart Gall]

Post by Renaud Allard
Indeed, but, as mentioned before, some will argue that if the spf is
false you have no right to use their resources to verify things as it is
probably a spam. And if spf != pass && spf != false (IE: not defined)
you still have no right to do a callout as you could be a player in a ddos.
So there is no real solution to this, the best practice would be that
the callout should be your last line of defense (just before data
session). And also that it should be avoided if the host is trusted (but
this last one is probably nearly unmaintainable for large
environments).

One thing exim should probably do or at least have the facility to do
is add all successful outgoing addresses to the callout cache.

Or put it another way
is there some way I can create a whitelist of all successful outgoing
envelope to's so that I can use it in the rcpt acl


Stuart

[David Saez Padros]

Hi !!

Post by Stuart Gall
One thing exim should probably do or at least have the facility to do
is add all successful outgoing addresses to the callout cache.
Or put it another way
is there some way I can create a whitelist of all successful outgoing
envelope to's so that I can use it in the rcpt acl

we actually do that by using a script in a contrab that examines exim's
logs, hope soon exim will have a 'success event handler' in the remote
transport
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Renaud Allard]

Post by Stuart Gall
Or put it another way
is there some way I can create a whitelist of all successful outgoing
envelope to's so that I can use it in the rcpt acl

Of course there is. But what if the mail account has been disabled
afterwards? How would you remove mailboxes that don't exist anymore?

[Stuart Gall]

Post by Renaud Allard

Post by Stuart Gall
Or put it another way
is there some way I can create a whitelist of all successful outgoing
envelope to's so that I can use it in the rcpt acl

Of course there is.

What is that? so far from David I have a good suggestion to use a
script to process the log. Is there a better way?

Post by Renaud Allard
But what if the mail account has been disabled
afterwards? How would you remove mailboxes that don't exist anymore?

Well I was planning time them out after some period, if no one sends
any email to them, and definitely pull them if mail is rejected.

Stuart.

[W B Hacker]

Post by Stuart Gall

Post by Renaud Allard
Indeed, but, as mentioned before, some will argue that if the spf is
false you have no right to use their resources to verify things as it is
probably a spam. And if spf != pass && spf != false (IE: not defined)
you still have no right to do a callout as you could be a player in a ddos.
So there is no real solution to this, the best practice would be that
the callout should be your last line of defense (just before data
session). And also that it should be avoided if the host is trusted (but
this last one is probably nearly unmaintainable for large
environments).

One thing exim should probably do or at least have the facility to do
is add all successful outgoing addresses to the callout cache.
Or put it another way
is there some way I can create a whitelist of all successful outgoing
envelope to's so that I can use it in the rcpt acl
Stuart

Not as fine-grained as all that but works to avoid BL'ing any <domain>.<tld>
that *any* user in *any* of our virtually-hosted domains has SENT to, and seres
as a user-controlled AWL as well:

====
warn
condition = ${lookup{$sender_host_name}dsearch{/data/mail/archive}{yes}{}}

(then set a flag and use as needed...)

ELSE just NOT the condition before blocking....

- Where '/data/mail/archive' is the outbound-archive dirtree, stored by an
'unseen' router/transport set that places them by destination <domain>.<tld>,
not sender.

Creating /data/mail/archive/<domain>.<tld> lets you manually open a hole, so
too, sending a message to the person formerly blocked.

Other rules, etc. to keep it within bounds, of course...

HTH,

Bill

[Ian Eiloart]

Post by Renaud Allard
Verizon also recommends to use
another email provider if you really want to send mails... How amazing...)

Not if they're an ISP. In that case, it's just sensible advice. Most ISPs
provide free email to lock you in to their Internet provision.

[Marc Perkel]

Post by David Saez Padros
Hi !!

Post by Jack Bailey

Post by Andrew - Supernews
None of this is true for callouts. We are forced to expend server
resources in handling callouts. Our ability to receive our own
email is impaired by other people's use of callout verification.
(How well would your mailserver stand up to receiving four orders
of magnitude more connections per second than it should?)

Verizon did this to me once. A spammer was forging one of my domainnames
in a spam run so VZ was issuing 70-100 callouts/second to my server. I
had no usable mail service for hours, so I blacklisted their callout
farm. Then they blacklisted me for blacklisting their callouts.

this looks like a faulty implementation, i'm sure that this 70-100
callouts/second to your server where also a problem for Verizon
all of this drives to no place ... wouldn't it be more practical to
recommend good callout practices ?

Generally what you want to do is block on the good blacklists, bad HELO,
verify recipient, and other blocking tricks forst and then do sender
verification last. I try to reduce callout traffic as much as I can.

[Marc Perkel]

Post by Jack Bailey

Post by Andrew - Supernews
None of this is true for callouts. We are forced to expend server
resources in handling callouts. Our ability to receive our own
email is impaired by other people's use of callout verification.
(How well would your mailserver stand up to receiving four orders
of magnitude more connections per second than it should?)

Verizon did this to me once. A spammer was forging one of my domainnames
in a spam run so VZ was issuing 70-100 callouts/second to my server. I
had no usable mail service for hours, so I blacklisted their callout
farm. Then they blacklisted me for blacklisting their callouts.

Exim caches callouts and probably should have some other features to
limit callouts to a specific server so as not to overwhelm them. I don't
know of any Exim servers who have loaded another server because of callouts.

[Chad Leigh -- Shire.Net LLC]

Post by Andrew - Supernews
Ian> but my sender verification callouts don't fill mailboxes or
Ian> server queues. And, they do stop lots of spam.

Post by Andrew - Supernews
Only at the expense of others, which isn't acceptable.

Renaud> In a perfect world we would need neither callouts neither
Renaud> blacklists as people wouldn't send spam in the first
Renaud> place. But we are not in a perfect world.
Spam is bad because it is the use of other people's resources without
permission.
Trying to block spam by using other people's resources without
permission is just as bad as sending spam.

You are not using other people's resources without permission. As
soon as you provide support for an email address, you have given
permission.

Post by Andrew - Supernews
Renaud> It is a fact that callouts stop spam, are better than full
Renaud> fledged bounces (or TMDA) and don't fill mailboxes.
Renaud> It is also a fact that DNS lists that list IP ranges without
Renaud> any proof of spam just prevent other people from sending
Renaud> ham. This is also at the expense of these "others", which is
Renaud> also unacceptable.
None of this is true for callouts. We are forced to expend server
resources in handling callouts. Our ability to receive our own
email is impaired by other people's use of callout verification.

It is part of the bargain for claiming to host an email address.

Post by Andrew - Supernews
(How well would your mailserver stand up to receiving four orders
of magnitude more connections per second than it should?)
Renaud> So we are just talking on what expense is the worst.
No. We're talking about WHOSE EXPENSE IT IS.

It is part of the expense you signed up for when you claim to provide
email services.

Chad

Post by Andrew - Supernews
Expend your own resources how you choose; but once you start presuming
to think that you have some claim on other people's resources then you
have crossed the line.
--
Andrew, Supernews
http://www.supernews.com
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net

[Ian Eiloart]

--On 17 October 2006 21:33:42 +0100 Andrew - Supernews

Post by Andrew - Supernews
Ian> 3. People using sender verification callouts. They seem to think
Ian> it's as bad as sending email,
Because ultimately it is.

So, if I stopped doing callouts, and chose to bounce spam instead, that
wouldn't be a backward step? You'd be no more unhappy for me to fill your
mailboxes with bounced spam than you are about my callouts?

[Andrew - Supernews]

Ian> 3. People using sender verification callouts. They seem to think
Ian> it's as bad as sending email,

Post by Andrew - Supernews
Because ultimately it is.

Ian> So, if I stopped doing callouts, and chose to bounce spam
Ian> instead, that wouldn't be a backward step?

False dichotomy. You're not being forced to do either.

Ian> You'd be no more unhappy for me to fill your mailboxes with
Ian> bounced spam than you are about my callouts?

If, for example, I were using BATV, how would I be able to tell the
difference?

Since there's no benefit to you in bouncing spam, whereas there _is_ a
claimed benefit in doing callouts, that means that if the practice of
doing callouts goes unchallenged and unpunished, I can expect to see
_more_ connections in the long term as a result of callouts (and C/R)
than as the result of bounced spam.

[Ian Eiloart]

--On 18 October 2006 12:37:56 +0100 Andrew - Supernews

Post by Andrew - Supernews
Ian> 3. People using sender verification callouts. They seem to think
Ian> it's as bad as sending email,

Post by Andrew - Supernews
Because ultimately it is.

Ian> So, if I stopped doing callouts, and chose to bounce spam
Ian> instead, that wouldn't be a backward step?
False dichotomy. You're not being forced to do either.

It's not a false dichotomy. I'm just trying to make you think about the
meaning of the phrase "as bad as". I think you're trying to argue that
they're both bad, and I might grant that. I won't grant that they're as bad
as each other.

[Andrew - Supernews]

Ian> So, if I stopped doing callouts, and chose to bounce spam
Ian> instead, that wouldn't be a backward step?

Post by Andrew - Supernews
False dichotomy. You're not being forced to do either.

Ian> It's not a false dichotomy. I'm just trying to make you think
Ian> about the meaning of the phrase "as bad as". I think you're
Ian> trying to argue that they're both bad, and I might grant that. I
Ian> won't grant that they're as bad as each other.

I argue that callouts are worse, since (given the existence of
measures such as BATV) the load on the recipient is the same, while
callouts are perceived as beneficial to the site that is making them,
so there's a perceived _incentive_ for them to become more widespread
(whereas bouncing spam benefits nobody).

(I say "perceived" because I am skeptical about the proportion of spam
that actually fails callout verification.)

[Renaud Allard]

Post by Andrew - Supernews
(I say "perceived" because I am skeptical about the proportion of spam
that actually fails callout verification.)

The proportion of spam that actually fails callout verification varies
from 10% to 99.99% during peaks...

[Chris Lightfoot]

[...]

Post by Renaud Allard

Post by Andrew - Supernews
(I say "perceived" because I am skeptical about the proportion of spam
that actually fails callout verification.)

The proportion of spam that actually fails callout verification varies
from 10% to 99.99% during peaks...

for a data point, here about 50% of my spam over the past
day or so has a valid sender; about 40% has an invalid
sender, and the remainder didn't complete sender
verification within the (fairly aggressive) timeout. By
comparison, about 75% of real mail has a valid sender, and
a bit under 1% an invalid sender. However, if I'd rejected
all the invalid-sender mail I would have lost (among other
mail) an important contract, some correspondence with A
Commercially Successful London Data Center Whose Owners
Are Too Incompetent To Implement SMTP[*] and various
automated mail I really did want to receive.

According to my Bayesian filter, ``SENDER_VERIFY_GOOD''
has spam probability about 0.6 (i.e., of mails given it
for training which passed sender verification, about 60%
were spam). The corresponding probability for
``SENDER_VERIFY_BAD'' is 0.93.


* -- Telecity Redbus.

[Ian Eiloart]

--On 18 October 2006 13:34:50 +0100 Andrew - Supernews

Post by Andrew - Supernews
(I say "perceived" because I am skeptical about the proportion of spam
that actually fails callout verification.)

As a quick snapshot, one of my four MX hosts has rejected 41,000 messages
today, of which 15,000 were sender verification failures. In the same time,
it accepted 4,600 inbound messages. These are messages that have passed RBL
tests and HELO string checks.

So, even if we assume that all the inbound messages were spam, sender
verification is blocking about 75% of spam that pass our IP and HELO tests.
If we assume that some of the inbound messages are ham, then sender
verification is better than 75% effective for us. So, don't let anyone tell
you that spammers tend to use valid sender addresses. Presumably the more
efficient ones might, but they're not usually using their own resources
anyway.

[Stuart Gall]

Post by Ian Eiloart
--On 17 October 2006 21:33:42 +0100 Andrew - Supernews

Post by Andrew - Supernews
Ian> 3. People using sender verification callouts. They seem to think
Ian> it's as bad as sending email,
Because ultimately it is.

So, if I stopped doing callouts, and chose to bounce spam instead, that
wouldn't be a backward step? You'd be no more unhappy for me to fill your
mailboxes with bounced spam than you are about my callouts?

You would not fill their mail boxes, the dsn would be rejected after
rcpt to: so in fact the session would be indistinguishable from a
callout.
except you will probably retry.

Post by Ian Eiloart
--
Ian Eiloart
IT Services, University of Sussex
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[David Saez Padros]

Hi !!

Post by Stuart Gall
You would not fill their mail boxes, the dsn would be rejected after
rcpt to: so in fact the session would be indistinguishable from a
callout.
except you will probably retry.

then doing a callout is the same as bouncing except that with the
callout the first message is not received and the bounce not
generated. This is a saving for the site doing the callout and
exactly the same thing for the site receiving the callout.
--
Best regards ...

----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail ***@ols.es
Pintor Vayreda 1 telf [phone]
08184 Palau-Solita i Plegamans movil [phone]
----------------------------------------------------------------

[Stuart Gall]

Post by David Saez Padros
Hi !!

Post by Stuart Gall
You would not fill their mail boxes, the dsn would be rejected
after rcpt to: so in fact the session would be indistinguishable
from a callout.
except you will probably retry.

then doing a callout is the same as bouncing except that with the
callout the first message is not received and the bounce not
generated. This is a saving for the site doing the callout and
exactly the same thing for the site receiving the callout.

No because callouts are cached, in general, for much longer than a
DSN failure would be.
also you might amass hundreds of DSNs on the queue - frozen these
will be retried (albeit once per user) until they have all expired.
You will definitely get many more connections from frozen DSNs.

There is also the advantage that you are rejecting the spammers
emails further back up the chain making it more likely they annoy
someone in a position to put a stop to them. And that is of benefit
to everyone.

Stuart.

[Dave Lugo]

Post by Ian Eiloart
So, if I stopped doing callouts, and chose to bounce spam instead, that
wouldn't be a backward step? You'd be no more unhappy for me to fill your
mailboxes with bounced spam than you are about my callouts?

You _could_ instead reject at end-of-DATA.

The result is: no callout performed, and it was really spam,
the connecting trojan/infection is unlikely to bounce the item
back to the forged sender.
--
--------------------------------------------------------
Dave Lugo ***@etherboy.com LC Unit #260 TINLC
Have you hugged your firewall today? No spam, thanks.
--------------------------------------------------------
Are you the police? . . . . No ma'am, we're sysadmins.

[Chad Leigh -- Shire.Net LLC]

Post by Andrew - Supernews
Ian> 3. People using sender verification callouts. They seem to think
Ian> it's as bad as sending email,
Because ultimately it is.
Ian> but my sender verification callouts don't fill mailboxes or
Ian> server queues. And, they do stop lots of spam.
Only at the expense of others, which isn't acceptable.

Yes it is. If someone provides email services, they accept the
responsibility for that email address and accept responsibility for
their servers being set up according to RFCs. If a provider supports
email addresss ***@manchu.com then part of that support is to verify
that the address is a valid address.

Chad

---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net

[Dave Lugo]

Post by Chad Leigh -- Shire.Net LLC
Yes it is. If someone provides email services, they accept the
responsibility for that email address and accept responsibility for
their servers being set up according to RFCs. If a provider supports
that the address is a valid address.

If you want to actually _deliver_ to it, then yes, it should
be supported.

(insert observation someone else made about VRFY being almost
universally disbabled now)

RCPT TO callouts are now bearing the burden doing something they
weren't designed for.

After hearing of friends' vanity domains being DoS'd by callbacks,
and seeing similar effects at $dayjob occasionally, I don't think
they're worth the hassle they can potentially inflict on others.
--
--------------------------------------------------------
Dave Lugo ***@etherboy.com LC Unit #260 TINLC
Have you hugged your firewall today? No spam, thanks.
--------------------------------------------------------
Are you the police? . . . . No ma'am, we're sysadmins.

[Marc Sherman]

Post by Chad Leigh -- Shire.Net LLC
Yes it is. If someone provides email services, they accept the
responsibility for that email address and accept responsibility for
their servers being set up according to RFCs. If a provider supports
that the address is a valid address.

Um, no. The RFC explicitly allows for sites refusing to support address
verification. See RFC2821, section 7.3. The RFC-blessed mechanism for
address verification is the VRFY command, and sites are perfectly within
their rights to return 252 (ie: VRFY not allowed) for all VRFY requests.
Using RCPT TO: to hack verification on a server that has made a policy
decision to disable VRFY is an abuse.

- Marc

[Stuart Gall]

Post by Ian Eiloart

Post by Zbigniew Szalbot
TXT= "Net 83.19.0.0/16 is Level 3 listed at UCEPROTECT-Network. See
http://www.uceprotect.net/en/index.php?m=7&s=8"

To be fair, they do recommend that users don't block at level 3.

Blocking the whole class B network is highly unlikely to be
restricted to the spammers
They only require 200/65535 IPs to block the lot.
It is also unclear if the 200 have to be from different class C
networks, as I read http://www.uceprotect.net/en/index.php?m=3&s=5
I understand that if 200 ips from a single class C network generate
spam then the whole class B is listed
559: Throwing the baby out with the bath water error

Post by Ian Eiloart
I still think their listing criteria are dumb. The seem to use three
1. People who bounce viruses with warning messages (actually,
that's fine).

I disagree with this, IME 99% of the time the mail is sent
automatically by the virus with a forged sender address so 99% of the
time it is wrong to bounce.
I am doing AV at SMTP time BTW

Post by Ian Eiloart
2. People who use SRS. I'd like to use it for local people that ask to get
email forwarded from their local (sussex.ac.uk) address to a personal
address. I don't see how SRS can harm anyone when I do this.
Perhaps such
email would never hit their honeypots, though.
3. People using sender verification callouts. They seem to think it's as
bad as sending email, but my sender verification callouts don't fill
mailboxes or server queues. And, they do stop lots of spam.

I think their policy is, create a spam trap, anyone that starts an
smtp session with the spam trap gets listed IRRESPECTIVE of what they
were trying to do.
Because the system is not able to determine legitimate access from
spam access.
Then find lots of sophistic arguments as to why you should be
blocking all these innocent people that have inadvertently pranged
the trap.
because they are trying to fight spam from a different angle

Stuart

PS
How about
Level 4 - block whole class A if there are 400 spammers in it
Level 5 - block all of internet if there are more than 1000 spammers
in the world

:-))
Sorry just being factious, blocking the whole class B is a bit crazy
HOWEVER, having a better granularity between /24 and /16 may have
some merit MAYBE - most ISPs have non contiguous class C net blocks
So blocking a whole /23 or /22 etc is probably useless but it is not
silly. Blocking /16 is silly

[Ian Eiloart]

Post by Ian Eiloart

Post by Zbigniew Szalbot
TXT= "Net 83.19.0.0/16 is Level 3 listed at UCEPROTECT-Network. See
http://www.uceprotect.net/en/index.php?m=7&s=8"

To be fair, they do recommend that users don't block at level 3.

Blocking the whole class B network is highly unlikely to be restricted to
the spammers
They only require 200/65535 IPs to block the lot.
It is also unclear if the 200 have to be from different class C networks,
as I read http://www.uceprotect.net/en/index.php?m=3&s=5
I understand that if 200 ips from a single class C network generate spam
then the whole class B is listed
559: Throwing the baby out with the bath water error

I agree with you, and with UCEPROTECT, that their level 3 list shouldn't be
used for rejecting email. They recommend that if it's used at all, it
should be used for scoring. I think your reading of their description is
correct, it doesn't say that more than 1 class C should be involved.

[Nigel Metheringham]

It looks like all the evidence is that UCEPROTECT are another bunch
of wannbe
RBL cowboys. Personally I intend to just ignore them.

Nigel.
--
[ Nigel Metheringham ***@InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]

[Stuart Gall]

On 17 Oct 2006, at 14:41, UCEPROTECT-Network Blacklistmaster of the

Post by UCEPROTECT-Network Blacklistmaster of the day
As we explained on our website, we consider callouts abusive,
because they
can make your system part of an ddos against others.
you will get a real feeling, why you should not use callouts.

This is a self defeating argument. If only a few "rouge" sites are
doing sender callouts then no harm is done.
If on the other hand most people are doing sender callouts then your
list is going to get poisoned very quickly.
Unless you believe you can persuade the millions of sites to stop
doing callouts.

Post by UCEPROTECT-Network Blacklistmaster of the day
Ok your system will have to deal with tons of bounces, but
additional with
all those lamerz using sender callouts.

well if you dont do a callout and for whatever reason (secondry mail
server defer for example)
the DSN gets frozen.
Then on most systems it will auto thaw and retry delivery of the DSN.
So that will be at least twice the bandwidth compared to doing callouts.

Post by UCEPROTECT-Network Blacklistmaster of the day
The problem is not that ONE connecction which you are doing. The problem is,
that you and millions of others
are trying to verify one address, which leads to a ddos against the targeted
system.
This is the reason why we are blacklisting anyone probing spamtraps of the
project.
The only difference between verifyers and for e.g. TMDA-Abusers is that no
real mail is sent by verifiers.
Anyone using sender callouts shows that he is selfish and it does
not matter to him, to be part of a ddos against third parties.

That is a rather extreme attitude. Callouts is a marginal activity at
worse. The question is do sender callouts cause more problems to
spammers or to sysadmins. IMO they cause vastly more problems for the
spammers than they do for sysadmins.

Post by UCEPROTECT-Network Blacklistmaster of the day
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/