What amazes me is that it's automagically assumed that a code-cutter also has business sense to run a successful business.
Remember at the end of the day he's a code-cutter... not a suit... if he was a suit.. he wouldn't be a code-cutter now would he!:[
I must admit as a code-cutter I'm sick of many businesses idea of 'yeah... lets' get it under the GPL... we can use, abuse and not pay for it'.
Bad Karma to this idea of thinking... These fat-cats still drive home to a nice warm bed, big meal and watch their TV.
How about flipping some $$'s towards the smuck that did all your hard work and ensure he's still around next year when you have a real question abuot the software.
At the end of the day... nothing is FREE... someone pays... unfortunately with a lot of GPL.. it's normally the developer and his family.:(
I run several commercal sites... one is even a large shopping mall... which gets hammered.
It really is about what is compiled in.
It's the old rule, if it's not needed, don't compile it in, it also saves on memory usage and is one less thing that can break/be vulnerable.:)
I do believe the way we tackle SPAM and Email in general is outdated.
SMTP based on RFC821 relies soley on the principle of:
User sends mail to target sender.
Mail goes to their SMTP server
Mail 'finally' arrives at the recievers SMTP server.
The problem with this is that there is no verifcation from the end-user that the mail is legit.
A much better solution would be based on user verification.
This in theory would work on the principle that the we are creatures of habit.
We all recieve legit Email from a small trusted group. Anything not based on the trusted group is potentially unwanted mail.
A verified Email transport would work like such:
Reciever builds a list of trusted Email senders.
The trusted list is uploaded to the recievers SMTP server.
A mail sender sends an email.
The senders SMTP server sends a message envelope to the recievers SMTP server. (contains just the senders smtp address).
The message is stored on the Senders SMTP server awaiting verification from the remote end.
The Recieving SMTP server checks the envelope against the user 'whitelist'.
If the sender is on the recievers whitelist - the RECIEVERS SMTP server confirms that this is legit.
Senders SMTP message delivers the message to the Remote SMTP server.
If the Email is NOT on the whitelist, the SMTP server sends a WAIT for further instructions message to the Sending SMTP server.
The user then can review the 'envelopes' and decide whether to recieve/remove the offending email.
If removed - the Recievers SMTP server sends a message back to the remote Senders SMTP server to say not to send.
If a response is never recieved by the Sending SMTP - the message is deleted after 30 days.
This has some added benefits:
Legit mail recieves a higher priority.:)
SPAM is not Blindly Sent but is only initiated at the 'Recievers request'.
Network Traffic is cut considerably.
The cost of storage of the SPAM is held at the remote end (SPAMMERS ISP).
The Spammers ISP could legitimately then charge the SPAMMER for 'unsent' Mail storage.:)
This is only a thought -- and would need to round out the idea - however it seems feasable that this is possible.
Interested in others comments.
Most Spam filtering software already includes 'WhiteLists/BlackLists'.
Moving this into the SMTP transport at the server end seems the next logical and automated approach.
Slashdot Mirror
Web-cam shows grass growing...
What amazes me is that it's automagically assumed that a code-cutter also has business sense to run a successful business.
:[
:(
Remember at the end of the day he's a code-cutter... not a suit... if he was a suit.. he wouldn't be a code-cutter now would he!
I must admit as a code-cutter I'm sick of many businesses idea of 'yeah... lets' get it under the GPL... we can use, abuse and not pay for it'.
Bad Karma to this idea of thinking...
These fat-cats still drive home to a nice warm bed, big meal and watch their TV.
How about flipping some $$'s towards the smuck that did all your hard work and ensure he's still around next year when you have a real question abuot the software.
At the end of the day... nothing is FREE... someone pays... unfortunately with a lot of GPL.. it's normally the developer and his family.
I can see it now...
/me goes back to hacking chair... ;)
My leather reclinerwill accept incoming SMS messages in a vibrate mode!
Believe me... take a look at their Marketing Strategy!
http://www.specopslabs.com/market.htm
Cheers, Matt.
68% of all statistics are made up...
Looks perfect on this monochrome monitor. :)
I've been using Apache2 now for some time.
I run several commercal sites... one is even a large shopping mall... which gets hammered.
It really is about what is compiled in. :)
It's the old rule, if it's not needed, don't compile it in, it also saves on memory usage and is one less thing that can break/be vulnerable.
So that's where the Russians, Chinese, Nth Koreans, and the US have been hiding them... And you always wondered what was on the dark side of the moon!
Now that's eating ya words! :)
Yup... Seems another great MS product... Take a look at the file set on SourceForge: http://sourceforge.net/project/showfiles.php?group _id=105970
- How much pot one could smoke...
- Many many times you were laid in a semester.
Obviously he not undertaking the same major...SMTP based on RFC821 relies soley on the principle of:
- User sends mail to target sender.
- Mail goes to their SMTP server
- Mail 'finally' arrives at the recievers SMTP server.
The problem with this is that there is no verifcation from the end-user that the mail is legit.A much better solution would be based on user verification.
This in theory would work on the principle that the we are creatures of habit.
We all recieve legit Email from a small trusted group. Anything not based on the trusted group is potentially unwanted mail.
A verified Email transport would work like such:
This has some added benefits:
This is only a thought -- and would need to round out the idea - however it seems feasable that this is possible.
Interested in others comments.
Most Spam filtering software already includes 'WhiteLists/BlackLists'.
MB.Moving this into the SMTP transport at the server end seems the next logical and automated approach.
Hmm.. I wonder if I can find share the amnestiy form? Maybe we all fill out the form using Mr. JackAss as the name and then all submit that. :)
It must just be me...
I look at their stock code "SCOX" -- Does anyone else think it says: SUCK C*X"
Hmm.... I think they are getting the message:
"SUCK EGGS".