OT: sorbs blacklisting scam - Debian

This is a discussion on OT: sorbs blacklisting scam - Debian ; This one time, at band camp, Andrew Miehs said: > > This argument seems to becoming a religious discussion regarding > point 2. - Accepting mails for a domain before know whether the > person really exists. > > The ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 66

Thread: OT: sorbs blacklisting scam

  1. Re: OT: sorbs blacklisting scam

    This one time, at band camp, Andrew Miehs said:
    >
    > 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?


    It is already strongly discouraged.

    > 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 plenty of ways to do this - exim can do recipient callout
    verification. Sendmail, postfix, and exim at least can query the LDAP
    interface that AD provides. There are other ways of doing this
    statitcally as well, like grabbing a list of valid usernames once every
    so often. Having a stupid backend is no excuse for being a stupid
    frontend.

    Take care,
    --
    -----------------------------------------------------------------
    | ,''`. Stephen Gran |
    | : :' : sgran@debian.org |
    | `. `' Debian user, admin, and developer |
    | `- http://www.debian.org |
    -----------------------------------------------------------------

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

    iD8DBQFEVOctSYIMHOpZA44RAgdUAJ4vQcOqcXj6prLQQotlEh KsgdpMcQCdFMVl
    Ar7CBCXzR4Z/q0HicCZFS9A=
    =Agb/
    -----END PGP SIGNATURE-----


  2. Re: OT: sorbs blacklisting scam

    On Sun, Apr 30, 2006 at 09:03:03AM -0700, Mike Bird wrote:
    > 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.


    I think this is the worst possible way to handle full mailboxes. I think
    that if the message is accepted for delivery to local mailbox, it is better
    to bite the bullet and just deliver it. If I send someone email, I would
    expect that if the servers are up and they accept the mail, it does not
    silently sleep in the queue for days. If there are warning bounces and a
    rejection bounce, the backscatter problem keeps on multiplying and if there
    are no warnings, the sender will falsely believe that the message has been
    delivered.

    I think bouncing immediately is better than to wait, warn, warn again and
    then bounce. But the best resolution is to just deliver it at update the
    front servers to temporarily reject further messages.

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


    True. Absolutely.

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


    It might be a good idea for other lists to start doing also.


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

    iD8DBQFEVPcIRGhQc/k/gTsRAutkAKCYJwe2np/3GsPyDUWeFJn7xT9XBgCfU01m
    rg45SchyDTGa98NroTU75iM=
    =bSvi
    -----END PGP SIGNATURE-----


  3. Re: OT: sorbs blacklisting scam

    On Sun, 2006-04-30 at 10:42, Juha-Matti Tapio wrote:
    > I think this is the worst possible way to handle full mailboxes. I think
    > that if the message is accepted for delivery to local mailbox, it is better
    > to bite the bullet and just deliver it. If I send someone email, I would
    > expect that if the servers are up and they accept the mail, it does not
    > silently sleep in the queue for days. If there are warning bounces and a
    > rejection bounce, the backscatter problem keeps on multiplying and if there
    > are no warnings, the sender will falsely believe that the message has been
    > delivered.


    A quota which is not enforced is not a quota. Without user
    quotas you are susceptible to a single accidental or
    deliberate DOS attack blocking email for all users instead of
    a small number.

    Example, based on incidents I have actually witnessed:

    Clueless Relative emails an enormous attachment to Hapless
    Recipient. Because we minimize backscatter we check for
    viruses during the SMTP transaction. Clueless Relative's
    ISP times out on the SMTP transaction after end of data
    while the anti-virus is staggering through the enormous
    attachment. Clueless Relative's ISP sends the message
    again a few minutes later. And again. And again.

    With user quotas enforced only hapless recipient's mailbox
    is full.

    Without user quotas, your whole mail spool is full and
    nobody can receive email.

    --Mike Bird



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

  4. Re: OT: sorbs blacklisting scam

    On Sun, 30 Apr 2006, Juha-Matti Tapio wrote:
    > > SORBS is the only well-known RBL which lists IPs for backscatter
    > > as a result of SORBS' own honeypot addresses being compromised.

    >
    > It might be a good idea for other lists to start doing also.


    I sure hope not. Are you aware that you are advocating killing the *only*
    back-channel SMTP has?

    Hint: you want to fix that channel to be validated, NOT to kill it.

    --
    "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

  5. Re: OT: sorbs blacklisting scam

    On Sun, 30 Apr 2006, Andrew Miehs wrote:
    > This argument seems to becoming a religious discussion regarding
    > point 2.


    Only for those who still think there is an easy answer. The scenario I
    proposed had NO blind user forwarding. It involves a *perfectly valid*
    email delivery, one that is not spam, but has been forged to come from a
    spam trap. If you cannot see past the "quota full" reason, then I can give
    you a pletora of others, such as IO error on the spool, resource starvation
    on the spool machine, network problems internal to the ISP, and even a
    completely sane, properly implemented "vacation" message that would *never*
    be sent again to the same sender.

    --
    "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

  6. Re: OT: sorbs blacklisting scam

    This one time, at band camp, Mike Bird said:
    > On Sun, 2006-04-30 at 10:42, Juha-Matti Tapio wrote:
    > > I think this is the worst possible way to handle full mailboxes. I think
    > > that if the message is accepted for delivery to local mailbox, it is better
    > > to bite the bullet and just deliver it. If I send someone email, I would
    > > expect that if the servers are up and they accept the mail, it does not
    > > silently sleep in the queue for days. If there are warning bounces and a
    > > rejection bounce, the backscatter problem keeps on multiplying and if there
    > > are no warnings, the sender will falsely believe that the message has been
    > > delivered.

    >
    > A quota which is not enforced is not a quota. Without user
    > quotas you are susceptible to a single accidental or
    > deliberate DOS attack blocking email for all users instead of
    > a small number.


    You have entirely failed to miss the point. Once you have accepted a
    message, you are wasting disk space _now_, so there is no point keeping
    the message in the mail spool as opposed to in the users mail box.

    The point is to know that the user's mail box is full and _not accept
    any more_ messages for that user. Creating backscatter because you
    can't configure your organizations mail spool so that the left hand
    knows about the right hand is still bad form.

    Take care,
    --
    -----------------------------------------------------------------
    | ,''`. Stephen Gran |
    | : :' : sgran@debian.org |
    | `. `' Debian user, admin, and developer |
    | `- http://www.debian.org |
    -----------------------------------------------------------------

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

    iD8DBQFEVUC4SYIMHOpZA44RArtLAKC/8276aCNLHXkfKULV1XDRQ7tVAACgt0Nl
    4pTv7Brb2pjMrTqS7jckO2I=
    =gVb0
    -----END PGP SIGNATURE-----


  7. Re: OT: sorbs blacklisting scam

    On Sun, 2006-04-30 at 15:56, Stephen Gran wrote:
    > You have entirely failed to miss the point.


    Well I'm glad we agree on one thing.

    > Once you have accepted a
    > message, you are wasting disk space _now_, so there is no point keeping
    > the message in the mail spool as opposed to in the users mail box.


    Your mail server has the queue in the same partition as
    the mailboxes? Wierd. All that unnecessary quota activity.

    > The point is to know that the user's mail box is full and _not accept
    > any more_ messages for that user.


    You are arguing against providing a safety net. We hold inbound
    messages in a queue for several days (space permitting) just like
    outbound messages. This is an added-value service which helps
    to prevent people from losing email when some twit has filled
    their mailbox and someone else is sending from an ISP with a
    retry timeout less than a typical human's sleep cycle.

    > Creating backscatter because you
    > can't configure your organizations mail spool so that the left hand
    > knows about the right hand is still bad form.


    This thread has already mentioned numerous cases where
    backscatter is unavoidable. Please post your Exim config
    which handles such cases without backscatter. If it's
    that good, I'll even switch our combination of Postfix,
    QMail, and custom SMTP code over to Exim.

    --Mike Bird


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

  8. Re: OT: sorbs blacklisting scam

    This one time, at band camp, Mike Bird said:
    > On Sun, 2006-04-30 at 15:56, Stephen Gran wrote:
    > > Once you have accepted a message, you are wasting disk space _now_,
    > > so there is no point keeping the message in the mail spool as
    > > opposed to in the users mail box.

    >
    > Your mail server has the queue in the same partition as the mailboxes?
    > Wierd. All that unnecessary quota activity.


    *sigh* Again with the missing the obvious.

    All I am pointing out is that once you have accepted a message, you are
    wasting your organization's storage and resources already, so I don't
    really see the harm in dropping it in the user's mailbox and
    incrementing their quota information.

    > > The point is to know that the user's mail box is full and _not
    > > accept any more_ messages for that user.

    >
    > You are arguing against providing a safety net. We hold inbound
    > messages in a queue for several days (space permitting) just like
    > outbound messages. This is an added-value service which helps to
    > prevent people from losing email when some twit has filled their
    > mailbox and someone else is sending from an ISP with a retry timeout
    > less than a typical human's sleep cycle.


    The sender gets a DSN saying "Sorry, your mail didn't get delivered"
    either way, right? Do you really think that creating the bounce message
    yourself is better in some way than having the sending MTA create it?

    > > Creating backscatter because you can't configure your organizations
    > > mail spool so that the left hand knows about the right hand is still
    > > bad form.

    >
    > This thread has already mentioned numerous cases where backscatter is
    > unavoidable. Please post your Exim config which handles such cases
    > without backscatter. If it's that good, I'll even switch our
    > combination of Postfix, QMail, and custom SMTP code over to Exim.


    Since exim can do arbitrary lookups in a number of backends, it would
    be trivial to store quota information in sql, ldap, flat files or cdb on
    shared storage, or whatever other signalling mechanism you can think of to
    communicate state. As for config file snippets, the first hit on google
    for 'exim quota sql' takes you to a discussion of how to implement it.
    I look forward to another qmail installation disappearing. It seems to
    be one of the primary agents of backscatter spam on the public internet.

    You seem to be conflating unavoidable DSNs and DSNs created due to
    software or admin created constraints. They are not the same.
    --
    -----------------------------------------------------------------
    | ,''`. Stephen Gran |
    | : :' : sgran@debian.org |
    | `. `' Debian user, admin, and developer |
    | `- http://www.debian.org |
    -----------------------------------------------------------------

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

    iD8DBQFEVUjLSYIMHOpZA44RApH+AKCf9QORY4ozhrFat3xYoi Amp/1TuwCfdLGc
    xpxfZ1PtAI6MJh+TBzPZSok=
    =3YSL
    -----END PGP SIGNATURE-----


  9. Re: OT: sorbs blacklisting scam

    On Sun, 2006-04-30 at 16:31, Stephen Gran wrote:
    > This one time, at band camp, Mike Bird said:
    > > You are arguing against providing a safety net. We hold inbound
    > > messages in a queue for several days (space permitting) just like
    > > outbound messages. This is an added-value service which helps to
    > > prevent people from losing email when some twit has filled their
    > > mailbox and someone else is sending from an ISP with a retry timeout
    > > less than a typical human's sleep cycle.

    >
    > The sender gets a DSN saying "Sorry, your mail didn't get delivered"
    > either way, right? Do you really think that creating the bounce message
    > yourself is better in some way than having the sending MTA create it?


    Yes, because our timeout is longer than that of some ISPs.
    Some ISPs are using two or four hour timeouts. I'd rather
    not have to tell our clients that they need to wake up every
    90 minutes and empty their mailboxes to avoid losing messages.

    > > > Creating backscatter because you can't configure your organizations
    > > > mail spool so that the left hand knows about the right hand is still
    > > > bad form.

    > >
    > > This thread has already mentioned numerous cases where backscatter is
    > > unavoidable. Please post your Exim config which handles such cases
    > > without backscatter. If it's that good, I'll even switch our
    > > combination of Postfix, QMail, and custom SMTP code over to Exim.

    >
    > Since exim can do arbitrary lookups in a number of backends, it would
    > be trivial to store quota information in sql, ldap, flat files or cdb on
    > shared storage, or whatever other signalling mechanism you can think of to
    > communicate state. As for config file snippets, the first hit on google
    > for 'exim quota sql' takes you to a discussion of how to implement it.
    > I look forward to another qmail installation disappearing. It seems to
    > be one of the primary agents of backscatter spam on the public internet.


    If Exim can do it then so can a Turing machine. Claiming that
    a solution exists is not the same as providing a solution.

    We're look forward to seeing your Exim config that avoids
    all of the potential causes of backscatter previously
    identified in this thread. Then we'll see if the reduced
    performance and/or functionality are worthwhile tradeoffs.

    Thanks,

    --Mike Bird


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

  10. Re: OT: sorbs blacklisting scam

    On Sun, Apr 30, 2006 at 09:13:39AM -0400, John Ackermann N8UR wrote:
    > 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).


    and an RBL listing is a statement that spam has been received from a
    particular IP address - this is 1. a statement of verifiable fact (i.e.
    "truth"), and 2. not a defamatory statement - it identifies only an
    *IP Address*, it does not identify any particular individual (i.e. the
    plaintiff) so can not injure their reputation or expose them to public
    hatred, contempt, ridicule or degradation.


    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

  11. Re: OT: sorbs blacklisting scam

    This one time, at band camp, Mike Bird said:
    > On Sun, 2006-04-30 at 16:31, Stephen Gran wrote:
    > > This one time, at band camp, Mike Bird said:
    > > > You are arguing against providing a safety net. We hold inbound
    > > > messages in a queue for several days (space permitting) just like
    > > > outbound messages. This is an added-value service which helps to
    > > > prevent people from losing email when some twit has filled their
    > > > mailbox and someone else is sending from an ISP with a retry
    > > > timeout less than a typical human's sleep cycle.

    > >
    > > The sender gets a DSN saying "Sorry, your mail didn't get delivered"
    > > either way, right? Do you really think that creating the bounce
    > > message yourself is better in some way than having the sending MTA
    > > create it?

    >
    > Yes, because our timeout is longer than that of some ISPs. Some ISPs
    > are using two or four hour timeouts. I'd rather not have to tell our
    > clients that they need to wake up every 90 minutes and empty their
    > mailboxes to avoid losing messages.


    And you attempt to ameliorate every brain dead MTA on the planet? I
    feel very sorry for you.

    > > > > Creating backscatter because you can't configure your
    > > > > organizations mail spool so that the left hand knows about the
    > > > > right hand is still bad form.
    > > >
    > > > This thread has already mentioned numerous cases where backscatter
    > > > is unavoidable. Please post your Exim config which handles such
    > > > cases without backscatter. If it's that good, I'll even switch
    > > > our combination of Postfix, QMail, and custom SMTP code over to
    > > > Exim.

    > >
    > > Since exim can do arbitrary lookups in a number of backends, it
    > > would be trivial to store quota information in sql, ldap, flat files
    > > or cdb on shared storage, or whatever other signalling mechanism you
    > > can think of to communicate state. As for config file snippets, the
    > > first hit on google for 'exim quota sql' takes you to a discussion
    > > of how to implement it. I look forward to another qmail
    > > installation disappearing. It seems to be one of the primary agents
    > > of backscatter spam on the public internet.

    >
    > If Exim can do it then so can a Turing machine. Claiming that a
    > solution exists is not the same as providing a solution.


    Pointing to an answer to your question is roughly equivalent, however.
    I can't help you if you're unwilling to do some research and think out
    the basic design issues, or at least I won't help you without the
    standard consulting fee my company charges for setting up things like
    this.

    > We're look forward to seeing your Exim config that avoids all of the
    > potential causes of backscatter previously identified in this thread.
    > Then we'll see if the reduced performance and/or functionality are
    > worthwhile tradeoffs.


    So far, the backscatter you are attempting to justify is beacuse the
    front end has accepted a message that the backend doesn't like, either
    due to unknown address, quota, or content. User verification is trivial.
    Content scans properly belong on the front end, and if your backend is
    rejecting spam that the front end has already accepted, you've got a
    broken design. Implementing quota is slighlty more complicated, but
    not by much.

    How do you want to implement the quota signalling? Shared storage? SQL?
    LDAP? DNS? I suggest if you're serious, send an email to exim-users
    asking for help with your environment. You'll find there are almost as
    many ways to fix it as you can think of.

    That being said, the simplest is an acl of the form:

    defer
    condition = ${if eq ${USER_OVER_QUOTA}{yes}{no}}
    message = Over quota

    And a one line addition to the standard delivery router for your users
    of the form
    condition = UPDATE_QUOTA_INFORMATION

    Where USER_OVER_QUOTA and UPDATE_QUOTA_INFORMATION are macros that
    handle querying and updating depending on the backend you've decided on.
    Admittedly, there is a small race condition where the front end can
    successfully run a query before the back end has finished the update, and
    so a user can go over quota and get one more message. But again, your
    current arrangement would have accepted all such messages, so accepting
    one message is hardly more of a burden. If you want to be idempotent,
    your UPDATE_QUOTA_INFORMATION macro should include a lock on the data, so
    the front end can't query mid update, and will have to wait for the lock.

    If you can be more specific about which backend you'd like, I am happy
    to help you with your problems (although I suspect the people on
    exim-users will be more knowledgeable than I am). If you want me to
    design an MTA farm for you, then you'll have to call me on my work
    number.
    --
    -----------------------------------------------------------------
    | ,''`. Stephen Gran |
    | : :' : sgran@debian.org |
    | `. `' Debian user, admin, and developer |
    | `- http://www.debian.org |
    -----------------------------------------------------------------

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

    iD8DBQFEVVicSYIMHOpZA44RAiOzAJ95HN4IZT8Bj9bU0fqtHK dmOJEWpACfSWQ4
    66eo8ud5wzuDjUvvBY3wfF0=
    =rr6p
    -----END PGP SIGNATURE-----


  12. Re: OT: sorbs blacklisting scam

    On Sun, Apr 30, 2006 at 04:16:17PM -0700, Mike Bird wrote:
    > This thread has already mentioned numerous cases where
    > backscatter is unavoidable.


    Yes, there are some corner cases where email is sent automatically due to a
    trigger. One good such example is registration confirmations for various
    web-sites and mailing lists.

    However, these are much more rare than the typical bounces such as "no such
    user", or "mailbox full". It does not bother me if bounces are rare, and
    surely almost all admins would agree that rare cases can be sorted out and
    they are not a problem. But if a spammer can easily use lots of mail hosts
    to reflect bounces containing their advertisements, that is bad. The more
    they do that, the worse it is.

    Abolishing bounces completely is not a reasonable target, but limiting
    bounces only to necessary cases is a very important target.

    The only excuse for "no such user"-bounces is short term configuration
    mishap. It would be a bad idea to block hosts due to mailing list
    confirmations or some other necessary and non-frequent automatic messages,
    but if I recall the example presented in this thread mentioned a forged
    sender causing the bounce. For that case, there is no excuse (not even if
    Sorbs does it themselves aswell).

    I am not going to give specific configuration examples, because lookup
    configurations are always specific to the system and the specific needs of
    it. Also there are many ways to copy account information to secondary
    servers. The simplest case would be to copy the lookup-file by cron every n
    minutes, a more complex way would be to setup replicated ldap servers and
    make the MTA check accounts from there. But even that alternative is not
    terribly complex compared to the task of running professionally an entire
    mail system.

    At least Exim4 has an excellent manual which includes ldap-lookups and many
    other applicable types of lookups.

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

    iD8DBQFEVWkxRGhQc/k/gTsRArYzAJ9mTBtX+PHc4Yf1TuNmbWPEGs+P5QCdHgtR
    UIImWlP8o4TBEFX0MjyyQgo=
    =FXSh
    -----END PGP SIGNATURE-----


  13. Re: OT: sorbs blacklisting scam

    On Mon, 2006-05-01 at 04:49 +0300, Juha-Matti Tapio wrote:
    > The only excuse for "no such user"-bounces is short term configuration
    > mishap. It would be a bad idea to block hosts due to mailing list
    > confirmations or some other necessary and non-frequent automatic messages,
    > but if I recall the example presented in this thread mentioned a forged
    > sender causing the bounce. For that case, there is no excuse (not even if
    > Sorbs does it themselves aswell).


    The discussion is not limited to "no such user" bounces.
    We're informing our colleagues that SORBS adds an IP to
    its RBL based on a single instance of backscatter caused
    by SORBS' failure to discontinue its own honeypot addresses.

    Let's take a real-life example that came in a couple of
    minutes ago. SPAMMER sent an email to USER@FOO with my
    address forged as sender. USER was clueless but not
    malicious and replied asking to be "removed".

    An annoyance but understandable.

    However, had SPAMMER forged a SORBS honeypot as sender
    instead of me, ISP FOO would now be SORBS-listed. Even
    if FOO had a simple and perfect config with absolutely
    no backscatter.

    Avoid SORBS. Minimize backscatter. Use several good RBLs.

    Next topic please!

    --Mike Bird


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

  14. Re: OT: sorbs blacklisting scam

    On Sun, 2006-04-30 at 09:29 -0700, Mike Bird wrote:

    Hmm... looks to me like SORBS are very active at fixing things so that
    they work right. No longer does the server send backscatter. Are you
    still reflecting spam bounces back to everyone Mike?

    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 2000cn.com.au
    250 scorpion.sorbs.net
    MAIL From: shane@2000cn.com.au
    250 Ok
    RCPT To: sorbs-backscatters-too@sorbs.net
    550 : Recipient address rejected: User
    unknown in local recipient table
    quit
    221 Bye
    Connection closed by foreign host.

    Shane

    > 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

  15. Re: OT: sorbs blacklisting scam

    On Sun, Apr 30, 2006 at 08:19:31PM -0700, Mike Bird wrote:
    > Let's take a real-life example that came in a couple of
    > minutes ago. SPAMMER sent an email to USER@FOO with my
    > address forged as sender. USER was clueless but not
    > malicious and replied asking to be "removed".


    Since Sorbs claims spam listing is manual, do you really think that Sorbs
    would list a naive user asking to be removed from a mailing list?

    Since you claim this to be a real-life example, do you evidence of this
    happening? I have a hard time believing it.

    IF Sorbs were fully automated, then yes, you would be correct in that it
    would be bad behaviour to automatically list all mail received on spamtrap
    addresses.

    The only real case related to Sorbs that has been brought forth so far was
    related to reflecting spams in a similar matter as an open relay would. That
    kind of listing is hardly inappropriate.

    Other than that, we are talking entirely hypothetically.

    While we are on the topic of blacklists, can anyone point me to a blacklist
    of hosts performing ssh brute force attacks? I have been wondering if it
    would be effective to use such a list for email since those compromised
    hosts do seem to be used primarily for spamming. (Just having spent most of
    the night monitoring a Romanian spammer controlling his botnet.)

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

    iD8DBQFEVfmtRGhQc/k/gTsRAosAAJ4/UCfSJ3GWIEpKH2cF7nMg9tckpACffALP
    8PUMkt7E39x+PaqDS47vDzw=
    =VkSI
    -----END PGP SIGNATURE-----


  16. Re: OT: sorbs blacklisting scam

    On Mon, 1 May 2006, Stephen Gran wrote:
    > > Your mail server has the queue in the same partition as the mailboxes?
    > > Wierd. All that unnecessary quota activity.

    > All I am pointing out is that once you have accepted a message, you are
    > wasting your organization's storage and resources already, so I don't
    > really see the harm in dropping it in the user's mailbox and
    > incrementing their quota information.


    Not necessarily. Apart that i could have the mailbox and queues on
    different partitions, setting a quota can be useful for user that retrieve
    e-mail via webmail since -at least the program that i use- is uncapable to get email when
    there are more than 80 MB of mail ... (and the best one I know is
    uncapable above 2GB). In these case i keep for one week in queue, but then
    if the user does not clean something .....

    Another problem for passing the list of acceptable addresses the seconday
    mx: I must have the mailbox accepting e-mail as soon a new user request a
    mailbox. however the mailbox is not created until i or some other
    administrator does not check the the person requesting the account (via a
    web page) has the right to do. This could need in the worst case of a
    request on friday evening, up to next working day.
    During this time the e-mails are accepted "under condition" and sent to a
    special queue. A soon the account is actually created are delivered, if
    the account is deemed as unvalid, the e-mails sitting on the queues are
    send back.





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

  17. Re: OT: sorbs blacklisting scam

    On Mon, May 01, 2006 at 03:06:05PM +0300, Juha-Matti Tapio wrote:
    > While we are on the topic of blacklists, can anyone point me to a
    > blacklist of hosts performing ssh brute force attacks? I have been
    > wondering if it would be effective to use such a list for email
    > since those compromised hosts do seem to be used primarily for
    > spamming. (Just having spent most of the night monitoring a Romanian
    > spammer controlling his botnet.)


    use a DUL (the SORBS DUL is good) and use greylisting - that will block
    most spam from botnets (which are mostly on dynamic IP addresses, and
    mostly don't have real MTAs so don't retry).

    even a 10 or 20 second timeout for greylisting is worthwhile. spambots
    typically don't retry.

    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

  18. NEVER USE SORBS


    Someone here mentioned a lawsuit. I can get behind that. They are messing
    with my business and it's impossible to get off their list. Any info on
    ongoing lawsuits, let me know.
    --
    View this message in context: http://www.nabble.com/OT%3A-sorbs-bl....html#a5494705
    Sent from the Debian ISP forum at Nabble.com.


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

  19. Re: NEVER USE SORBS

    On Tue, 25 Jul 2006, NEVERUSESORBS wrote:

    > ... impossible to get off their list.


    I think it's impossible for an ordinary end user to get off their DUHL.
    However, if you have an AS number, they apparently view your request.

    My IP was removed from the DUHL due to a delisting request by my upstream
    provider. I doubt they even read the comments within my support requests.

    My IP block is within a /21 that got listed because SORBS didn't like my
    upstreams naming convention.

    I feel very happy the new owner of my upstream took care of this.
    Resolution did take two weeks during which time I would have been very
    happy to sue SORBS.

    Now, I'm back to my real work instead of fighting email delivery problems.

    I agree with the poster. Never Use Sorbs!

    Steve


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

  20. Re: NEVER USE SORBS

    On Tue, 2006-07-25 at 17:31 -0700, Steve Redlich wrote:
    > On Tue, 25 Jul 2006, NEVERUSESORBS wrote:
    >
    > > ... impossible to get off their list.

    >
    > I think it's impossible for an ordinary end user to get off their DUHL.


    Not true. Anyone can get off thier list providing you do what is
    mentioned on the faq page. Once thats done you simply submit the info
    automatically and its done. You dont even need to talk to anyone at
    sorbs to do it, but you do need matching forward and reverse dns and a
    ttl >= 43200 seconds.

    Shane


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

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast