Nope .. just like pain and suffering :( ----- Original Message ----- From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu> To: "Brian R. Watters" <brwatters@absfoc.com> Cc: nanog@nanog.org Sent: Thursday, July 28, 2011 12:44:29 PM Subject: Re: SORBS contact On Thu, 28 Jul 2011 12:31:13 PDT, "Brian R. Watters" said:

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.

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%2Eorg

You want to speak to SORBS? Good luck with that. Unless you are Chuck Norris; Chuck Norris can speak with SORBS anytime he wants :) On Thu, Jul 28, 2011 at 3:50 PM, William Pitcock <nenolod@systeminplace.net>wrote:

On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) "Brian R. Watters" <brwatters@absfoc.com> 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).

William

He's the most interesting man in the world...SORBS is on HIS list and can't get off. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

On Thu, 28 Jul 2011 14:16:23 PDT, "Brian R. Watters" said:

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

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... ;)

On Fri, 29 Jul 2011 09:48:44 EDT, William Herrin said:

Correction: It's a standard way to denote that "this mail is a bounce report."

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).

On Sat, 30 Jul 2011 09:46:13 EDT, William Herrin said:

Point taken. Bounce reports, temporary failure reports and successful delivery reports. Nevertheless, it still isn't for "other programmatically generated mail." In fact, the next paragraph in RFC 5321 4.5.5 says:

"All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path."

tl;dr: 4.5.5 says SHOULD instead of MUST for a *reason*. RFC2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I know for a fact that the LSoft guys thought long and hard about it, and decided that "Yes, 99.998% of the mail will go out with a non-null reverse path. But the other 0.002% of administrivia and confirmation mail will best serve the network interests if they are sent with a null reverse path so they are treated similarly to bounce messages, even though they aren't an RFC-blessed bounce message". Hint: If somebody forges a subscription request from 'nosuchuser@herrin.us', do you want the resulting "Somebody has requested this email address to be added to the foobar-l list, please click or reply within 48 hours to confirm" mail to show up with a <> so you can skip generating the bounce, or do you want it to have a non-null return path so you're forced to generate a bounce that will be ignored at the other end anyhow? Does your answer change if some skript kiddie forges 10,000 requests?

On Sat, 30 Jul 2011 15:18:17 EDT, William Herrin said:

2. I assume the subscription request came from a web page because if it was from an email request you received then you ignored my SPF records when generating the confirmation request. That was OK in 2001 but in 2011 you ought not be doing that.

So let's see. Certainly, you can try to make the case that SPF tends to help eliminate *some* of the use cases of that one SHOULD in that RFC. However: 1) SPF is not itself a mandatory required service for SMTP. 2) SPF usage is not anywhere near 100%. 3) Last I checked, the SPF grammar still included things like ~all and ?all and people were still using them. Let's look at the actual domain that owns the misbehaving Barracuda that started this thread: absfoc.com. 300 IN TXT "v=spf1 mx ptr a:mail.absfoc.com a:outbound.absmailgateway.net ?all" Hmm.. .'?all'. Remind me what that means Biil, my reading of RFC4408 is obviously wrong, because it seems to say "we explicitly don't claim anything about mail sent from any other addresses". That sort of shoots your "If Woody had gone straight to the SPF record, none of this would have happened" claim. That SPF record doesn't advise that mail arriving from other sources should be viewed with suspicion - it's saying even the mail admin of the domain doesn't want to make a value judgement. 3a) SPF doesn't prevent forgeries. In particular, it doesn't do anything for determining the validity of the left-hand side of the address... The above 3 alone tend to say to any reasonable person that if you're doing something because SPF isn't in place, you need to *keep* doing it *because SPF isn't universally in place in a configuration that's usable for this purpose*. But wait, there's more... 4) SPF doesn't in fact address the issue that using a null <> is dealing with - there are *many* cases where the subscription request can't be delivered even with SPF in place. Consider all the cases where your mail server may emit a 4xx or 5xx response to a mail. Many of those are in response to mail that was generated to once-valid email addresses. 5) And don't bother saying "but we'd reject the mail during the SMTP transaction yadda yadda yadda", because the fact you would do so is in fact the cause of the biggest headache scenario, and the one that many products *USE* that null MAIL FROM for: 5a) We receive a mail from joe@mailboxes-r-us.com requesting a subscription. It's all nice and pretty, and even both DKIM and SPF validated as that user at mailboxes-r-us.com. 5b) We send out the confirm message, and mailboxes-r-us.com accepted the mail because 'joe' is a fully paid up customer in good standing. 5c) Oh, and 'joe' has set forwarding to joe@herrin.us. 5d) That MAIL FROM:<> isn't for your benefit, it's for mailboxes-r-us.com's benefit so they don't have to generate a bounce when your SMTP server informns them that joe@herrin.us isn't a valid address anymore because you enforced your TOS on their spamming butts, or it's not a valid address anymore because they didn't pay their bill, or it's not valid anymore because they *did* pay their bill but your back office people screwed up posting the credit to their account, or their mailbox is full, or they've got a syntax error in their mail filter file, or some *other* user's mail just went totally bat-guano crazy and filled your spool, or... or pretty much *any* case where your mail server will generate a 5xx error in response to a forwarded mail. mailboxes-r-us.com is now the proud owner of a bounced message it didn't originate. And you're upset because some people looked at the SHOULD in the RFC, and thought hard about it, and decided that the administrivia mail in question should have the exact same delivery semantics as a bounce, MDN, or DSN, for exactly the same reasons (allow a mailer to drop it on the floor rather than potentially double-bounce it), and decided that it met the "for good reason" exemption that RFC2119 specifically includes as *the distinguising difference between MUST and SHOULD*. I'll make you a deal - *you* donate the resources needed to fix all 5 of the above Internet-wide(and yes, point 5 means you need to totally ban store-and-forward mail forwarding), and all the *other* corner cases that are involved, and then I'll talk with the people who are violating your sensibilities regarding that SHOULD. And even at that point, that Barracuda is almost certainly *still* broken, because I'm pretty darned sure it doesn't include code that says "reject MAIL FROM:<> unless it's a specifically blessed MDN, DSN, bounce or other RFC-compliant format", it's just got a "reject <> yes/no" switch someplace.

On Sun, 31 Jul 2011 18:36:22 EDT, William Herrin said:

On Sun, Jul 31, 2011 at 2:32 PM, <Valdis.Kletnieks@vt.edu> wrote:

...

That sort of shoots your "If Woody had gone straight to the SPF record, none of this would have happened" claim.

My WHAT claim?

What you said:

2. I assume the subscription request came from a web page because if it was from an email request you received then you ignored my SPF records when generating the confirmation request. That was OK in 2001 but in 2011 you ought not be doing that.

However, we've established that the if the email request was from the domain that actually *started* this thread, the SPF data would *not have mattered* - even if it *was* checked, the fact it contained a '?all' would *not* have stopped the subscription request from being passed on. And before you start saying "but then they've got their SPF misconfigured" - remember that in 2011, we *still* don't have enough sites with SPF configured *correctly* that we can start chopping out code on the basis of "this case can't possibly happen with proper SPF, and almost never happens in the production Internet". And as I pointed out, there are a *lot* of failure modes that make you wish you can ditch the bounce message that are *not addressed at all* by SPF. Bounces caused by forged messages are just *one* issue - and even that's one that SPF doesn't actually address.

I'll see your wild speculation and raise you mine. The Barracuda is designed to protect enterprises where the mail can only go out one path -- through it. It auto-whitelists folks its users sends mail to and allows bounce messages for those destinations based on pattern matching in the message content... before discarding other messages with a null return path.

Presumably you're referring to this press release: http://www.reuters.com/article/2008/08/21/idUS127450+21-Aug-2008+BW20080821 However, it has the same problem as any other auto-whitelist - it can only whitelist those things it knows about. The press release talks about NDRs - but is silent on DSNs, MSNs, and other RFC-blessed uses of a null return path. And even if it *does* DTRT for all current standards-path RFCs, that *still* doesn't change the fact that what it's basically doing is saying "We're unilaterally insisting that the 'SHOULD have a non-null' is actually a MUST, and enforcing it". They are of course welcome to do so, but they're not allowed to complain when elevating said SHOULD to a MUST causes some mail to be lost because the mail came from a site that's still following what the RFC actually says, not what Barracuda or the recipient site *wishes* it said. Let me repeat that: You're certainly allowed to be stricter than the standard. However, you're *not* allowed to complain when being stricter than the standard results in failures dealing with less-strict-but-still-standard inputs.

On Fri, 29 Jul 2011 23:52:50 +0200, Michelle Sullivan said:

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.

LSoft's Listserv product does this as well - subscription confirmation messages and some other administrivia mail are sent with MAIL FROM:<> so forged subscribe requests don't generate bounces. The upshot is that if you block <> your users will never be able to subscribe to any Listserv-hosted list. There's enough sites running Listserv that it might be a bit more impact than "I can't e-mail SORBS"... I have always been amazed at how products like the Barracuda or the PIX can ship with totally broken software, and yet get enough market share to cause so much pain for the rest of us. Some days, I wonder if there's grounds for legal action - do such broken "training wheels for net admins" products constitute an attractive nuisance? ;)

Landon Stewart wrote:

On 28 July 2011 14:16, Brian R. Watters <brwatters@absfoc.com> wrote:

...

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.

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

Emailing random non-existent email addresses (such as webmaster@sorbs.net) will earn you a listing... -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/

On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote:

On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan <matthew@sorbs.net> wrote:

...

Emailing random non-existent email addresses (such as webmaster@sorbs.net) will earn you a listing...

webmaster@* isn't "random", it's a fairly standard way to reach the administrator of a service.

Per RFC 2142 section 5, it's the standard way to reach the administrator of the HTTP service, just as "hostmaster" is the standard way to reach the administrator of the DNS service. So you're both wrong: SORBS, since it has a web site, should support the "webmaster" address; and you shouldn't send traffic there unless your enquiry is about the web site (e.g., difficulty accessing it, broken links, malformed pages). ---rsk

On Sat, Jul 30, 2011 at 02:57:12PM +0200, Michelle Sullivan said:

Ok I'll accept that reference..I must admit I didn't know that RFC/STD existed so I learnt something today. ;-)

That's pretty rich. You enforce people to adopt standards that are part of proposed RFC's, not official by any standard, jump through 18 other hoops, and still won't delist them because some bit in their named replies is the wrong number of electronvolts on your wire, and then claim you dont know an RFC? p.k.b. /kc -- Ken Chase - ken@sizone.org

On 7/30/2011 2:33 PM, Michelle Sullivan wrote:

Ken Chase wrote:

...

On Sat, Jul 30, 2011 at 02:57:12PM +0200, Michelle Sullivan said:

...

Ok I'll accept that reference..I must admit I didn't know that RFC/STD existed so I learnt something today. ;-)

That's pretty rich.

You enforce people to adopt standards that are part of proposed RFC's, not official by any standard, jump through 18 other hoops, and still won't delist them because some bit in their named replies is the wrong number of electronvolts on your wire, and then claim you dont know an RFC?

p.k.b.

/kc

What's the current RFC/BCP and STDs count? I'm sure you remember at least 95% of them by heart and can recite them word for word, just like me..!

Whilst you have a reasonable point, and there are a fair number of them to keep track of, you are providing a service based around a subset of them. Would you not agree that it would be reasonable to assume that you (or your product designers) would know and understand all the standards appropriate to your product, and are ensuring your own compliance? Paul

Jimmy Hess wrote:

On Sat, Jul 30, 2011 at 7:57 AM, Michelle Sullivan <matthew@sorbs.net <mailto:matthew@sorbs.net>> wrote:

Rich Kulawiec wrote: > On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote: [snip]

later in the document, Webmaster@ is not in the required list. As per my previous email, the webservers (all of them) report another email

[snip]

I wouldn't fault SORBS for not supporting optional addresses such as webmaster@. I would fault SORBS for automatically listing someone e-mailing webmaster@ though, as implied above. Whether the actual RFC existed or not.

It's probably true that all the standard addresses are likely to be subject to abuse. info@ sure is.

However, they should not be listed without at least analyzing the content of the actual message. To decide if it is in fact abuse, OR if it's just a human failure, somebody attempting to contact an admin address/service that does not exist.

There mere act of attempting to contact multiple standard addresses alone, is certainly not proof of abuse.

A valid and well put argument. I don't know what we do with stuff to webmaster@ however I do know that it is possible that messages to it will go into the spamtrap system. (the spamtrap system has multiple entry points, and a mail going in does not guarentee a listing, but it is likely, especially if the message is repeated to multiple addresses and therefore is 'bulk'.) Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/

Dan Collins wrote:

On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan <matthew@sorbs.net> wrote:

...

Emailing random non-existent email addresses (such as webmaster@sorbs.net) will earn you a listing...

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

Feel free to point out the RFC/STD/BCP that states that (yes, there is one for abuse@ and postmaster@.. last time I checked there wasn't any mention of webmaster@ - both abuse@ and postmaster@ are valid addresses that go to real people, neither will respond to any type of delisting requests.) FWIW, you get an error on the SORBS website you get the email address to reach the administrators, it is not webmaster@, it's a lot more um... appropriate. SORBS gets messages to a lot of um "Standard" email addresses (eg sales@, marketing@, legal@, www@, root@, etc) which don't exist (and several that do exist or used to, eg noc@, support@, help@).. which I do smile at as it seems people who should have more sense, just don't. Every email address published for SORBS goes to a real person either directly or via RT (ticket type tracking system) and there are quite a few published email addresses... using something that is not published is not likely to get to a person and is most likely abuse. webmaster@ has never been a valid email address at SORBS and previously when people have commented on not getting a response I have indicated that it is not and has never been a valid address (and IIRC I have mentioned that on NANOG before).... Yet people still use it... Addresses that used to exist and are not to be used any more, either re-direct to the appropriate contact or reject at the MX with an appropriate reason message. Everything else is fair game for the spam collectors. Regards, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/

On 29/07/2011 22:55, Michelle Sullivan wrote:

Friendly or non friendly response is usually gaugable in advance by the tone of the initial email.

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

Paul Graydon wrote:

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.

You will find that all responses from SORBS support staff to support requests are very helpful, polite and customer service orientated - there have been many exceptions in the past, but for sometime we have been working on it to ensure that the issues of the past are not repeated. Note: threats (legal or violence) are not answered by support staff, there is a blunt and factual templated response that goes out to any such messages. That said, emails to people directly that either do not deal with support, or are not support email addresses may not get the same polite helpful response. I think most of us have experienced that from many organisations past and present, and SORBS is certainly has been on *that* list. Regards, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/