Si quieres desasociar tu cuenta de Google de tu teléfono con Android, bien sea para asociar otra o simplemente para volver a asociar la misma, es posible que hayas dado muchas vueltas por todos los menús y opciones del teléfono sin éxito.

Si es así, has estado cerca de la solución, seguro.

El método a seguir es:

Ir al Menú -> Ajustes -> Aplicaciones -> Administrar Aplicaciones, buscar Google Apps, seleccionarlo y entonces pulsar Borrar datos.

Ya podrás volver a abrir una aplicación de Google, Gmail por ejemplo, y aparecerá el asistente para configurar tu cuenta Google asociada al teléfono.

Me lo dejo por aquí apuntado por si vuelvo a necesitarlo.

Tags: Android, google, HTC Magic

En alguna ocasión puede ser interesante configurar nuestro equipo para que realice las resoluciones de nombres contra servidores DNS diferentes dependiendo del dominio preguntado.

Un caso habitual se produce cuando nuestro equipo pertenece a la red local de nuestra empresa, por ejemplo, a la vez que tiene acceso a otra red en la que hay dominios diferentes del local y sin posibilidad de relacionarlos. Pongamos por ejemplo, internet.

En este escenario, tenemos un equipo que queremos que resuelva direcciones de dominios válidos en internet y a la vez que resuelva direcciones de nuestro dominio local, que no tiene por que ser válido en internet, ni estar registrado como tal.

En una configuración típica, especificaríamos una lista de servidores DNS a utilizar en orden, de forma que las consultas se harían siempre al primero de la lista y solo se consultaría al segundo si el primero no respondiese por algún motivo.

En este caso, si el primer servidor DNS de la lista es el correspondiente a nuestro dominio local, este resolverá los nombres que conoce, y no lo hará para dominios públicos, como por ejemplo google.es. Podríamos configurar nuestro(s) servidor(es) DNS locales para que reenviasen las peticiones que no supiesen resolver a otros servidores, incluso públicos.

De hecho, este sería el funcionamiento normal y lógico de los servidores DNS.

El problema se plantea cuando nuestros servidores DNS locales no pueden reenviar las peticiones a servidores públicos, siendo la razón más común que nuestra red se encuentra aislada de internet.

Resumiendo, no podemos aprovecharnos de los reenvíos de los servidores DNS, porque ninguno de los dos disponibles conoce nada del otro, ni tiene forma de conocerlo.

Para solventarlo, podemos instruir a nuestro cliente DNS (resolver) para que utilice en cada momento el servidor DNS que nos interese. Para ello, hemos de crear un fichero, con el nombre de la red privada, en:

/etc/resolver/dominiolocal.com

En este fichero, pondremos los servidores DNS que queremos que resuelvan las peticiones para el dominio dominiolocal.com, de la forma:

nameserver 1.2.3.4
nameserver 1.2.3.5

De esta forma, nuestro cliente DNS utilizará siempre los servidores de nombres que tengamos definidos en nuestro sistema (en /etc/resolv.conf) para resolver cualquier dominio (todos los públicos), mientras que cuando se le solicite la dirección de un equipo de nuestra red local (equipo.dominiolocal.com), consultará a los servidores definidos en /etc/resolver/dominiolocal.com.

Más información sobre el fantástico cliente DNS de Mac OS X en:

man 5 resolver

Tags: DNS, internet, Mac OS X, redes

A celebrar el próximo día 6 de febrero de 2009, en Adeje, organizada por el Ayuntamiento de Adeje, con los siguientes objetivos:

• Promover espacios de discusión de ideas tendentes a mejorar los servicios al ciudadano por parte de las AA.PP. a través de las Tecnologías de la Información y la Comunicación
• Mantener al ayuntamiento de Adeje como referente en el ámbito de las Web de Administraciones Públicas Locales.
• Aumentar los niveles de acceso a la Sociedad de la Información de la vida socioeconómica municipal a través de la organización de eventos TIC de alto nivel en el que puedan participar y compartir conocimientos las empresas del municipio.

Se puede consultar el programa, conocer más a los ponentes, inscribirte (inscripción gratuita) en la web del evento. También puedes seguirlo por twitter y por Facebook.

Allí estaremos, bien atentos y prestos a tomar buena nota de todo, que el programa promete.

Tags: adejetec, administración pública, google, jornadas, maps

Cuando decidí terminar mi antiguo blog, quise también sacarlo de los buscadores, no quería que quedasen diseminados miles de resultados en los buscadores que llevaban a un blog cerrado, y que habré movido de ubicación en breve.

El primer paso es sacarlo del todopoderoso Google. Ya hay quien dice que si no estás en google no existes, así que, como precisamente esa era mi intención, dejar de existir para el público, hacia ahí dirigí mis pasos.

Básicamente hay dos acciones a realizar. Una, evitar que los buscadores sigan indexando, y otra, intentar que olviden todo lo que ya han indexado.

La primera acción se consigue con el fichero robots.txt, un fichero que colocado en el directorio raiz de la web, indica a las arañas de los buscadores cómo deben corportarse con nuestro sitio. Así, pues, el primer paso es colocar el fichero con el siguiente contenido:

User-agent: *
Disallow: /

Con esto ya hemos conseguido que los buscadores (todos, como se indica en el User-agent: *) ya no indexen nada de nuestro dominio (deshabilitamos todo a partir de la raiz, es decir, todo el sitio).

El siguiente paso, es eliminar el contenido indexado. Empezamos por google, por ser el más utilizado hoy en día.

Necesitamos tener cuenta en Google y nuestro sitio verificado. Para ello, accedemos a nuestra cuenta y desde ahí vamos a las Herramientas para Webmasters o Webmaster tools. Añadimos nuestro sitio, en caso de no tenerlo aún y lo verificaremos.

Para verificar que el sitio es nuestro, Google nos indicará como proceder, pudiendo elegir entre modificar la cabecera de nuestra página índice añadiendo un campo meta, o bien, subiendo o creando un fichero con un nombre específico.

Hecho este paso, le diremos a google que prosiga con la verificación, con lo que ya habremos demostrar a Google que el sitio es nuestro.

Para no hacerlo eterno, y dada la facilidad con la que se hace, solo nos queda hacer click sobre nuestro dominio y a continuación elegir las Herramientas y dentro de estas, la Eliminación de URL, donde haremos una nueva solicitud de eliminación, pudiendo elegir qué eliminar (el sitio entero, un directorio, páginas o imagenes específicas).

Hecha la solicitud, quedará pendiente hasta que en la siguiente indexación, Google eliminará todo el contenido solicitado de su índice.

Yahoo.

La filosofía es la misma. En este caso accedemos a Yahoo! Site Explorer, donde realizaremos idénticos pasos que los descritos en el caso de Google para verificar nuestro sitio. Una vez verificado, podemos explorar el índice que tiene Yahoo! de nustro sitio, y en los resultados de la exploración junto a los enlaces a nuestro sitio, aparecerá un botón (al pasar el ratón sobre cada fila) que nos permitirá borrar una URL y/o path. Ahí haremos la solicitud, que al igual que en el caso de Google, quedará programada. Comentar que no es necesario borrar uno por uno todos nuestros enlaces. Se pueden utilizar rutas y así se borra todo lo contenido en esa ruta.

Microsoft Live Search.

Hasta el momento, desconozco la forma de salir de este buscador. Parece ser que se puede realizar algún tipo de solicitud al respecto, mediante correo electrónico y un formulario de solicitud genérico de incidencias. No me preocupa sobremanera, puesto que el sitio en cuestión lo cambiaré de ubicación y estará protegido de las arañas de los buscadores. En cualquier caso, un punto negativo para el buscador de Microsoft.

Archive.org

El último sitio del que quería eliminarlo es de archive.org, o “la máquina para viajar atrás en el tiempo”, como se definen. Este sitio mantiene un historial de nuestra web a lo largo del tiempo, pudiendo consultar, por ejemplo, como era el diseño del sitio hace cuatro años. Para sacar nuestro sitio de este particular indexador, basta con el fichero robots.txt descrito antes. La próxima vez que archive.org indexe nuestro sitio, acatará el contenido de dicho fichero y bloqueará nuestro contenido.

Y así, hemos logrado limpiar un poco internet. Seguramente sean muy raros los casos en que alguien quiere hacer desaparecer por completo su sitio, pero seguro que es mucho más común el interés por eliminar una ruta en particular, un fichero, o alguna imagen determinada, y para eso, también nos sirven estas herramientas.

Tags: buscadores, google, internet, msn, yahoo

Comentaba el otro día con Sergio en Plurk sobre algunos de los problemas que presenta el greylisting del que hablaba el otro día.

Es cierto que, aunque las ventajas del greylisting superan, a mi parecer, las desventajas, puede no ser el caso para todos, pudiéndose convertir en algún momento en un problema inaceptable.

Esta técnica adolece principalmente de una molestia y de un problema.

La molestia del greylisting.

Los correos se demoran.

Puede darse la circunstancia de que esto no sea aceptable. Es cierto que es una molestia, cuando, por ejemplo, nos registramos en algún sitio y tenemos que esperar el tiempo de embargo para que nos llegue el correo de registro. Esos minutos se hacen eternos, haciendo dudar al receptor de si ha puesto correctamente su dirección de correo. No es raro el caso en que el usuario insiste en registrarse una y otra vez en ese servicio, probando incluso con direcciones distintas. Lógicamente, si las direcciones de correo radican en servidores que utilicen greylisting, no conseguirá nada más que recibir un aluvión de correos de registro una vez pasado el tiempo de embargo.

Esto es lo que yo denomino una molestia, y que para algunos, ciertamente, puede alcanzar el grado de problema. A veces es necesaria la inmediatez en el correo. La solución: paciencia. No hay más.

El problema del greylisting: distintos servidores de correo.

Aquí si que existe un problema se mire por donde se mire. Recordando el funcionamiento del greylisting, este se basaba en guardar una terna (<dirección IP del emisor>,<correo electrónico del emisor>,<correo electrónico del receptor>). Esta terna se almacenaba, y se devolvía un error al servidor emisor, quien reintentaría el envío más tarde.

El problema surge cuando el emisor no es un servidor único, sino es parte de una granja de servidores, donde el correo no tiene por que ser enviado siempre desde la misma dirección IP. Este es el caso de Gmail, por ejemplo, que dispone de una cantidad ingente de servidores de correo, y es muy común que el primer intento de correo y sus posteriores reintentos no provengan de la misma dirección, por lo que la terna nunca será la misma y el correo no se aceptará.

Perder un correo válido no es aceptable. Cualquier lucha contra el spam debe basarse en esta máxima.

Para paliar este problema, se utilizan las listas blancas, con rangos de direcciones IPs conocidas. De esta forma, le podemos indicar a nuestro sistema de greylisting que si el emisor proviene de una de las direcciones IP contenidas en nuestras listas blancas, se acepte el envío (siempre y cuando supere el resto de pruebas que realicemos a los mensajes entrantes, lógicamente).

Algunos sistemas de greylisting son capaces incluso de aprender e ir alimentando el fichero de listas blancas, detectando las granjas de servidores.

RedIRIS provee dos listas muy interesantes para añadir a nuestra solución de greylisting: La lista ESWL y la lista MTAWL. En la lista ESWL figuran las IPs de los servidores de correo salientes gestionados por ISPs españoles miembros del Foro ABUSES. La lista MTAWL es una lista de IPs de servidores de correo propuestos y validados por los miembros del Foro ABUSES de servidores de correo cuyo tráfico consideran no debe ser bloqueado (Hotmail, Gmail, Yahoo, bancos, agencias de viaje, etc).

La técnica del greylisting normalmente se acompaña de otras, como el RBL, SPF, DomainKeys, etc. Se pueden combinar estas técnicas con el greylisting, de forma que no sean comprobaciones independientes sino que se complementen. De esta forma, por ejemplo, podemos relajar las condiciones de la comprobación SPF, y en vez de denegar el acceso a quien no lo cumpla, y a quien lo cumpla dejarlo pasar para realizarle luego el greylisting, podríamos cambiar el test de SPF para que sea más permisivo y asi ayudar al greylisting. En este ejemplo, haríamos que quien pase el SPF sea aceptado automáticamente por nuestra solución de greylisting, haciendo que solo caiga en ella quien falle la prueba del SPF. Podemos meter en la ecuación también la comprobación de DomainKeys.

Lo que está claro es que hay un mundo de posibilidades (y de trabajo) para luchar contra el SPAM, que no es solo la molestia de un correo no deseado en nuestro buzón, sino que también es causa, como ya he comentado alguna que otra vez, de gastos importantes de recursos, y que lamentablemente no existe una solución de enchufar-y-listo válida para todas las situaciones.

Tags: correo, greylistin, spam

Leo en Appleismo sobre la aparición de un troyano para Mac OS X, oculto bajo un juego de poker.

El funcionamiento del troyano parece ser que consiste en, con la excusa de una corrupción en un fichero de preferencias, solicitar la contraseña de administrador parar poder reparar el fichero y aprovechar esa escalada de privilegios para, en su lugar, enviar el hash de las contraseñas a un determinado servidor.

En principio, podríamos pensar, que bueno, visto que pide la contraseña de administrador, nadie va a caer en el engaño, porque ¿quien va a dar la contraseña de administrador?. Lamentablemente, mucha gente. Y es normal, porque ante la costumbre de los sistemas operativos de preguntar continuamente por la contraseña de administrador, aparece la costumbre del usuario de dar permiso de forma casi automática. Los usuarios de Windows Vista, sufridores de este mal en un nivel superior (por la frecuencia con que lo pregunta Windows Vista) saben lo que es (¿cuantos no han desactivado ya el UAC?).

Pero este troyano, que no debería de preocuparnos más allá de un simple ataque que dependen de la interacción del usuario, nos hace pensar sobre otra vulnerabilidad mucho más grave que aun no ha sido resuelta.

Hace unos días se hablaba de Root Exploit in Apple Remote Desktop, que permite que cualquier usuario o aplicación pudiese ejecutar comandos como root sin ningún tipo de autorización.

Sumando ambos casos, es facil ver el resultado de la ecuación: cualquier programa malintencionado puede obtener los datos que consigue el troyano sin necesidad de solicitar autorización.

Esto es un problema grave. Muy grave. Cualquier programa puede, sin ningún tipo de problemas, tomar el control completo de nuestro Mac, obtener los datos que quiera, y si así lo quiere, destruir su contenido sin ningún impedimento.

La solución pasa, como siempre, por no descargar y ejecutar programas de fuentes no fiables (¡vaya novedad!). Mala solución, cierto, pero es la que nos queda.

Y aunque no tenga que ver directamente, no pierdo la oportunidad de aprovechar para recomendar la instalación de Little Snitch, un indispensable en seguridad en nuestros macs.

Este era el precio a pagar que ya auguraban por el aumento de la cuota de mercado de los Macs.

Habrá que irse haciendo a la idea de que los antivirus van a empezar a tocar el timbre de Mac OS X con insistencia.

Tags: apple, Mac OS X, seguridad

Emulando a Fray Luis de León, como decíamos ayer, continuemos hablando de SPAM. O mejor dicho, de la lucha contra él.

Existen múltiples sistemas de comprobar el grado de validez de un correo en el momento de su entrada en el servidor destino, que es cuando queremos pararlo. Recordemos, cuanto antes lo paremos mejor: menos tráfico consumido, menos recursos consumidos y antes le decimos al spammer que no nos la ha colado.

Entre las comprobaciones básicas, podemos encontrar las listas negras (listas dinámicas de direcciones IP conocidas de spammers. Si el emisor está en una de estas listas, terminamos la conexión), fallo en la validez del protocolo SMTP (obligamos a seguir estrictamente todos los protocolos, incluyendo el de identificarse correctamente el servidor emisor), comprobación de que el emisor existe (el servidor receptor hace una nueva conexión hacia el servidor de correo del emisor, para comprobar que el remitente es una dirección válida).

Tras esta primera batería de comprobaciones, vendría la aceptación del correo en si. Otra medida que se puede utilizar es ir analizando el correo a medida que va entrando, y desde que se tenga la certeza de que es spam, un virus, o incumpla alguna de las normas, terminar la conexión en ese momento, rechazando el correo y dejándolo a medias.

Dependiendo de la agresividad de los filtros, los correos no se dejarán entrar o se aceptarán todos y se marcarán como SPAM para que el usuario final los revise. No aceptarlos tiene el peligro de perder correos válidos, y aceptarlos todos tiene el peligro de que cara a los spammers nuestra dirección de correo es buena y acepta el SPAM, por lo que no saldremos nunca de esas listas.

Estos métodos necesitan cada vez de un mayor consumo de recursos, al ir adaptándose los spammers para saltárselos, lo que obliga a mejorar las medidas de detección, haciéndolas más complejas y por tanto necesitando más tiempo de cómputo.

Es aquí donde surgen una serie de medidas interesantes y de alto impacto. Son tres de las que voy a hablar: Greylisting, SPF y DomainKeys.

GreyListing.

Hoy por hoy, es mi medida preferida. Tiene una eficacia increíble para la sencillez de la idea. Es cierto que tiene alguna contrapartida, pero los resultados son tan impresionantes que creo que merecen la pena.

Su funcionamiento se basa en quedarse a medio camino entre las listas blancas (white lists), listas de emisores y/o receptores válidos y confiables, y las listas negras (black lists), listas de emisores y/o receptores denegados.

Las listas blancas se utilizan para saltarse las comprobaciones de correo de ciertos remitentes que sabemos que son seguros, o para algunos receptores que no quieren que su correo pase por ningún filtro. Las listas negras, imagino que a estas alturas ya se sabe para que son.

A medio camino, las listas grises. El funcionamiento consiste en denegar inicialmente cualquier intento de entrega de correo, informando al emisor de que en ese instante no podemos aceptar su correo y que vuelva a intentarlo más tarde (código de error 451 de SMTP).

Antes de rechazar el correo, el receptor ha tomado nota y apunta la siguiente tripleta: <Dirección IP del emisor, dirección de correo del emisor, dirección de correo del receptor>. Esta tripleta se “embarga” durante un tiempo definido por el receptor.

Si el emisor del correo es un servidor de correo que cumple con los estándares, volverá a intentar la conexión pasado un tiempo. Si aun no se ha cumplido el tiempo de embargo, el servidor receptor volverá a informar del mismo error, indicando que aun no puede recibir el correo.

El emisor volverá a intentarlo más tarde, y eventualmente llegará el momento en que en su intento ya haya pasado el tiempo de embargo, por lo que el receptor aceptará el correo sin más problema.

Por el lado del receptor, una vez aceptado el correo, se almacena la tripleta y se mantendrá válida durante un tiempo definido por el servidor, por ejemplo un mes. Cualquier correo posterior que coincida con la misma tripleta, se aceptará directamente, sin demora, y además, pondrá a cero el contador de esa tripleta, dándole de nuevo otro mes de validez.

La gran pega de este método es que el primer correo desde un emisor, tardará en entrar. Al menos tanto como tengamos definido como tiempo de embargo, que puede variar desde 5 minutos hasta varias horas.

Y aquí surge la pregunta ¿Y en qué ayuda esto en la lucha contra el SPAM?. La mayoría del SPAM se genera desde equipos zombies, o mediante programas encargados de lanzar miles de correos a listas de destinatarios, pero que no son servidores de correo completos, o que no respetan todos los requisitos del protocolo SMTP. También se puede deber al hecho de que el coste, para estos emisores de spam, de reintentar enviar un correo con las direcciones que fallan es demasiado alto (errores de destinatario no válido, buzón lleno, servidor no puede tramitar la solicitud en este momento, correo rechazado por ser spam…).

El hecho es que estos emisores masivos no vuelven a intentar enviar una vez recibido el error inicial, con lo que los hemos descartado sin siquiera tener que recibir un solo bit del correo ni haber gastado un ciclo de CPU en analizarlo.

Para mi se ha convertido en uno de los mejores sistemas por que me ha demostrado ser capaz de evitar el 95% del SPAM. Y eso supone muchos cientos de miles de correos semanales (si, no me he equivocado en el número). Después de todo, la mayoría de nuestro correspondencia la hacemos con los mismos interlocutores, por lo que estos siempre estarán marcados como válidos. Los nuevos interlocutores, los que no conocemos aun de nada, son de los que desconocemos sus intenciones, y por eso nos tomamos un tiempo en aceptar su correo.

Además, es de los sistemas de detección y protección que marcan las direcciones de correo de los destinatarios como no válidas para los spammers, por lo que (y esto es otro dato que he comprobado con el tiempo) acaban saliendo de algunas de estas listas, reduciendo el volumen de spam que se les intenta enviar. Doble beneficio a cambio de la demora de un correo.

Uno solo.

Merece la pena.

Soy un fan declarado del greylisting y de la belleza de su sencillez y eficacia.

Y aunque a Juanjo no le guste, el post se me ha alargado demasiado, por lo que seguiré hablando de los otros métodos de los que quería hablar (SPF y DomainKeys) en otra entrada.

Permanezcan atentos a la pantalla.

Tags: greylisting, spam

Arte SPAM. CC Yandle

El SPAM, el maldito SPAM, generador de tanta basura y de altísimos costes económicos, es una de las plagas actuales de internet. Es una lucha continua la que se libra entre los ISPs y los spammers, unos intentando frenar por todos los medios a los otros y estos intentando saltarse las protecciones impuestas por los primeros.

Por supuesto, hablo del SPAM en el correo electrónico.

El volumen actual de SPAM es ingente. En algun servidor con poco tráfico recibíamos hace dos años alrededor de 50.000 (intentos de) mensajes semanales de los cuales un 1% podía ser correo válido. Los números y los métodos han cambiado mucho, pero la imagen global puede seguir siendo válida.

Todo este análisis de mensajes y conexiones requiere ancho de banda y tiempo de CPU. Y mucho.

Es por esto, que la lucha actual se dirige, sobre todo, al origen del mensaje: cuanto antes tratemos el mensaje, menos consumiremos. Si somos capaces de detectar al spammer desde que intenta la conexión, antes siquiera de que nos empiece a dejar el mensaje, habremos ganado ancho de banda, tiempo de CPU y le habremos dado el claro mensaje de que aquí no le queremos.

La antigua solución, la de “tragarse” el mensaje entero para luego analizarlo, va cayendo en desuso, por el evidente consumo de medios, y por el hecho de que al spammer le hemos dado a entender que aceptamos el mensaje, quedando “marcados” como receptores para posteriores envíos.

Por otro lado, hay que hilar muy fino en qué mensajes marcamos como SPAM y cuales no aceptamos en nuestros servidores. Los falsos positivos pueden ser inaceptables. En ocasiones, el destinatario prefiere tragarse todo el SPAM a sufrir la posibilidad de perder un solo correo válido.

No es mi caso. La experiencia me ha demostrado que cuando un correo no llega, el problema suele estar en el emisor, que o bien no cumple los estándares, o bien ha caído en listas negras o incluso su ISP les ha filtrado el tráfico saliente para evitar que envíen correo al haber sido emisores de SPAM anteriormente (normalmente sin saber que tienen un zombie en casa). Telefónica de España es uno de los ISPs de los que tengo constancia que están bloqueando el correo saliente a los spammers.

No creo que la solución para recibir correo de alguien que no cumple las normas sea saltárnoslas nosotros, bajando las defensas. Lo lógico es que corrija la situación el infractor. Después de todo, no puede pretender que todos sus destinatarios le abran las puertas cuando llega tocando de malas maneras.

Para no seguir alargando la entrada, demoraré para otro(s) post(s) la explicación de algunas de las medidas en uso hoy en día. Permanezcan atentos a la pantalla.

Tags: correo, spam

Mi primer portatil, un Asus, tenía en la BIOS una funcionalidad que no encontré posteriormente en otros portatiles y que se demostró muy util.

Con el uso y las continuas cargas y descargas, las baterías de los portátiles van perdiendo capacidad, y el sistema va mermando en su fiabilidad en la medición de cuanta carga nos queda o cuanto tiempo va a permanecer encendido.

Aquella utilidad en el Asus, se limitaba a forzar a cargar el portatil a plena carga, para luego, una vez cargado, pedirte que lo desenchufaras, para proceder a poner al máximo ventiladores y procesador para consumir la batería hasta agotarla por completo. De esta forma, el portátil era capaz de volver a medir los niveles máximos y mínimos de carga de la batería.

Esto no aumenta la capacidad de carga de la batería, pero si hace que la medida sea más correcta. Sin estas calibraciones, es fácil encontrarse con equipos que de repente se apagan cuando la batería aun indicaba un 40% o un 50% de carga. O que al ponerla a cargar, al poco tiempo nos informa de que ya está llena.

Calibrando la batería sabremos de forma más fiable cuanto tiempo nos queda de uso. Y según Apple, incluso mejorará la vida de la batería. Este proceso se puede hacer en los macbook y macbook pro siguiendo estos pasos:

• 1.- Conectar el macbook o el macbook pro a la corriente y dejarlo cargando hasta que la luz del MagSafe se ponga verde y que el icono en la barra de menú indique que la batería está completamente cargada.
• 2.- Permitir que la batería se mantenga completamente cargada durante un período mínimo de dos horas. Puedes seguir utilizando el ordenador siempre y cuando lo mantengas conectado a la corriente, para no tirar de la batería.
• 3.- Desconectar de la corriente (quitar el MagSafe) con el ordenador encendido y empezar a utilizar con la batería. Cuando la carga de la batería esté baja, saldrá un aviso de carga baja en la pantalla.
• 4.- Continuar utilizando el ordenador hasta agotar la batería. El ordenador se suspenderá. Recuerda grabar tu trabajo y cerrar todas las aplicaciones cuando la batería esté baja y antes de que el ordenador se suspenda.
• 5.- Apagar el ordenador o dejarlo suspendido durante 5 horas como mínimo.
• 6.- Volver a conectar a la corriente y cargar la batería por completo. Se puede utilizar el ordenador mientras tanto.

Apple recomienda realizar este proceso más o menos cada dos meses, aunque si le das un uso esporádico al macbook o macbook pro, recomiendan hacerlo una vez al mes. Con este proceso la batería se utilizará al máximo de su rendimiento.

Si tienes baterías extra, hay que hacer el proceso también con ellas.

Y repito, este proceso no hará que las baterías duren más, pero si que se aprovechen al máximo durante su vida útil.

La imagen corresponde a una captura de coconutBattery, una utilidad gratuita que te permitirá saber cual es la carga máxima que soporta actualmente tu batería, cual es la carga actual, el número de ciclos de carga que ha tenido y la capacidad original. Es muy buen indicador de la vida de tu batería.

Tags: apple, baterias, macbook, macbook pro