Re: [BULK] Re: SORBS contact
Sender: brwatt...@absfoc.com Subject: Re: [BULK] Re: SORBS contact Message-Id: 1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office Recipient: ge...@trinity.edu.test-google-a.com, Forwarded: gerno.rein...@trinity.edu ---BeginMessage--- 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. - Original Message - From: Dorn Hetzel d...@hetzel.org To: William Pitcock neno...@systeminplace.net Cc: Brian R. Watters brwatt...@absfoc.com, nanog@nanog.org Sent: Thursday, July 28, 2011 12:47:56 PM Subject: [BULK] Re: SORBS contact 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 neno...@systeminplace.net wrote: On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) Brian R. Watters brwatt...@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 ---End Message---
Re: [BULK] Re: SORBS contact
On Thu, 28 Jul 2011 16:17:02 CDT, trinity.edu's mailer, *not* Brian R. Watters said: Sender: brwatt...@absfoc.com Subject: Re: [BULK] Re: SORBS contact Message-Id: 1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office Recipient: ge...@trinity.edu.test-google-a.com, Forwarded: gerno.rein...@trinity.edu WIll somebody please smack the trinity.edu mail system upside the head? And then smack whatever deluded code hacker that couldn't be bothered to DTRT and cloned the inbound RFC822 headers into the outbound ones rather than generating an appropriate DSN? RFC1894 was back in 1996, there's no excuse this far into this century to botch this. pgpzdO0YOWdCH.pgp Description: PGP signature
Re: [BULK] Re: SORBS contact
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 j...@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 j...@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 j...@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. pgpFnDk0hz6WD.pgp Description: PGP signature
Re: [BULK] Re: SORBS contact
On Sun, Jul 31, 2011 at 2:32 PM, valdis.kletni...@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? You asked if I wanted mailing list confirmation requests that arrive at my mail server to have a non-null return path. My answer was yes I do. And I still do. Even if it means I'm the one who gets stuck generating a deferred bounce because the final recipient downstream turned out to be non-deliverable. 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. 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. If my speculation is right, the Barracuda is behaving reasonably and SORBS' use of the null return path ignores the SHOULD in an ill considered manner. If your speculation is right, the Barracuda's design bug is exacerbated by SORBS' ill considered use of the null return path. Either way, SORBS' ill considered use of the null return path for the confirmation messages (disregarding the SHOULD in RFC 5321) contributes to fully broken mail delivery behavior. That last sentence there, that's my claim. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: [BULK] Re: SORBS contact
On Sun, 31 Jul 2011 18:36:22 EDT, William Herrin said: On Sun, Jul 31, 2011 at 2:32 PM, valdis.kletni...@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. pgprxWoqvJxDU.pgp Description: PGP signature
Re: [BULK] Re: SORBS contact
On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote: On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan matt...@sorbs.net wrote: Emailing random non-existent email addresses (such as webmas...@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
Re: [BULK] Re: SORBS contact
Dan Collins wrote: On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan matt...@sorbs.net wrote: Emailing random non-existent email addresses (such as webmas...@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/
Re: [BULK] Re: SORBS contact
Rich Kulawiec wrote: On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote: On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan matt...@sorbs.net wrote: Emailing random non-existent email addresses (such as webmas...@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 Ok I'll accept that reference..I must admit I didn't know that RFC/STD existed so I learnt something today. ;-) I would like to point out though that in section 1 it states 'are encouraged to support' not must or even should, a quick skim read later and I see there are mention of those that are required to be supported later in the document, Webmaster@ is not in the required list. As per my previous email, the webservers (all of them) report another email address which is more appropriate for our organisation, and will feed all mail to a real person or into a ticket system in a queue for bugs and errors with the SORBS service as appropriate (this does not include any reports about content of the DNSbl, there are other addresses published for that.) Thanks, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: [BULK] Re: SORBS contact
On Fri, Jul 29, 2011 at 11:22 AM, valdis.kletni...@vt.edu wrote: 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. 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). Hi Vladis, 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. Contrary to your claim, it's perfectly reasonable for an spam filter in a symmetric routing scenario to discard a null return path message that isn't unambiguously responsive to one it previously sent. On Fri, Jul 29, 2011 at 5:52 PM, Michelle Sullivan matt...@sorbs.net wrote: 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.) Michelle, Is your web site registration message required by a standards track RFC to use a null reverse path? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: [BULK] Re: SORBS contact
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? ;) pgp1kFjrUG2RF.pgp Description: PGP signature
Re: [BULK] Re: SORBS contact
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 - k...@sizone.org
Re: [BULK] Re: SORBS contact
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 'nosuchu...@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? pgpUxLJyh63E5.pgp Description: PGP signature
Re: [BULK] Re: SORBS contact
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..! -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: [BULK] Re: SORBS contact
On Sat, Jul 30, 2011 at 7:57 AM, Michelle Sullivan matt...@sorbs.netwrote: 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. -- -JH
Re: [BULK] Re: SORBS contact
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
Re: [BULK] Re: SORBS contact
Jimmy Hess wrote: On Sat, Jul 30, 2011 at 7:57 AM, Michelle Sullivan matt...@sorbs.net mailto:matt...@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/
RE: [BULK] Re: SORBS contact
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'.) Respectfully, I'm unconvinced that fewer than 10 recipients (sending to webmaster and cc'ing netops) constitutes sending in 'bulk'. For instance, USPS requires 200 recipients for standard mail to classify such mail as 'bulk'[1]. That number seems quite high to me, but then again, 2-10 seems quite low. In the past, I've had a heck of a time getting blocks delisted from SORBs - even getting a PI assignment removed from the DUHL, which isn't even a list of abusive blocks, was tough. Again respectfully, if so many operations people have a problem with the way SORBS operates, doesn't that represent a valid concern? Operators constitute the bulk of your users, and they are, by and large, frustrated. The fact that they are trying to reach out via other methods should tell you something - and it isn't that the operators are doing it wrong (and should therefore be punished). Writing as a human, not as my employer, Nathan Eisenberg [1] - http://pe.usps.com/businessmail101/getstarted/bulkmail.htm
Re: [BULK] Re: SORBS contact
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... ;) pgpFSkeUEglVP.pgp Description: PGP signature
Re: [BULK] Re: SORBS contact
On Fri, Jul 29, 2011 at 2:46 AM, valdis.kletni...@vt.edu 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. 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 -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: [BULK] Re: SORBS contact
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). pgpnH7aW9Q1Q4.pgp Description: PGP signature
Re: [BULK] Re: SORBS contact
William Herrin wrote: On Fri, Jul 29, 2011 at 2:46 AM, valdis.kletni...@vt.edu 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: devn...@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. -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: [BULK] Re: SORBS contact
On 28 July 2011 14:16, Brian R. Watters brwatt...@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. -- Landon Stewart lstew...@superb.net SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more Ahead of the Rest: http://www.superbhosting.net
Re: [BULK] Re: SORBS contact
Landon Stewart wrote: On 28 July 2011 14:16, Brian R. Watters brwatt...@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 webmas...@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/
Re: [BULK] Re: SORBS contact
On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan matt...@sorbs.net wrote: Emailing random non-existent email addresses (such as webmas...@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
Re: [BULK] Re: SORBS contact
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. - Original Message - From: Dorn Hetzel d...@hetzel.org To: William Pitcock neno...@systeminplace.net Cc: Brian R. Watters brwatt...@absfoc.com, nanog@nanog.org Sent: Thursday, July 28, 2011 12:47:56 PM Subject: [BULK] Re: SORBS contact 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 neno...@systeminplace.net wrote: On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) Brian R. Watters brwatt...@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
