Value too large for defined data type
Hi all, maybe it's not right place for my question, but... There is such message (look at Subj.) when I try to ls, rm, du or something else with one my big (more than 2Gb) file. How can I remove it? It will be enough for me at this time :-) I use potato with 2.4.18 kernel, if it can help someone to help me... Thanks in advance, IOpuk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: Spamassasin over RBL, was Re: rblsmtpd -t?]
> > > > Using your mentality, then everything always gets escalated to the highest > > point (since everyone below the top-most ISP is essentially a customer). > > So... essentially, the highest point is nearly always the network > > provider... UUnet, Level3, MCIWorldcom... whomever owns the actual > > physical cable. > > > > Calm down and think it through. > > There is a chain of responsiblity and any incident can be escalated. > > If ISP1 is on Sprint and ISP1 takes no action about > spam from spammer-leaf-node-on-ISP1, then one needs to escalate to > Sprint to take action to enforce aup on ISP1. If it turns out that > sprint pipes mail to abuse@ into /dev/null, or even has a yellow > contract with ISP1 that permits spam, then what? Or it might be > that an ISP is trying to do something about a customer (monsterhut) > or is just half-assed. Maybe you use rfc-ignorant. I understand completely on what you are trying to say. Naturally, if a downstream customer of, for example, UUnet, refuses to take any action against their spamming users, then UUnet must step in to do something. However, my point is... on the actual size of the "customer". For example... if the customer was small ISP with 500 users, then 100 spam complaints against that small ISP would obviously mean something is seriously wrong with that small ISP (technically, or otherwise), and UUnet would be justified in either cutting off the small ISP or doing other similar actions. If the customer was a large ISP with 5M users, then 100 spam complaints doesn't seem so many when you look at it from a top-down picture, and UUnet may not be justified in cutting off that large ISP for those complaints, EVEN THOUGH the number of complaints is the same as the small ISP. Now... if the complaints were 10,000, then obviously they have a problem... if you agree with this thinking, then we are thinking along the terms of ratios and mail volumes, and then we start looking at the methods employed by RBLs like Spamcop. Hence, it makes sense that large customers (such as large ISPs, Universities, etc.) are given more breathing room regarding complaints, and are allowed to handle this more. Does this make sense? > > It's also possible that your standards might not jibe with everyone > elses. Me, I think any site sending email that will not accept bounces > deserves to go into RBL. Not everyone would even qualify such email > as spam, but we do. I thought there was more-or-less a standard "definition" of "spam"... unsolicited bulk email. Are bounces going to /dev/null, or such, unsolicited bulk email? Perhaps I am mistaken regarding the definition. > You might decide that your customers cannot live without Sprint. You > might decide that they cannot live **long term** with such actions. Or > you might give them a choice. Well... if it was personal email, i could probably accept it. For business email, even a few missed customer emails would be more than unacceptable. So RBLs that employ "netblock"-wide filters are unacceptable... only ones that target specific IPs would do well as they, obviously, would have less effect that a block on a whole ISP like Sprint. That would mean more spam gets through, but as a business, i think that is better. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: Spamassasin over RBL, was Re: rblsmtpd -t?]
On Fri, May 10, 2002 at 07:19:27AM +0800, Jason Lim wrote: > > > On Wed, May 08, 2002 at 10:56:12PM +0200, Emile van Bergen wrote: > > > > what has size got to do with it? > > > > > > Because the distinction between a customer and an ISP is not clear. > > > [...] > > > > that was a tautology. it only matters if you think size is relevant. > > > > it doesn't matter in the slightest whether an ISP's customer is another > > ISP or not. > > Using your mentality, then everything always gets escalated to the highest > point (since everyone below the top-most ISP is essentially a customer). > So... essentially, the highest point is nearly always the network > provider... UUnet, Level3, MCIWorldcom... whomever owns the actual > physical cable. > Calm down and think it through. There is a chain of responsiblity and any incident can be escalated. If ISP1 is on Sprint and ISP1 takes no action about spam from spammer-leaf-node-on-ISP1, then one needs to escalate to Sprint to take action to enforce aup on ISP1. If it turns out that sprint pipes mail to abuse@ into /dev/null, or even has a yellow contract with ISP1 that permits spam, then what? Or it might be that an ISP is trying to do something about a customer (monsterhut) or is just half-assed. Maybe you use rfc-ignorant. It's also possible that your standards might not jibe with everyone elses. Me, I think any site sending email that will not accept bounces deserves to go into RBL. Not everyone would even qualify such email as spam, but we do. You might decide that your customers cannot live without Sprint. You might decide that they cannot live **long term** with such actions. Or you might give them a choice. -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Content/site management, online commerce, internet integration, Debian linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: Spamassasin over RBL, was Re: rblsmtpd -t?]
> On Wed, May 08, 2002 at 10:56:12PM +0200, Emile van Bergen wrote: > > > what has size got to do with it? > > > > Because the distinction between a customer and an ISP is not clear. > > [...] > > that was a tautology. it only matters if you think size is relevant. > > it doesn't matter in the slightest whether an ISP's customer is another > ISP or not. Using your mentality, then everything always gets escalated to the highest point (since everyone below the top-most ISP is essentially a customer). So... essentially, the highest point is nearly always the network provider... UUnet, Level3, MCIWorldcom... whomever owns the actual physical cable. So, continuing on that, you will have the 4 or 5 big physical network operators, each being responsible for all their downstream customers. An RBL will essentially hold each of these 4 or 5 physical network operators responsible for any spam that originates with their network. How impossible is that? You would essentially making the big 5 operators Gods of Email... controlling everything. And you would then have the situation that all the customers of, for example, UUnet, would not use any RBL because if they did, and that RBL decided that UUnet was responsible for spam, then they themselves would be blocked (just like many Asian ISPs do not use RBLs because many RBLs just block all mail from Asia, so they would in essense be blocking themselves). > > Qwest is an ISP. Is it responsible for mail sent from their ISP > > customers? > > yes. absolutely. without exception. they are responsible for all mail > sent by their customers. Read above, and you will see what will happen from that. > > Perhaps they should be. Then, would you say, if a large percentage of > > their customer ISPs are spamha?ser (plural for spamhaus), should we > > start blocking all mail from Qwest? > > yes. if a significant amount of spam is coming out of qwest and they > are doing little or nothing to stop it then they should be black-listed. Read above, and you will see what will happen from that... if you hold the large providers responsible for all their customers email, the end result is that no users will use the RBL for fear that their own network provider will be blacklisted by the RBL. > > At which percentage? How can we measure that? Using spam messages vs. > > total output perhaps? That sounds remarkably like what Spamcop's > > doing. So which criteria would *you* choose? You seem avoiding that > > question. > > at no percentage. it's about quantity of spam received versus their > willingness and/or ability to do something about their spammer customers > - as judged by competent people with several years experience in > anti-spam activities. Ah ha... foot in mouth again. A small ISP with, for example, 500 customers, will find it very easy to shut down the account of a spammer. Perhaps you can explain how Hotmail, or any number of large freemail service providers, can do the same just as easily? If you agree that it is harder for large providers to act just as fast as a small provider, then you will see that there IS a difference between the way a small and large provider act regarding complaints and spam. So that, by itself, proves that your logic of "size and mail volume does not matter" is immediately flawed and incorrect. > technological decisions and judgements should be made by those who are > competent to make them, not by democratic processes or by giving equal > weight to the opinions of experts and the ignorant/stupid. Then you think the US democratic process and people, whereby all are given a vote and have the ability to shape the outcome, is stupid. Are you American? > > Hence my question. Apparently you see a big and fundamental difference > > between an ISP, who would be allowed to do direct to MX SMTP, and a > > customer, who would not be allowed to do direct to MX SMTP. > > no, stop putting bullshit words in my mouth. > > i see a fundamental difference between dynamic IP address and static IP > addresses. All your focus seems to go on dynamic IPs... yet you fail to see that those on static IPs will probably have higher bandwidth, and hence can do far more damage than any user on dynamic IPs. > > > are you being genuinely stupid or is this a deliberate attempt to put > > > straw-man words in my mouth? > > > > Just continue assuming I'm stupid. That's fine with me, if that helps. > > you're doing a damn good job of proving that you are stupid. > > Of course not. But now I understand. You were basically assuming that > > everyone agrees that > > > > 1. ISP is equivalent to static IPs, and > > 2. Customer is equivalent to dynamic IP. > > stop putting words in my mouth. especially stop putting cretinous words > in my mouth. But thats the way other people see your standpoint... ISP = static IP and allowed to send direct-to-mx mail, Customer = dynamic IP and forced to use upstream's mail servers. Perhaps if people are not seeing your point of vi
