Re: Reporting problem (found problem: COMCAST)
Blammo <[email protected]>
| Newsgroups | gmane.mail.spam.spamcop.help |
|---|---|
| Organization | RM Gates |
| Message-ID | <[email protected]> |
On 24 Jul 2005 Brian Hetrick entered spamcop.help and left news:[email protected]: > "Blammo" wrote ... >> So why do you put up with stupid mail hosts and ISPs? > > For the same reason I put up with SpamCop needing _two_ clicks to > process a spam, when a single confirm this one/process next one button > would do. > > A distinct difference... Submitting a form has to return a message, or a location redirect, can't do both. This also requires quite a bit of logic to get it to work "bug free"; the return script would have to determine - after confirming no errors - what the next waiting report ID would be, rather than the more reliable way it's determined at page load now. Even if this location redirect were enabled, we would miss out on any confirm messages, and it would take the exact same amount of time - minus the short time one click takes. There are other reasonable alternatives, involving Javascript or tabbing order, which won't speed anything up either, but I do think a tabbing order would be nice. Mail filtering by ISPs is done in order to gain approval of their customers, as it does practically nothing to improve their service. You could say "oh, I never get viruses, because they block EVERYTHING, I can only send plain text". While they scan the entire message body of every single eMail, which in turn consumes resources, which costs you money, all to protect you from that 1 in a million chance that you might send an infected .eml through their mail server (or some such silly nonsense), so you can shout out "my ISP protects my infected computer from infecting the rest of the Internet". Obviously none of this really works, which you have proved by working around it to do something you have every right to (ironically, to report abuse). In short, you are comparing some inconvenience to a complete lack of functionality. -- | Ric |