Yeah, you are correct.
But it was still a dumpster. We recycle a lot of metal around here 
We are looking for a SORBS contact as their web site and registration process is less than friendly if somehow you get listed by them.
BRW
You're new here, aren't you?
(Sorry, couldn't resist. Previous discussion on NANOG:
http://www.google.com/search?sourceid=mozclient&scoring=d&ie=utf-8&oe=utf-8&q=sorbs+site%3Ananog.org
As I recall it, you can manually create an account on their
request-tracker instance and open a ticket through that requesting
delisting... however, complaining on NANOG is probably just going to
result in a less than friendly response from Michelle (at least as
history as shown).
William
You want to speak to SORBS? Good luck with that. Unless you are Chuck
Norris; Chuck Norris can speak with SORBS anytime he wants
Last time I went through this... first it was they didn't like my RDNS, so I
added "Static" to it. Then it was my ISP didn't SWIP the record properly,
they fixed this. Then after that they said my DNS TTL was too low.
The final straw was the DNS TTL, we used it for failover to accommodate a
redundant mail setup and it wasn't changing.
My ISP even tried to intervene with communications from the e-mail address
who owned the IP block with no luck. A large part of one of their /16s
was listed.
Mind you, my space was not listed for spamming, just being dynamic. This
was a Metro-E circuit.
At around the third iteration (DNS TTL), I just asked the ISP for an
additional IP block allocation and moved the mail server there.
2 months later someone updated/closed the ticket and it was delisted
My advice? Try the instant de-list process on their web page. If it works
the first time, great. If it fails you're in for a long painful
experience. Asking the ISP for a new/additional IP block is often quicker.
Thanks .. their attempts to reach us are blocked via our Barrcacuda's due to the fact that they are sending with a blank FROM: and as such Barracuda thinks its SPAM .. just to darn funny .. I have whitelisted their domain so on my fourth attempt we will see .. Cant create tickets or communicate with them unless you have an account and you can not get an active account unless you can get an email to activate it .. very frustrating to say the least.
Nope .. just like pain and suffering 
He's the most interesting man in the world...SORBS is on HIS list and
can't get off.
Please clarify. Are they sending
MAIL FROM: (syntactically broken, they need to fix it)
or
MAIL FROM:<> totally valid, and if your Barracuda rejects it, it's *your* problem.
And you might want to fix it, since your users will never get a bounce notice
from any RFC-compliant mailer - even if they *wanted* to know that their mail
wasn't delivered. <> is the RFC-standard way to denote "this mail is a bounce
report or other programmatically generated mail, and if it bounces itself, do *not*
generate another bounce, as that may start a bounce loop".
See RFC5321, sections 3.6, 4.5.5, and 6.1.
(And all those of you anti-spam zealots who want to argue about RFC5321's
SHOULD/MUST pronouncements on the handling of <>, I'll point out that there's
*lots* of wiggle room for those of us with years of SMTP wrangling experience.
On the other hand, we're talking about a potentially misconfigured Barracuda
here, and if a site has a misconfigured Barracuda, urging RFC-compliant
behavior is the only sane choice... 
Correction: It's a standard way to denote that "this mail is a bounce
report." Any other sort of programmatically generated email is
supposed to use an email address capable of receiving a reply so that
the sender becomes aware that it failed to be delivered. One defense
against so-called blowback spam is to refuse bounce reports which do
not, somewhere within the message, contain an email address that the
bounce recipient recently sent to.
Regards,
Bill Herrin
Correction to your correction: What the RFC actually says:
4.5.5. Messages with a Null Reverse-Path
There are several types of notification messages that are required by
existing and proposed Standards to be sent with a null reverse-path,
namely non-delivery notifications as discussed in Section 3.7, other
kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and
Message Disposition Notifications (MDNs, RFC 3798 [37]). All of
these kinds of messages are notifications about a previous message,
and they are sent to the reverse-path of the previous mail message.
(If the delivery of such a notification message fails, that usually
indicates a problem with the mail system of the host to which the
notification message is addressed. For this reason, at some hosts
the MTA is set up to forward such failed notification messages to
someone who is able to fix problems with the mail system, e.g., via
the postmaster alias.)
It's *not* just "bounce reports" (in particular, DSNs and MDNs are not
non-delivery (bounce) messages in the sense of section 3.7, and both
can be generated in response to *successful* deliveries).
generated for *successful* deliveries).
William Herrin wrote:
And you might want to fix it, since your users will never get a bounce notice
from any RFC-compliant mailer - even if they *wanted* to know that their mail
wasn't delivered. <> is the RFC-standard way to denote "this mail is a bounce
report or other programmatically generated mail, and if it bounces itself, do *not*
generate another bounce, as that may start a bounce loop".
Correction: It's a standard way to denote that "this mail is a bounce
report."
Umm no... As has been pointed out by others, but in another section
(maybe another RFC) it says that the null return path should be used
when a return message is not required, not desired, or it is from an
automated system or you wish to avoid mail loops (with particular
reference to bounce messages and mailing lists.) The registration email
has a null return path because people will put in forged addresses and
we don't want them to do that in the first place, and if they do it, we
certainly don't want any auto-responder from replying or it going to a
mailing list (most mailing list software prevent delivery of null return
path mail to the list members) - seems the like most responsible and
desired setup.. which is why I chose it.
Note (to answer another mail in this thread): MAIL FROM:<> and 'From:
<devnull@sorbs.net>' in the headers to be completely within standards
(previously it used in the headers as well which is a violation of an
RFC - I forget which one.)
Michelle
PS: Baracuda are not the only ones, Ironport has an option for it as
well - but I believe the default in Ironport is 'Off' for bounce control.
William Pitcock wrote:
We are looking for a SORBS contact as their web site and registration
process is less than friendly if somehow you get listed by them.
As I recall it, you can manually create an account on their
request-tracker instance and open a ticket through that requesting
delisting... however, complaining on NANOG is probably just going to
result in a less than friendly response from Michelle (at least as
history as shown).
You have to have an account first. However you can create a ticket via
Email if you use one of the input addresses for a queue (eg:
support@support.sorbs.net).
Friendly or non friendly response is usually gaugable in advance by the
tone of the initial email.
Regards,
Michelle
Which is usually gaugeable in advance by the tone of the customer
complaints that precipitated contact with SORBS in the first place.
Email is such a lousy medium for this. We're all much more decent people
in person than over snarky emails.
Nick
It's pretty much customer service 101 to ensure that you keep your communications as neutral and polite as possible, regardless of how frustrated or vilified you feel by the person you're supporting, and regardless of how tired you are of accusatory tickets. Being snarky back gains little, if anything, and just helps promote a bad reputation. People forget good customer service (unless it surpasses that to brilliant), but remember bad service.
"In Soviet Russia - Network block SORBS!" - Yakov Smirnoff
Ok, he didn't really say that one. Seriously though, in the past I've found
their website so slow and generally parts were broken I couldn't use it. I
tried to email webmaster@ and some other addresses about issues with the
site but my emails were all blocked for whatever reason I can't recall. I
probably spelled my own name wrong or something in my signature and it was
detected and summarily blocked. Maybe its better now though, I'm not sure.
We haven't had much need for it lately <knocks on wood>.
Nick Hilliard wrote:
Email is such a lousy medium for this. We're all much more decent people
in person than over snarky emails.
Speak for yourself!
Landon Stewart wrote:
webmaster@* isn't "random", it's a fairly standard way to reach the
administrator of a service. A failure to support that on your part
does not constitute abuse on my part.
--Dan