On Fri, Apr 28, 2006 at 01:34:37PM +0200, Mariusz Kruk wrote:
> OTOH, "freedom" is not the same as "anarchy". And you can not freely go
> out on the street and shout "Mr. whatever is a fscking thief, he stole
> my 200$" justifying it by "it's the listener's choice whether he likes
> to believe it or not".

if what you're shouting is not true then you're subject to libel laws.

OTOH, if what SORBS is "shouting" is actually true (i.e. that the IP
address or the ISP responsible for that address was at one time a source
of spam) then they can publish that fact whether you like it or not.

> It's not as simple as you want it to be.

no, it's not as simple as you'd like it to be.

> Try to "just make a list" of firms who do this or do that (generaly -
> something wrong), and publish this list on the internet. Unless you
> have strong proof for your acucsations, they'll sue your pants off.

if what you say is true (and/or if you have reasonable grounds to
believe it is true) then you can say whatever you like.

even if what you are saying isn't true, anyone suing would have to prove
deliberate malicious intent on your part before they could get any
compensation (in most jurisdictions - the internet is global, different
locations have different laws).


craig

--
craig sanders (part time cyborg)


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Fri, Apr 28, 2006 at 12:28:19PM +0200, Michelle Konzack wrote:
> And as I have allready written, the domain I use is NOT public and
> only used for the french governement... It allow only connections of
> known an trusted networks (The IP's are owned by the fench Gov).

that's twice now that you have mentioned the domain you use as if it was
any way relevant. that clearly demonstrates that you don't know enough
to make any useful contribution to this topic. i advise you to do some
research on how RBLs work before you make any further comment.

to start with, you need to understand that RBLs do not list domains.
they list IP addresses.


craig

--
craig sanders (part time cyborg)


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Craig Sanders wrote:
>
> to start with, you need to understand that RBLs do not list domains.
> they list IP addresses.
>
They can also list domains:

http://www.rfc-ignorant.org/how_to_domain.php

-Roberto

--
Roberto C. Sanchez
http://familiasanchez.net/~roberto

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEVC+SjqO5DLK5e7ERAuzuAJ4ol/+0J2YdAv+4PwiMpx0TdIdd5QCgobP5
P4Nsr9OB3NxwHtv5iQc9hPo=
=LSeu
-----END PGP SIGNATURE-----

On Sat, Apr 29, 2006 at 11:31:30PM -0400, Roberto C. Sanchez wrote:
> Craig Sanders wrote:
> > to start with, you need to understand that RBLs do not list domains.
> > they list IP addresses.
>
> They can also list domains:
>
> http://www.rfc-ignorant.org/how_to_domain.php

that's:

1. a different class of thing entirely, an RHSBL rather than an RBL.

2. not relevant to the SORBS RBL which (like all other RBLs) only lists
IP addresses.



craig

--
craig sanders (part time cyborg)


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Craig Sanders wrote:
>
> that's:
>
> 1. a different class of thing entirely, an RHSBL rather than an RBL.
>
> 2. not relevant to the SORBS RBL which (like all other RBLs) only lists
> IP addresses.
>

My mistake.

-Roberto

--
Roberto C. Sanchez
http://familiasanchez.net/~roberto

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEVDIwjqO5DLK5e7ERAv6sAKCpQA80owYQn4iEIRWZbU MBpiX2MACdFKbE
EuMVsChTMqK2D5UHRof7YCM=
=OJx+
-----END PGP SIGNATURE-----

On Sat, Apr 29, 2006 at 08:33:22PM -0700, Mike Bird wrote:
> You are mistaken Craig. Consider our case. A spam was sent
> with the sender's address forged as one of SORBS's honeypots.
> Although I lot of spam is rejected during SMTP delivery, this
> was accepted and subsequently bounced. Unlike reputable RBLs,
> SORBS does not filter bounces of forgeries.

There is no valid reason whatsoever to send bounces for spam. If you have a
system that can be used as a reflector to send me spam, I personally want
it blocked. They are basically behaving as open relays, they only add an
error header.

All well designed MTA's are built so that all instances on a system can
refuse undeliverable mail during the SMTP transaction. Dropping spam after
that should be done silently, via a quarantine, or not at all. Even
substandard MTA's such as qmail tend to have 3rd party patches to fix this
security vulnerability.

Reflectors have been used for so much abuse, both spam and denial of service
(not limited to email) attacks that there really is no excuse.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEVI2cRGhQc/k/gTsRAhWaAKCmaIBpxqrIFPggumvTraD/1fJEwwCeJfb8
T/0CY9BTINPdRtXHdMm4HZ4=
=eLex
-----END PGP SIGNATURE-----

> even if what you are saying isn't true, anyone suing would have to prove
> deliberate malicious intent on your part before they could get any
> compensation (in most jurisdictions - the internet is global, different
> locations have different laws).
>
In the US, the plaintiff has to prove either malicious intent or (and this is
the important one, I think) reckless disregard for the truth. SORBS policy
explicitly states that they will not de-list you without paying their "fine",
even if you can prove that you were given an already blacklisted address from
an upstream provider and are not a spammer yourself. Sounds like reckless
disregard for the truth to me.
--
Peter A. Dumpert
Innovative Computer Services, LLC
www.innovativebusiness.net
Phone: 732-683-0092 ext 102 Fax: 732-577-9390





--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sunday 30 April 2006 20:43, Pete Dumpert wrote:
> > even if what you are saying isn't true, anyone suing would have to prove
> > deliberate malicious intent on your part before they could get any
> > compensation (in most jurisdictions - the internet is global, different
> > locations have different laws).
>
> In the US, the plaintiff has to prove either malicious intent or (and this
> is the important one, I think) reckless disregard for the truth. SORBS
> policy explicitly states that they will not de-list you without paying
> their "fine", even if you can prove that you were given an already
> blacklisted address from an upstream provider and are not a spammer
> yourself. Sounds like reckless disregard for the truth to me.

Hmm.. lets look at how you being assigned an old spammers IP address changes
the truth... "it doesnt".


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Pete Dumpert said the following on 04/30/2006 08:43 AM:

> In the US, the plaintiff has to prove either malicious intent or (and this is
> the important one, I think) reckless disregard for the truth. SORBS policy
> explicitly states that they will not de-list you without paying their "fine",
> even if you can prove that you were given an already blacklisted address from
> an upstream provider and are not a spammer yourself. Sounds like reckless
> disregard for the truth to me.

Actually, that "actual malice or reckless disregard of the truth"
standard applies only to "public figures" (it's called the "New York
Times test" from New York Times v. Sullivan). If the plaintiff is not a
public figure, the traditional defamation standard. In general, a
public figure is someone like a politician or a public figure.

The standard for other plaintiffs, which varies a bit state-by-state,
requires (a) a defamatory statement (b) published to third parties which
(c) the speaker or publisher knew or should have known was false (that
third requirement is relatively new and may not apply in all cases).

Just what is a "defamatory statement" gets interesting, but in general,
it's a statement that "tends to injure the plaintiff's reputation and
expose the plaintiff to public hatred, contempt, ridicule or
degradation" (quote from a Minnesota case).

John


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, 30 Apr 2006, Juha-Matti Tapio wrote:
> There is no valid reason whatsoever to send bounces for spam. If you have a

What should happen when someone sends mail from a spam trap [yes, forged],
to a valid address, WITHOUT any spam content (or content not filtered as
spam, it is the same), and that valid address bounces because its inbox is
full?

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Apr 30, 2006 at 01:56:40PM +0000, Andy Smith wrote:
> On Sun, Apr 30, 2006 at 10:57:28AM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 30 Apr 2006, Juha-Matti Tapio wrote:
> > > There is no valid reason whatsoever to send bounces for spam. If you have a
> >
> > What should happen when someone sends mail from a spam trap [yes, forged],
> > to a valid address, WITHOUT any spam content (or content not filtered as
> > spam, it is the same), and that valid address bounces because its inbox is
> > full?
>
> Such a delivery failure should be rejected with a temp. failure
> which would not generate a bounce to the forged address.

Not always true:

1. sender forges address and sends off e-mail
2. intermediary mailserver accepts mail and tries to deliver to destination
3. destination rejects with temp failure
4. intermediary tries a few more times, and eventually gives up
5. intermediary *generates bounce* to forged sender

Making the argument that there should never be bounces is silly.

Ward.

--
Pong.be -( "If you think penguins are fat and waddle, you have )-
Virtual hosting -( never been attacked by one running at you in excess of )-
http://pong.be -( 100 MPH." -- Linus )-
GnuPG public key: http://gpg.dtype.org


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Apr 30, 2006 at 10:57:28AM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 30 Apr 2006, Juha-Matti Tapio wrote:
> > There is no valid reason whatsoever to send bounces for spam. If you have a
>
> What should happen when someone sends mail from a spam trap [yes, forged],
> to a valid address, WITHOUT any spam content (or content not filtered as
> spam, it is the same), and that valid address bounces because its inbox is
> full?

Such a delivery failure should be rejected with a temp. failure
which would not generate a bounce to the forged address.

--
http://strugglers.net/wiki/Xen_hosting -- A Xen VPS hosting hobby
Encrypted mail welcome - keyid 0x604DE5DB

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEVMIXIJm2TL8VSQsRAgL4AJ0Rql+ilZKOwrNDDCqWwQ bTD7wHXwCg1gwl
WKaSMdvQcfnAbg3OAHMt2SM=
=qYOe
-----END PGP SIGNATURE-----

* Andy Smith (andy@lug.org.uk) [060430 16:03]:
> On Sun, Apr 30, 2006 at 10:57:28AM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 30 Apr 2006, Juha-Matti Tapio wrote:
> > > There is no valid reason whatsoever to send bounces for spam. If you have a
> >
> > What should happen when someone sends mail from a spam trap [yes, forged],
> > to a valid address, WITHOUT any spam content (or content not filtered as
> > spam, it is the same), and that valid address bounces because its inbox is
> > full?
>
> Such a delivery failure should be rejected with a temp. failure
> which would not generate a bounce to the forged address.

Unless it stays a temporary failure until the retry time expires. Might
happen with users who read mail once per 14 days.


Cheers,
Andi
--
http://home.arcor.de/andreas-barth/


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Apr 30, 2006 at 10:08:02AM -0400, Ward Vandewege wrote:
> On Sun, Apr 30, 2006 at 01:56:40PM +0000, Andy Smith wrote:
> > On Sun, Apr 30, 2006 at 10:57:28AM -0300, Henrique de Moraes Holschuh wrote:
> > > On Sun, 30 Apr 2006, Juha-Matti Tapio wrote:
> > > > There is no valid reason whatsoever to send bounces for spam. If you have a
> > >
> > > What should happen when someone sends mail from a spam trap [yes, forged],
> > > to a valid address, WITHOUT any spam content (or content not filteredas
> > > spam, it is the same), and that valid address bounces because its inbox is
> > > full?
> >
> > Such a delivery failure should be rejected with a temp. failure
> > which would not generate a bounce to the forged address.
>
> Not always true:
>
> 1. sender forges address and sends off e-mail
> 2. intermediary mailserver accepts mail and tries to deliver to destination
> 3. destination rejects with temp failure
> 4. intermediary tries a few more times, and eventually gives up
> 5. intermediary *generates bounce* to forged sender

Well sure but that is not the problem or concern of the receiving
site, which is what I thought this was about.

If the forwarding host and the receiving site are actually part of
the same organisation then they should be trying to push out the
knowledge of users and mailboxes to their edge so that the
forwarding hosts don't have to accept mail they can't/won't deliver.

> Making the argument that there should never be bounces is silly.

It's something that I believe should be aimed for whenever possible,
but in the real world I agree that it is not always possible.

--
http://strugglers.net/wiki/Xen_hosting -- A Xen VPS hosting hobby
Encrypted mail welcome - keyid 0x604DE5DB

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEVMTQIJm2TL8VSQsRAkssAJwJ+yKXtMZNOBNI9vHWLp iRSb3cAQCfbFBt
Ll+OY4qZ70qobQMrcRV+TyI=
=7omY
-----END PGP SIGNATURE-----

On Sun, Apr 30, 2006 at 10:08:02AM -0400, Ward Vandewege wrote:
> 1. sender forges address and sends off e-mail
> 2. intermediary mailserver accepts mail and tries to deliver to destination

In this scenario the sender is supposedly within the authority of the
intermediary mailserver and the mailserver's admin needs to take care of
spamming in exactly the same way he would do when the recipient is
deliverable.

I am not opposed of smarthosts, they are a good thing because they make it
possible to do spam checks for outgoing mail and they also make it easier to
keep track of mail flow.

> Making the argument that there should never be bounces is silly.

Bounces are so fundamental to email that we can never get rid of them, but
they are very problematic and risky when they are sent across organisation
boundaries. If someone insists on sending bounces because of forged
recipients or full mailboxes, they should be prepared to accept the
problems that will eventually arise from them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEVM8eRGhQc/k/gTsRAnQ2AKCZpVQOQTPu2Pt3hq20kLrTk/MmLwCfc+4G
2C822Uilzw0qn9Mtri+Ihzs=
=Rc4h
-----END PGP SIGNATURE-----

On Sun, Apr 30, 2006 at 10:57:28AM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 30 Apr 2006, Juha-Matti Tapio wrote:
> > There is no valid reason whatsoever to send bounces for spam. If you have a
> What should happen when someone sends mail from a spam trap [yes, forged],
> to a valid address, WITHOUT any spam content (or content not filtered as
> spam, it is the same), and that valid address bounces because its inbox is
> full?

I have always solved this by not connecting mailbox fullness directly to
cutting mail flow. If the mailbox goes over the quota, I would only then put
delivery to hold so that temporary error can be returned during SMTP
transactions. Once the incoming message has been accepted, it is already
taking disk space on the server and it might just as well be delivered even
if the box overflows.

Usually quota is placed to either protect the system from sudden disk space
starvation and/or due to business reason. In both cases it is not necessary
to prevent a small overrun in disk usage in the short time between the
mailbox becoming full and before the inbound SMTP servers know about it.

If I were dependent on a mailbox with quota, I would really appreciate it if
the admins gave me some slack so that I would have a bit time to clean up
before incoming mail was cut off.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEVNJ3RGhQc/k/gTsRAsjJAKCsRovO28GXXMk9CP4Jqi8RaPidxgCgmMDf
B3MsW22sS6GUHU7FVsEQT1w=
=Tbpk
-----END PGP SIGNATURE-----

On Sun, 2006-04-30 at 08:06, Juha-Matti Tapio wrote:
> On Sun, Apr 30, 2006 at 10:57:28AM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 30 Apr 2006, Juha-Matti Tapio wrote:
> > > There is no valid reason whatsoever to send bounces for spam. If you have a
> > What should happen when someone sends mail from a spam trap [yes, forged],
> > to a valid address, WITHOUT any spam content (or content not filtered as
> > spam, it is the same), and that valid address bounces because its inbox is
> > full?
>
> I have always solved this by not connecting mailbox fullness directly to
> cutting mail flow. If the mailbox goes over the quota, I would only then put
> delivery to hold so that temporary error can be returned during SMTP
> transactions. Once the incoming message has been accepted, it is already
> taking disk space on the server and it might just as well be delivered even
> if the box overflows.
>
> Usually quota is placed to either protect the system from sudden disk space
> starvation and/or due to business reason. In both cases it is not necessary
> to prevent a small overrun in disk usage in the short time between the
> mailbox becoming full and before the inbound SMTP servers know about it.
>
> If I were dependent on a mailbox with quota, I would really appreciate it if
> the admins gave me some slack so that I would have a bit time to clean up
> before incoming mail was cut off.

I think you're following the logic already followed by many ISPs.
The next step is to consider what should happen after the message
has been in the recipient's ISP's mail queue for a few days.
Perhaps the recipient is on vacation. The only sensible course
is to bounce the message (hoping that the sender was not forged)
so that legit senders know that the message has not been
received. Otherwise, you might as well forget reliable SMTP
delivery and just send an instant message hoping the recipient
is watching.

Bounces should be minimized. In many circumstances, they cannot
be avoided.

SORBS is the only well-known RBL which lists IPs for backscatter
as a result of SORBS' own honeypot addresses being compromised.

SORBS is the only well-known RBL which demands a delisting fee.

SORBS is just not worth the hassle when there are so many good
RBLs.

--Mike Bird


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

I think we can put this to rest. SORBS is not only clueless,
it is hypocritical.

SORBS backscatters off of its own secondary MX. (Proofs
below - easy to replicate.)

Drop SORBS. Use several reliable RBLs. Minimize bounces.

Next topic please.

--Mike Bird


*** THE TEST MESSAGE TO SORBS SECONDARY MX ***

# telnet scorpion.sorbs.net smtp
Trying 203.15.51.56...
Connected to scorpion.sorbs.net.
Escape character is '^]'.
220 scorpion.sorbs.net ESMTP SORBS v0.97 WARNING: Sending Unsolicited
E-Mail to/via this server will result in a US$50 charge per e-mail.
HELO yosemite.net
250 scorpion.sorbs.net
MAIL From: mgb-debian@yosemite.net
250 Ok
RCPT To: sorbs-backscatters-too@sorbs.net
250 Ok
DATA
354 End data with .
Subject: BACKSCATTER TEST

WARNING: Bouncing this email will result in a US$100 charge per e-mail.

--Mike Bird / mgb-debian@yosemite.net
5320 Hwy 49 N #5 Mariposa CA 95338
This message is not from a mailing list
..
250 Ok: queued as D16ADA6C2C
quit
221 Bye
Connection closed by foreign host.



*** THE BOUNCE FROM SORBS ***

This is the Postfix program at host scorpion.sorbs.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The Postfix program

: host
desperado-int.sorbs.net[203.15.51.58]
said: 550 : Recipient address
rejected:
User unknown in local recipient table (in reply to RCPT TO command)



--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>
>> 1. sender forges address and sends off e-mail
>> 2. intermediary mailserver accepts mail and tries to deliver to
>> destination
>> 3. destination rejects with temp failure
>> 4. intermediary tries a few more times, and eventually gives up
>> 5. intermediary *generates bounce* to forged sender

....
>
>
> If the forwarding host and the receiving site are actually part of
> the same organisation then they should be trying to push out the
> knowledge of users and mailboxes to their edge so that the
> forwarding hosts don't have to accept mail they can't/won't deliver.

This argument seems to becoming a religious discussion regarding
point 2.
- - Accepting mails for a domain before know whether the person really
exists.

The mail protocol still allows for this.

Maybe this is something that should at some stage be considered bad
practice?

Many small companies have this problem, ie: protection your MS
Exchange Server
behind a postfix server... How do you want them ALL to fix this?
There are
unfortunately no - out of the box scripts to query your exchange
server and
fill your mail server configs.

There are surely many more reasons that makes disabling feature '2' very
difficult. - But maybe we should work in that direction.

I hope the people from SORBs are reading this list and that they too are
thinking about how to solve the problem, and not add to it.

The times I have had this problem, I have spoken to the admins of the
sites
using RBL and informed them of the problem. If they want
Internet
Connectivity, they need to fix the problem - if not - that's there
problem -
or perhaps tell their customers to get free mail addresses somewhere
else
until they have! :-)


Regards

Andrew

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEVOSfW126qUNSzvURAixfAJkB+d3xLyG2a58XiqMzfe gvtZkeigCfQJfe
WJPUKSz5J1JYBSOJ6zoGluA=
=HVsM
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org