Rising seas, caused by global warming, have for the first time washed an inhabited island off the face of the Earth. The obliteration of Lohachara island, in India's part of the Sundarbans where the Ganges and the Brahmaputra rivers empty into the Bay of Bengal, marks the moment when one of the most apocalyptic predictions of environmentalists and climate scientists has started coming true.
My view, doesn't this have anything to do with plate tectonics?
Monday, December 25, 2006
Saturday, December 23, 2006
Behoud de Kamp (1) Opnieuw bezwaren tegen plan
STEENWIJK – Bij de gemeente Steenwijkerland zijn 155 zienswijzen binnengekomen tegen de hernieuwde procedure rond bestemmingsplan De Schans, het zeer omstreden plan voor bebouwing van de Steenwijker Kamp.
De Raad van State vernietigde in oktober het gemeentelijk besluit voor de vaststelling van dit bestemmingsplan, alsmede het goedkeuringsbesluit van de provincie Overijssel, omdat er procedurefouten waren gemaakt.
De gemeente moest het plan opnieuw in procedure brengen en afgelopen woensdag sloot de termijn voor het indienen van de bezwaren. Volgens gemeenteambtenaar Jan Mulder is het aantal bezwaren nagenoeg hetzelfde als de vorige keer. `Toen waren er zo’n 150 en een aantal dat niet ontvankelijk was verklaard.'
Bestemmingsplan De Schans staat voor behandeling op de agenda van een extra commissievergadering op 17 januari en de raad op 23 januari.
Meer over het laatste nieuws rond bestemmingsplan De Schans en een interview met een van de bezwaarmakers, die opnieuw in de pen is geklommen - Klaas Brinkman uit Steenwijk -, in de Opregte Steenwijker Courant van vrijdag 22 december.
De Raad van State vernietigde in oktober het gemeentelijk besluit voor de vaststelling van dit bestemmingsplan, alsmede het goedkeuringsbesluit van de provincie Overijssel, omdat er procedurefouten waren gemaakt.
De gemeente moest het plan opnieuw in procedure brengen en afgelopen woensdag sloot de termijn voor het indienen van de bezwaren. Volgens gemeenteambtenaar Jan Mulder is het aantal bezwaren nagenoeg hetzelfde als de vorige keer. `Toen waren er zo’n 150 en een aantal dat niet ontvankelijk was verklaard.'
Bestemmingsplan De Schans staat voor behandeling op de agenda van een extra commissievergadering op 17 januari en de raad op 23 januari.
Meer over het laatste nieuws rond bestemmingsplan De Schans en een interview met een van de bezwaarmakers, die opnieuw in de pen is geklommen - Klaas Brinkman uit Steenwijk -, in de Opregte Steenwijker Courant van vrijdag 22 december.
Friday, December 22, 2006
How to reduce spam
These days people fight spam anywhere except at the source. I agree with the slashdot poster suggesting E2EASMTP to get rid of spam, maybe people think this is not the answer, but hey, Bill Gates promised to solve the spam problem before 2007..
What we really need is E2EASMTP: End-to-end Authenticated SMTP. The design is basically just the existing SMTP. The only changes are as follows:
1. All mail servers require an SSL key. This is assigned by the registrar when you purchase a domain. This key may be shared among multiple hosts within the same domain.
2. All mail servers must require SMTP-Auth for outbound traffic.
3. All mail servers must sign each piece of mail as it passes through their systems. This signature must sign the complete message, including the signatures of previous servers in the path.
4. All mail servers must support an automated abuse handling mailbox, autoabuse@domain for responses to spam messages.
5. All mail servers must forward automated abuse messages appropriately by verifying its own email signature (sending an abuse bounce-back if it does not match) and then forwarding the abuse report to the mail server that send the message to it in the first place.
6. Upon receipt of a certain number (determined as a site policy) of reports of spam or other junk emails from a given user, the mail server should automatically email that user to notify him/her that his computer is compromised and block any and all emails from that user until it is reset.
7. All ISPs should take reasonable care not to reinstate mail sending privileges until they are sure that the user's computer is clean.
8. ISPs are encouraged to manually look at any blocked accounts as soon as they become blocked to make sure that the messages really are spam/phishing.
The key is that the entire abuse reporting process should be automated and that no email messages without an initial host signature should be delivered. This will make it impossible for continued operation of spam zombies in two ways:
1. It will prevent them from sending mail directly by running an SMTP server on the compromised computer.
2. It will prevent them from continuing to send mail through an ISP's mail server by ensuring that the mail messages can be traced back to a single individual user of the originating ISP, where the messages will be automatically blocked in a timely fashion.
In effect, by ensuring a trusted (albeit not necessarily encrypted) path for all email messages, you make spamming orders of magnitude harder with minimal performance impact. Best of all, I think that this could be implemented with relatively minor additions to the SMTP protocol and phased in over a period of time, ensuring a smooth transition from the spam nightmare we have now to a more modern, usable email infrastructure.
What we really need is E2EASMTP: End-to-end Authenticated SMTP. The design is basically just the existing SMTP. The only changes are as follows:
1. All mail servers require an SSL key. This is assigned by the registrar when you purchase a domain. This key may be shared among multiple hosts within the same domain.
2. All mail servers must require SMTP-Auth for outbound traffic.
3. All mail servers must sign each piece of mail as it passes through their systems. This signature must sign the complete message, including the signatures of previous servers in the path.
4. All mail servers must support an automated abuse handling mailbox, autoabuse@domain for responses to spam messages.
5. All mail servers must forward automated abuse messages appropriately by verifying its own email signature (sending an abuse bounce-back if it does not match) and then forwarding the abuse report to the mail server that send the message to it in the first place.
6. Upon receipt of a certain number (determined as a site policy) of reports of spam or other junk emails from a given user, the mail server should automatically email that user to notify him/her that his computer is compromised and block any and all emails from that user until it is reset.
7. All ISPs should take reasonable care not to reinstate mail sending privileges until they are sure that the user's computer is clean.
8. ISPs are encouraged to manually look at any blocked accounts as soon as they become blocked to make sure that the messages really are spam/phishing.
The key is that the entire abuse reporting process should be automated and that no email messages without an initial host signature should be delivered. This will make it impossible for continued operation of spam zombies in two ways:
1. It will prevent them from sending mail directly by running an SMTP server on the compromised computer.
2. It will prevent them from continuing to send mail through an ISP's mail server by ensuring that the mail messages can be traced back to a single individual user of the originating ISP, where the messages will be automatically blocked in a timely fashion.
In effect, by ensuring a trusted (albeit not necessarily encrypted) path for all email messages, you make spamming orders of magnitude harder with minimal performance impact. Best of all, I think that this could be implemented with relatively minor additions to the SMTP protocol and phased in over a period of time, ensuring a smooth transition from the spam nightmare we have now to a more modern, usable email infrastructure.
Subscribe to:
Comments (Atom)