Slashdot Mirror

That sounds like Reply-To considered harmful extra bad edition:

http://www.unicom.com/pw/reply...

Return-path is to be filled by the MDA with the envelope from, so mailing list software has no business touching it, Reply-To is there for the sender to use to set a different reply address, so might in particular already have a value which you certainly should not overwrite, and in any case, the From header is supposed to indicate who wrote the mail, so mailings list software has no business touching it either. And in order to enable list replies, it should not break direct replies (which altering From or Reply-To headers does), because a proper MUA already has at least a group reply function, which exists exactly for that purpose - and a good MUA also will understand Mail-Followup-To in order to avoid double replies when the sender of the message that you group-reply to wants that (so, it's also something that the sender should set, never the mailing list).

They sign people up without ever opting in.

Their means of signing out are both extremely complex and non-functional.

Here is a blog entry that talks about the problem.

Many people I know have had this problem.

We need to get political organizations to no longer be an exemption from the CAN-SPAM act.

One thing you can do is send email to hostmaster@dnc.org -- however, you might want to use a disposable email address, lest you too get signed up for their mailing list.

I've come to like musikCube for a Windows player and indexer. It finds files automatically if you give it the directory and, if the files are tagged correctly, you get a decent search it seems. I don't have that much music ripped to my computer, though, so I don't know how it handles larger collections for sure, but it looks promising. (The support for FLAC is what made me download it in the first place.)

I would like to set up a hard drive on my dedicated Linux box with my entire music collection in FLAC format, then set it up as an SMB share so that I can access all my music over WiFi from wherever in the house. I teach music lessons, and this would be really handy if, during a lesson, I thought of a recording I wanted to play for my student and I had my laptop there. (Organizing/cataloging my CD collection would be another alternative, but not nearly as interesting.) Might be a summer project for me. I have come to like abcde as a ripper. Under Linux, be sure to turn off cdparanoia if you ever want the ripping process to finish (link isn't using abcde, but the reasoning is the same, and cdparanoia options can be specified in the config file for abcde).

When I was threatened by a reverse domain hijacking, the EFF provided reference to a lawyer who helped with my case. We won, and I've been told my case has established precedent. As a result of my case, a company cannot try to steal a domain by filing a lawsuit in a distant state.

I'm grateful for the support of the EFF.

Actually, um, no.

Microsoft sold Xenix off to SCO (and others).

That enhancement alone is worthy of upgrading!

Never heard of xtail? It was released in 1989 and does exactly that.

Do you have a reference to where Panix said they locked the domain? I've been wondering whether or not that was done. I posted a blog entry on this topic earlier this evening.

Chip Rosenthal would disagree with you, just like I do.

Individuals should stay out of the .COM domain as owners in all circumstances, because an individual is not a corporations.

Again, I clearly disagree. You'll notice the homepage listed at the top of my post, for instance. I wanted a domain primarily so that when I move from one provider to another, or my current provider goes belly up, I don't have to change email addresses. I could have choosen something other than .com - but there are no "whitis" companies that I'm familiar with, so I see no conflict. And some day, I may want to start a business. Why should I wait for someone else to register it?

Sure. Tell it the girl at to veronica.org, or the boy at pokey.org.

Tell it to Chip Rosenthal who was sued by a company named unicom for his unicom.com domain. He had owned the domain name since 1990. They registered unicom as a trademark in 1997, started trying to buy his domain in 1998, and sued in December of 2001. He did win the suit, but he had to defend himself in California (where the assholes were located) to do so, and he had to pay the legal bills involved.

Sorry, but having a trademark doesn't make it a clear cut case.

The Uzi Nissan v Nissan case is quite different. Uzi had Nissan Computers which is not the same business as Nissan Motor Corp, so when soliciting customers one would generally recognize that these are different Nissan's. Furthermore, the domain name matched his last name exactly; therefore, he was not trying to impersonate Nissan Motors or make fun of them in any way.

The Uzi case was definitely about the corporate monoliths trying to bully the little guy. Another reasonably good example is Unicom but fortunately the company wasn't big enough to win.

I feel sorry for Uzi, he was doing business with his name and big corporate interest bullied him out of his domain. Mike Rowe, on the other hand, was poking fun at a company and doing business in a similiar area -- consumers would be unable to identify the difference between these two names.

See http://www.unicom.com/chrome/a/000294.html for more information.

Okay ... I'll post the complete message that was quoted in the article.

Now, will the people who are whinging, "You can't trust From: headers" please stop? :)

I blogged my rebuttal to Larry last January.

The problem, in a nutshell, is that the success of his proposal depends upon the efficacy of filtering. His bounty, if it works as desired, ensures that we have subject tags to do that filtering. My claim is that even if Larry's proposal allows for perfect filtering, we're still in store for a mail system meltdown.

This claim has not been well received. :)

The problem is that too many people--a significant number of them hang out on this web site--believe filtering is a magic bullet. It isn't, and Larry's proposal provides an example of the situation where you can implement perfect filtering and still have a mail system meltdown.

I do think there may be a remedy that may save Larry's proposal. If the filtering tag is moved from the Subject header into the tranport session (say, an ESTMP parameter), that may reduce the cost of rejecting spam enough to avoid the system meltdown problem.

Or rather this tool, actually, which is for open mail relays. The other one's for proxies. Got those too? Ever bothered checking them?

It doesn't need to be a lot of work either... because a nice tool exists which may aid you, and other people even created a website to run the tool for you.

Alternatively, you can telnet to relay-test.mail-abuse.org from the mailserver.

so now i'll get spam which says that it is spam...will this reduce the amount i get?

Of course! Now you can just set up a filter to deny any email that has both of these statements in it:

• This is not spam!
• This is spam!

various references for your amusement:

http://www.wired.com/news/infostructure/0,1377,571 32,00.html

http://www.spamhaus.org/newsdog.lasso?article=114

http://www.unicom.com/chrome/a/000032.html

the last one is of particular interest because it claims that Hotmail doesn't seem to do anything about these dictionary attacks:

They have discovered that MSN/Hotmail seems to allow spammers to run long-lived dictionary attacks, in one case extending over five months in duration.

as for software capable of launching this type of attack - there are already programs which exist for launching these attacks against authentication systems. those written in scripting languages (many of them are written in perl) are easily altered to attack a mail server.

1. control - \ sends SIGQUIT rather than SIGINT as control - c does. Useful for killing programs that do something besides exit when they get SIGINT (such as xtail).
2. kill -ILL Simulates an illegal instruction - useful for killing tasks that ignore kill -KILL. I had to use this all the time to kill hung opnet and comnet simulations back in my networking class several years ago.

Yes, that allegation was in the complaint I deny it.

You don't have to take my word for it. All of my communication with USI (prior to the cease and desist letter) was by email, and that email is available online. You can read it and decide for yourself.

Try the main page, and I see it now says:

I am Slashdotted

Sorry ... this web site is Slashdotted at the moment.

Here is the Google cache version of my main page.

Until my new shipment of bandwidth arrives, you may want to visit the Save Unicom.Com web site.

Tom.

Chip is in Austin, Texas, but the Plaintiff sued him in Los Angeles.

When we responded to the Complaint, we made several alternative motions, one being that a court in California lacked personal jurisdiction over Chip, not only because he's in Texas, but also because he does not have sufficient contacts with California to make it reasonable for him to be dragged into court here.

The Court granted our motion to dismiss for lack of personal jurisdiction. That's a big victory, there's much to be said for the proposition that courts do not have unlimited reach, even when the Internet is involved (think Matt Pavlovich and the California DVDCCA case, for example), but it isn't a ruling on the merits.

If Plaintiff should choose to file a new action against Chip in Austin, we have plenty of ammunition for arguing the merits of his rightful claim to the unicom.com domain name, but readers should not assume that this win addressed that issue. The Court's ruling is here.

I have a bunch of random e-mail addresses linked-to off a period on my home page. If any bot finds it, it gains 2,500 fake addresses. I update it every so often. It was generated by SpamBait. Everyone should do one. I don't have the link to the orignal program, but here's another.

some joker in mpinet.net just wouldn't give up - I had several hits PER SECOND on my home dsl line. quite the TOS attack.

I was forced to learn more about my mail system (qmail on openbsd) and the oh-so-useful tcp-wrappers. I also learned about the ORBS, MAPS/RBL/RSS servers.

in a few days I had hacked my qmail and tcpwrappers system to consult the RBL lists and if there was a hit, add the offender to a local cache (so that I can recognize him quickly next time).

since my site has very very few valid usernames, it was also easy to honeypot the spammers and when an invalid username was sent to, the source IP and username would be logged for future auto-blacklisting.

I've found that cutting the spammers off at the tcp-env level is quite effective in cutting down bandwidth. they can't even telnet to my port 25 anymore - I immediately shutdown the connection! no more megabyte-of-.doc crap, no more offensive spam, no more crapola, nada. just clean and quick tcp rejects ("connection refused").

the only shame is that I fear most mass abusers don't check the return codes of mail attempts and more than that, they engage the STOLEN use of open relays. so its the open relay that queues and retries and retries (I see it in my logs..) over and over. I almost wonder if I should let them complete their junk email exchange (only after hours, when I don't need my line) just to help purge their queues (?).

at any rate, the following scripts are quite useful in this battle:

rlytest.pl, checks (sends mail to) open mail relays

blq.pl, checks the MAPS,ORBS,RSS,DUL realtime blocking lists

--

some joker in mpinet.net just wouldn't give up - I had several hits PER SECOND on my home dsl line. quite the TOS attack.

I was forced to learn more about my mail system (qmail on openbsd) and the oh-so-useful tcp-wrappers. I also learned about the ORBS, MAPS/RBL/RSS servers.

in a few days I had hacked my qmail and tcpwrappers system to consult the RBL lists and if there was a hit, add the offender to a local cache (so that I can recognize him quickly next time).

since my site has very very few valid usernames, it was also easy to honeypot the spammers and when an invalid username was sent to, the source IP and username would be logged for future auto-blacklisting.

I've found that cutting the spammers off at the tcp-env level is quite effective in cutting down bandwidth. they can't even telnet to my port 25 anymore - I immediately shutdown the connection! no more megabyte-of-.doc crap, no more offensive spam, no more crapola, nada. just clean and quick tcp rejects ("connection refused").

the only shame is that I fear most mass abusers don't check the return codes of mail attempts and more than that, they engage the STOLEN use of open relays. so its the open relay that queues and retries and retries (I see it in my logs..) over and over. I almost wonder if I should let them complete their junk email exchange (only after hours, when I don't need my line) just to help purge their queues (?).

at any rate, the following scripts are quite useful in this battle:

rlytest.pl, checks (sends mail to) open mail relays

blq.pl, checks the MAPS,ORBS,RSS,DUL realtime blocking lists

--

ESC really sucks in IE

There is some discussion going about 'Reply-To munging'.

I found this in the Mailman "general/reply_goes_to_list" details help:

There are many reasons not to introduce or override the Reply-To: header. One is that some posters depend on their own Reply-To: settings to convey their valid return address. Another is that modifying Reply-To: makes it much more difficult to send private replies. See `Reply-To' Munging Considered Harmful for a general discussion of this issue. See Reply-To Munging Considered Useful for a dissenting opinion.

I prefer _not_ to set the Reply-To header.

Sendy

I'm not going to claim any great experience in the job market (I've been working in IT as a sysadmin and programmer off and on while finishing my degree for about the last year and a half, for context; ~70% of my friends are in IT full time and cover the gamut in terms of experience). Still, it seems that the problems that keep good people from connecting with good employers and vice versa are always HR-related.

The primary symptom of this is what I call the Laundry List syndrome. It seems to happen when the HR person(s) go about asking all the dept. heads what skill sets they need. Then, not knowing the difference between, say JSP and IOS, they place an ad for ONE person, listing ALL of ths skills as REQUIRED. :-( I can't count the number of times I've searched for "perl and linux and java" only to have a third of the result set read like so: "Java, AWT, JSP, Servlets, JDBC, Unix (Solaris, Linux expert admin level), perl, SQL, XML, DHTML, and Photoshop". Predictably this position goes unfilled and nobody is happy in the end. HR people need to _understand_ how what they're looking for fits into the company's goals in order to do their job well.

HR depts. (and recruiters) all to frequently tend to use really, really rigid demarcations and heuristics to attempt to sift for qualified potential employees. "Oh, we're sorry, you have everything we need in skills 1 - 4, and seem like a really easy guy to work with, but you only have 3 years experience with Java instead of 4." I'm not going to say I'm as good with Unix (with ~1 1/2 years experience) as some 20+ year admin; that's just silly. But, let's be honest here, what substantive difference is there between 2 years exp. and 1.5? Yet time and again I've been hit with walls like that, and I've seen it happen many times to friends. If less Procrustean standards were applied, the companies would be able to get people who were at least close enough to learn and come up to speed (this requires good teamwork in the workplace, of course), enabling work to accelerate instead of stagnate or decelerate as the existing employee base gets burned out from having no coworkers to rely on to share the load...

And of course let's not forget the classic chestnuts of "You're taking classes/have a family and thus can't work 60 hours a week, so you're useless to us." Internet Time is bullshit, and is purely a symptom of organizational failure: failure in planning, failure in leadership, failure in marketing, etc. etc. If you can't get all your work done at a reasonably human pace in 40 hours a week, something is W*R*O*N*G with your company.

In short, my sympathy for employers who whine about not being able to find anyone with one breath and yet reject 9 out of 10 applicants with the next is extremely limited.

As a side tangent, I recently found a funny posting in 1997 to Usenet talking about Usenet job ads (and the sad-but-true-insert-bitter-pained-chuckle-here things therein). I still see the exact same things in usenet and web board ads today. The archived post is here.