If you aren't specifically retained by 1 or more clients to engage
in paid efforts to stimulate grassroots lobbying on behalf of such
clients (the bill's phrasing), you're exempt. IANAL, but I don't
think people buying click-through ads on your blog's web site because
it's popular counts; they have to be paying you
specifically to lobby on their behalf.
If you aren't being paid $25,000 or more in any quarterly
period, you're exempt. Meaning, you've got to be
receiving/spending $100,000 a year to qualify.
You have to specifically be encouraging people to contact Congress to
take specific action on some matter.
Communication from an organization to its members, employees,
officers, or shareholders is exempt.
This isn't about going after bloggers. Rather, S.1 appears to be
attempt to register astroturfers as lobbyists.
If you're a blogger, and some organization writes you a big fat check
to post in your blog about how bad some particular Senate or House
bill is and gosh we should all contact Congress and
object to it, then I'm sorry, but I don't see how you can claim that
you're not a lobbyist.
And although I'm still oscillating somewhat, I tentatively think that
your being required to register your activities as lobbying is a Good
Thing, because those who read your blog (or email, or whatever) might
wish to know that you were paid specifically to influence
people to take action.
I'm not saying you have to be an astroturfer to object to this bill.
But based on the virtually-hysterical frothing I've seen from certain
organizations, I think it helps.
If you do nothing else, read the changes
that S.1 proposes, and decide for yourself: is S.1 an attempt to
silence criticism of the government, or an attempt to drag
astroturfers into the sunlight? Whose interests do those who are
ranting about S.1 Section 220 have at heart—free speech, or
their pocketbooks?
The quality of the product should be questioned because the author did not have adequate understanding of MTAs and Internet mail. As a result, he released an MTA that, in essence, would DoS other MTAs under certain (and not particular uncommon) conditions.
Imagine if an auto manufacturer produced a car that people love to drive because it's comfortable, gets good fuel economy, etc. The car just has one teeny defect, however: unless you know how to tune it properly, it occasionally backfires a 50-foot fireball that sets everything behind it in a 120 degree arc on fire—buildings, pedestrians, trees, pets, etc.
Speaking as one of the burn victims, your arguments about how great the car is to the driver are irrelevant. I don't care if it has a hole in the seat to give you a blowjob while you drive; the car is a danger to everyone else.
Now, finally, after many years, the car manufacturer has gone out of business. No more of these cars will be produced. This is a good thing. Do not resuscitate the company. And for God's sake, do not open source the blueprints for the car so some other idiots can start making them again.
Resuscitate Pegasus Mail if you think it's worthwhile to do so, but
only under the condition that resuscitating Pegasus
Mail doesn't also breathe more life into Mercury Mail.
When I left the university in 1999, the problems with open relay
Mercury Mail servers were still quite severe. No one
else was still shipping SMTP servers that were open relays by default
by then.
And of course the users could edit the.INI file; they
had to in order to configure it to use our relay
servers (so Mercury Mail could actually send mail). But the vast
majority of the people running Mercury Mail had so little mail
experience that they didn't even know what an open relay was, let
alone why it was Bad Thing. That was the entire point of Mercury
Mail; it was a product aimed at people who wanted to run a mail server
but didn't really have enough expertise to know how to do so.
Besides, as I already said, most of the bad defaults were deliberately
chosen, in order to cover up glaring deficiencies in functionality
(e.g., a stateless mail queue).
Again, I bear David Harris no ill will. But he unleashed an SMTP
server onto the world that was a horrifically bad Net.citizen, and he
either didn't realize that (unlikely), or simply didn't care because
it didn't affect his bottom line. I don't care what happens to
Pegasus (because I never had issues with it), but please, let
Mercury Mail die. God help us if that code is released as
open-source and then recycled back into new products.
You misunderstand. (Perhaps I wasn't clear in my original post, so
I'll attempt to clarify.)
The group in which I worked provide core computing services for the
entire university; that is, we made <user@example.edu>
email addresses work. We did not use Mercury Mail;
we used Solaris machines running sendmail and AMDS. The core mail
infrastructure had to handle 30,000+ users, and had to be available
24x7x365, because it was what most people used.
Some departments deployed their own mail systems; e.g.,
<user@ee.example.edu>. Most of them made no attempt to
coordinate with us, and with university politics being what they are,
we couldn't compel them to cooperate with us. Since virtually no
departments (outside of CS and IS) had people familiar with
unix/sendmail systems in-house, Mercury Mail was a popular choice.
In other words, Mercury Mail was appealing to precisely the
type of people who shouldn't have been running it: people who lacked
enough expertise with Internet mail systems to recognize that the
defaults were extremely dangerous.
You missed my point about the default settings. Other than shipping
as an open relay by default (which no respectable MTA had done for
years), most of the "poor defaults" were necessitated by the
fundamental design flaws of Mercury Mail. We'd get pushback from
departments when we asked them to set the queue processing interval
to, say, every 15 minutes, instead of every 5 seconds. ("But we
want our mail to go out right after we press the send button!")
I'm sorry, but any supposed MTA that is incapable of maintaining any
state about its own mail queue is simply a toy, not a real MTA.
Unfortunately, Mercury Mail was a toy that had just enough
functionality to be truly dangerous.
I did point out the more egregious shortcomings of Mercury Mail to
David Harris via email. I never received a response. I didn't expect
to, either: I was pointing out misfeatures, not bugs. The latter can
be easy to fix, but misfeatures are fundamental design flaws, and are
very difficult to fix. (To this day, I still don't know if Mercury
Mail was ever redesigned to associate state with queue entries. It
wouldn't surprise me if it still doesn't.)
I'm not disputing that Mercury Mail might have been useful to small
groups without enough expertise to run "real" mail infrastructures.
But for those of us who did run real mail infrastructures,
Mercury Mail was an agonizing curse. IMHO; its death is not only
well-deserved, but a decade late. (I generally dislike giving
Microsoft credit for anything, but Exchange is an order of magnitude
better than Mercury Mail.)
(For the record, I have no opinion on Pegasus; I never used it, and
never had issues with others who did. My vitriol is reserved solely
for Mercury Mail.)
I bear David Harris no personal ill will, but speaking as someone who
was largely responsible for the primary mail infrastructure at a large
university during the mid to late 1990s, and thus had to deal with
collateral damage caused by Mercury Mail, I fervently hope that the
disks containing the Mercury Mail source code are smashed into pieces.
Furthermore, I hope those pieces are placed in steel containers,
filled with concrete, and then dropped into a deep oceanic trench.
The only reason why MM mail existed was because it filled a
void: it was a mail (SMTP) server that ran on Novell NetWare. And to
paraphrase Dennis Ritchie, MM filled that void, and still
sucked.
Consider the following facts about MM:
The default (shipping) configuration was to be an open SMTP relay.
MM kept no state about messages in its outbound queue.
All new outbound messages were first placed into the queue to be
processed.
The default configuration was to process the outbound queue insanely
frequently—sleeping only 30 seconds or so (IIRC) between each
queue processing run.
MM wasn't a fully-functional relay. For any addresses that weren't
local, you needed to configure a "smart host" for it to hand off
messages to.
MM performed little or no DNS validation of envelope sender addresses.
The first issue (being an open relay by default) deserves no further
comment.
The "everything queues first" strategy is why the delay between
successive queue runs was insanely short by default; otherwise
outbound messages would have to sit in the queue for a while until the
next queue run picked them up and delivered them.
But because MM kept no state about messages in the queue, for each
queue run, it would treat every message as new. That didn't matter
for successful deliveries or permanent failures, but God help you if a
MM server were trying to relay a message to you and you tempfailed it,
because MM would retry again and again and again, and send a
DSN ("bounce") message to the sender every single damn
time.
So, here was the recipe for my misery: some doofus in some department
on campus would bring up a new Mercury Mail server. They'd figure out
they needed to list our mail server as the "relay server" in order for
outbound mail to work, but they wouldn't know to change any of the
other batshit default settings. Inevitably, a spammer would discover
that this shiny new MM server was an open relay, wait until Friday
evening (even better if it were over a holiday), and start using it to
spam. Sooner or later, the spammer would send a message with a
(forged) envelope sender whose domain would timeout if you tried to
verify it (look it up in DNS). MM would cheerfully accept it and
attempt to relay it to us; we'd tempfail that message. MM would then
generate a DSN to that bogus sender and send it via
relaying it to us, which we'd accept, but would be forced to queue
because we couldn't resolve the recipient's domain. The next time MM
ran its queue (usually, in just a few seconds), we'd get other DSN.
The result is that MM became not just a mail loop, but a mail
generator. If I were lucky, I'd catch the problem
before I left work on Friday. If I weren't, there'd be hundreds of
thousands of the DSN messages clogging our mail queues before Monday
morning rolled around, which was a gigantic mess to clean up.
I felt like I was playing Whack-A-Mole in hell: every time I'd smack
down one of the MM servers, another one would spring up a few weeks
later and the pattern would repeat again. I eventually just resorted
to blacklisting all MM servers as soon as I discovered them. This
often wound up pissing off some such-and-such important professor, but
it was the only way I could protect the mail infrastructure.
Maybe David Harris has made MM less drain-bamaged since then. (I
don't care; I've since moved on.) But I
In terms of FICO scores, although you always want to pay off your entire balance each month (to avoid finance/interest charges), when you pay that balance matters.
An example:
Person A charges $2,000 on his credit card each month. When he receives his credit card statements, they always show a total balance of $2,000. Each time, he pays off the entire $2,000 balance immediately.
Person B also charges $2,000 on his credit card each month. But each month, a few days before his statement period ends, he pays whatever his total balance is at that time. When he receives his next credit card statement, the total balance will be reflect only the charges he made on the last few days of his billing period (after he paid the current balance). He immediately pays whatever that total balance is.
Neither person A nor person B will have to pay any finance or interest charges. But person B's FICO score will be anywhere from 30 to 80 points higher than person A's FICO score.
Why? Because credit card companies send balance information to the credit agencies only once per month, and the balance information they send is the statement balance.
That means from the point of view of the credit agencies, person A is always carrying a $2,000 balance on his card, and person B is always carrying a trivially small balance ($0 or something close to it). Yes, person A is paying off the total balance each month. But the credit agencies can't know that, because the only data they receive each month is the statement balance, which is a snapshot in time. Fair Isaac & Co. looks at the credit reports and sees that person A is consistently carrying a higher balance than person B, and penalizes person A accordingly. (It's no secret that they do this; they flat-out tell you if you sign up for their credit report and FICO score monitoring service.)
I expect that the credit card companies and the credit agencies will eventually address this issue by communicating not just the monthly statement balance, but also the total charges and payments made each month. But until then, here's the bottom line: not only should you pay off your entire balance each month, but you want to do so before your billing cycle ends, so that the "total balance" amount on your statement is as small as possible.
As someone who has worked with AFS for the past 8 years, I have to say
that I greet this announcement with a somewhat more pessimistic view.
Namely: AFS is now officially dead.
I say "officially" because, IMO, AFS is
already dead, and has been for years (ever
since Transarc (now IBM Transarc Labs, but I'll refer to them as
Transarc for brevity)) came out with DCE/DFS, really).
Oh, there were bouts of heavy maintenance and limited development.
These periods were inevitably precipitated by Transarc's AFS customers
becoming vocal and complaining. But when the complaints died down, so
did Transarc's commitment.
Transarc has never treated AFS like a real product. Their
"development" efforts have been limited to ports to new versions of
the same operating systems, a few ports to new architectures,
bugfixes, and very limited feature additions (mostly backports
from DFS).
In fact, this year has seen Transarc's AFS support sink to a new low.
From what I've been able to garner, all AFS development is being
outsourced to India. Responses from Transarc's AFS hotline support (a
support service which customers purchase!) have been inept. There was
no Decorum (Transarc's yearly AFS conference) this year, nor even an
announcement concerning it. It's been ages since anyone from Transarc
has posted on the AFS mailing list.
So, why is Transarc (now IBM Transarc labs) open-sourcing AFS? For
one simple reason: AFS is IBM's red-headed stepchild, and they don't
know what else to do with it.
Yes. IBM recognizes that many of our customers will still want a
commercially-supported version of AFS IBM AFS. IBM/Transarc will
still sell, maintain, port (to new versions of currently-supported
OS), support, and provide minor enhancements to "IBM AFS".
Good software grows or dies. AFS died a long time ago. I,
personally, think this is tragic, because AFS had great potential.
But Transarc never made a long-term commitment to anything other than
keeping it on life support. Perhaps it can be resuscitated back to
health, but I can't help but wonder if the Open Source community's
effort would be better spent towards other distributed filesystems
efforts, such as CODA (which
I admittedly haven't investigated, but plan to).
Slashdot Mirror
It's worth reading the changes that S.1 Section 220 proposes quite carefully, because I think some of the criticisms here are off-base. Consider:
This isn't about going after bloggers. Rather, S.1 appears to be attempt to register astroturfers as lobbyists.
If you're a blogger, and some organization writes you a big fat check to post in your blog about how bad some particular Senate or House bill is and gosh we should all contact Congress and object to it, then I'm sorry, but I don't see how you can claim that you're not a lobbyist.
And although I'm still oscillating somewhat, I tentatively think that your being required to register your activities as lobbying is a Good Thing, because those who read your blog (or email, or whatever) might wish to know that you were paid specifically to influence people to take action.
I'm not saying you have to be an astroturfer to object to this bill. But based on the virtually-hysterical frothing I've seen from certain organizations, I think it helps.
If you do nothing else, read the changes that S.1 proposes, and decide for yourself: is S.1 an attempt to silence criticism of the government, or an attempt to drag astroturfers into the sunlight? Whose interests do those who are ranting about S.1 Section 220 have at heart—free speech, or their pocketbooks?
The quality of the product should be questioned because the author did not have adequate understanding of MTAs and Internet mail. As a result, he released an MTA that, in essence, would DoS other MTAs under certain (and not particular uncommon) conditions.
Imagine if an auto manufacturer produced a car that people love to drive because it's comfortable, gets good fuel economy, etc. The car just has one teeny defect, however: unless you know how to tune it properly, it occasionally backfires a 50-foot fireball that sets everything behind it in a 120 degree arc on fire—buildings, pedestrians, trees, pets, etc.
Speaking as one of the burn victims, your arguments about how great the car is to the driver are irrelevant. I don't care if it has a hole in the seat to give you a blowjob while you drive; the car is a danger to everyone else.
Now, finally, after many years, the car manufacturer has gone out of business. No more of these cars will be produced. This is a good thing. Do not resuscitate the company. And for God's sake, do not open source the blueprints for the car so some other idiots can start making them again.
Resuscitate Pegasus Mail if you think it's worthwhile to do so, but only under the condition that resuscitating Pegasus Mail doesn't also breathe more life into Mercury Mail.
When I left the university in 1999, the problems with open relay Mercury Mail servers were still quite severe. No one else was still shipping SMTP servers that were open relays by default by then.
And of course the users could edit the .INI file; they
had to in order to configure it to use our relay
servers (so Mercury Mail could actually send mail). But the vast
majority of the people running Mercury Mail had so little mail
experience that they didn't even know what an open relay was, let
alone why it was Bad Thing. That was the entire point of Mercury
Mail; it was a product aimed at people who wanted to run a mail server
but didn't really have enough expertise to know how to do so.
Besides, as I already said, most of the bad defaults were deliberately chosen, in order to cover up glaring deficiencies in functionality (e.g., a stateless mail queue).
Again, I bear David Harris no ill will. But he unleashed an SMTP server onto the world that was a horrifically bad Net.citizen, and he either didn't realize that (unlikely), or simply didn't care because it didn't affect his bottom line. I don't care what happens to Pegasus (because I never had issues with it), but please, let Mercury Mail die. God help us if that code is released as open-source and then recycled back into new products.
You misunderstand. (Perhaps I wasn't clear in my original post, so I'll attempt to clarify.)
The group in which I worked provide core computing services for the entire university; that is, we made <user@example.edu> email addresses work. We did not use Mercury Mail; we used Solaris machines running sendmail and AMDS. The core mail infrastructure had to handle 30,000+ users, and had to be available 24x7x365, because it was what most people used.
Some departments deployed their own mail systems; e.g., <user@ee.example.edu>. Most of them made no attempt to coordinate with us, and with university politics being what they are, we couldn't compel them to cooperate with us. Since virtually no departments (outside of CS and IS) had people familiar with unix/sendmail systems in-house, Mercury Mail was a popular choice.
In other words, Mercury Mail was appealing to precisely the type of people who shouldn't have been running it: people who lacked enough expertise with Internet mail systems to recognize that the defaults were extremely dangerous.
You missed my point about the default settings. Other than shipping as an open relay by default (which no respectable MTA had done for years), most of the "poor defaults" were necessitated by the fundamental design flaws of Mercury Mail. We'd get pushback from departments when we asked them to set the queue processing interval to, say, every 15 minutes, instead of every 5 seconds. ("But we want our mail to go out right after we press the send button!")
I'm sorry, but any supposed MTA that is incapable of maintaining any state about its own mail queue is simply a toy, not a real MTA. Unfortunately, Mercury Mail was a toy that had just enough functionality to be truly dangerous.
I did point out the more egregious shortcomings of Mercury Mail to David Harris via email. I never received a response. I didn't expect to, either: I was pointing out misfeatures, not bugs. The latter can be easy to fix, but misfeatures are fundamental design flaws, and are very difficult to fix. (To this day, I still don't know if Mercury Mail was ever redesigned to associate state with queue entries. It wouldn't surprise me if it still doesn't.)
I'm not disputing that Mercury Mail might have been useful to small groups without enough expertise to run "real" mail infrastructures. But for those of us who did run real mail infrastructures, Mercury Mail was an agonizing curse. IMHO; its death is not only well-deserved, but a decade late. (I generally dislike giving Microsoft credit for anything, but Exchange is an order of magnitude better than Mercury Mail.)
(For the record, I have no opinion on Pegasus; I never used it, and never had issues with others who did. My vitriol is reserved solely for Mercury Mail.)
I bear David Harris no personal ill will, but speaking as someone who was largely responsible for the primary mail infrastructure at a large university during the mid to late 1990s, and thus had to deal with collateral damage caused by Mercury Mail, I fervently hope that the disks containing the Mercury Mail source code are smashed into pieces. Furthermore, I hope those pieces are placed in steel containers, filled with concrete, and then dropped into a deep oceanic trench.
The only reason why MM mail existed was because it filled a void: it was a mail (SMTP) server that ran on Novell NetWare. And to paraphrase Dennis Ritchie, MM filled that void, and still sucked.
Consider the following facts about MM:
The first issue (being an open relay by default) deserves no further comment.
The "everything queues first" strategy is why the delay between successive queue runs was insanely short by default; otherwise outbound messages would have to sit in the queue for a while until the next queue run picked them up and delivered them.
But because MM kept no state about messages in the queue, for each queue run, it would treat every message as new. That didn't matter for successful deliveries or permanent failures, but God help you if a MM server were trying to relay a message to you and you tempfailed it, because MM would retry again and again and again, and send a DSN ("bounce") message to the sender every single damn time.
So, here was the recipe for my misery: some doofus in some department on campus would bring up a new Mercury Mail server. They'd figure out they needed to list our mail server as the "relay server" in order for outbound mail to work, but they wouldn't know to change any of the other batshit default settings. Inevitably, a spammer would discover that this shiny new MM server was an open relay, wait until Friday evening (even better if it were over a holiday), and start using it to spam. Sooner or later, the spammer would send a message with a (forged) envelope sender whose domain would timeout if you tried to verify it (look it up in DNS). MM would cheerfully accept it and attempt to relay it to us; we'd tempfail that message. MM would then generate a DSN to that bogus sender and send it via relaying it to us, which we'd accept, but would be forced to queue because we couldn't resolve the recipient's domain. The next time MM ran its queue (usually, in just a few seconds), we'd get other DSN.
The result is that MM became not just a mail loop, but a mail generator. If I were lucky, I'd catch the problem before I left work on Friday. If I weren't, there'd be hundreds of thousands of the DSN messages clogging our mail queues before Monday morning rolled around, which was a gigantic mess to clean up.
I felt like I was playing Whack-A-Mole in hell: every time I'd smack down one of the MM servers, another one would spring up a few weeks later and the pattern would repeat again. I eventually just resorted to blacklisting all MM servers as soon as I discovered them. This often wound up pissing off some such-and-such important professor, but it was the only way I could protect the mail infrastructure.
Maybe David Harris has made MM less drain-bamaged since then. (I don't care; I've since moved on.) But I
I've never had a credit card that reported a monthly balance to the credit agencies that wasn't the statement balance.
The way to tell: simply look at your credit report. The balances reported by your credit card companies should match your statement balances.
On the page http://www.privacyrights.org/fs/fs6c-CreditScores. htm, the answer to the "Does it improve my score to pay off my credit card balance every month?" question is highly misleading, if not outright wrong.
In terms of FICO scores, although you always want to pay off your entire balance each month (to avoid finance/interest charges), when you pay that balance matters.
An example:
Person A charges $2,000 on his credit card each month. When he receives his credit card statements, they always show a total balance of $2,000. Each time, he pays off the entire $2,000 balance immediately.
Person B also charges $2,000 on his credit card each month. But each month, a few days before his statement period ends, he pays whatever his total balance is at that time. When he receives his next credit card statement, the total balance will be reflect only the charges he made on the last few days of his billing period (after he paid the current balance). He immediately pays whatever that total balance is.
Neither person A nor person B will have to pay any finance or interest charges. But person B's FICO score will be anywhere from 30 to 80 points higher than person A's FICO score.
Why? Because credit card companies send balance information to the credit agencies only once per month, and the balance information they send is the statement balance.
That means from the point of view of the credit agencies, person A is always carrying a $2,000 balance on his card, and person B is always carrying a trivially small balance ($0 or something close to it). Yes, person A is paying off the total balance each month. But the credit agencies can't know that, because the only data they receive each month is the statement balance, which is a snapshot in time. Fair Isaac & Co. looks at the credit reports and sees that person A is consistently carrying a higher balance than person B, and penalizes person A accordingly. (It's no secret that they do this; they flat-out tell you if you sign up for their credit report and FICO score monitoring service.)
I expect that the credit card companies and the credit agencies will eventually address this issue by communicating not just the monthly statement balance, but also the total charges and payments made each month. But until then, here's the bottom line: not only should you pay off your entire balance each month, but you want to do so before your billing cycle ends, so that the "total balance" amount on your statement is as small as possible.
As someone who has worked with AFS for the past 8 years, I have to say that I greet this announcement with a somewhat more pessimistic view.
Namely: AFS is now officially dead.
I say "officially" because, IMO, AFS is already dead, and has been for years (ever since Transarc (now IBM Transarc Labs, but I'll refer to them as Transarc for brevity)) came out with DCE/DFS, really).
Oh, there were bouts of heavy maintenance and limited development. These periods were inevitably precipitated by Transarc's AFS customers becoming vocal and complaining. But when the complaints died down, so did Transarc's commitment.
Transarc has never treated AFS like a real product. Their "development" efforts have been limited to ports to new versions of the same operating systems, a few ports to new architectures, bugfixes, and very limited feature additions (mostly backports from DFS).
In fact, this year has seen Transarc's AFS support sink to a new low. From what I've been able to garner, all AFS development is being outsourced to India. Responses from Transarc's AFS hotline support (a support service which customers purchase!) have been inept. There was no Decorum (Transarc's yearly AFS conference) this year, nor even an announcement concerning it. It's been ages since anyone from Transarc has posted on the AFS mailing list.
So, why is Transarc (now IBM Transarc labs) open-sourcing AFS? For one simple reason: AFS is IBM's red-headed stepchild, and they don't know what else to do with it.
If you read the announcement at http://www.transarc.com/News/pre ss/opensource.html, you'll note this entry in the FAQ:
Good software grows or dies. AFS died a long time ago. I, personally, think this is tragic, because AFS had great potential. But Transarc never made a long-term commitment to anything other than keeping it on life support. Perhaps it can be resuscitated back to health, but I can't help but wonder if the Open Source community's effort would be better spent towards other distributed filesystems efforts, such as CODA (which I admittedly haven't investigated, but plan to).