Mejores prácticas para recibir correos electrónicos en rieles

Question

He estado tratando de encontrar la mejor manera de manejar el correo electrónico entrante en las aplicaciones de rieles. Me doy cuenta de que las "mejores prácticas" son bastante subjetivas, así que comenzaré afirmando que mis principales preocupaciones son la escalabilidad y la eficiencia. Este es un problema principalmente porque mi uso implicará el manejo de archivos adjuntos potencialmente grandes.

Parece que ayer el método aceptado fue utilizar ActionMailer para recibir el correo electrónico, pero recientemente me encontré con varios artículos diciendo que esto es ineficiente ya que genera una nueva instancia de rieles con cada correo electrónico (horrible en grandes volúmenes).

Más recientemente, este artículo ha sido conseguir mi atención: http://jasonseifer.com/2009/04/24/receving-email-with-rails

Los post habla de una versión reducida del sistema ActionMailer que no está obligado a generar toda una instancia rieles, pero los comentarios hablan de varias otras opciones como un directorio de correo dedicado (maildir?) y la recuperación imap/pop.

Mi pregunta es: ¿Alguien tiene alguna idea sobre cuál sería la mejor opción para procesar el correo electrónico entrante en una aplicación de rieles (incluidos los archivos adjuntos)?

Answer 1

Mantengo el Fetcher plugin para descargar el correo electrónico de un servidor IMAP que uso con cron. Solía ​​usar un daemon pero era difícil seguir corriendo (incluso con monit) porque Ruby se bloqueaba. Cron está bien para mi carga de trabajo, pero genera un proceso de Rails una vez por minuto.

Para procesar archivos adjuntos, consulte la biblioteca MMS2R. Tiene una interfaz agradable para obtener los archivos de un correo electrónico.

El otro enfoque que me han recomendado es disparar una publicación HTTP para cada mensaje recibido. Luego puede escalar su nivel web para manejarlo.

Conector Shameless: es posible que desee comprobar Mike Mondragon y mi PeepCode book on receiving email with Ruby.

Answer 2

en mms2r el MMS2R#default_media simplemente devuelve el archivo adjunto de video más grande si existe, o el archivo adjunto de imagen más grande si existe, o el archivo adjunto de texto más grande, si existe, en ese orden. MMS2R#default_text devuelve el archivo adjunto texto/plano más grande si existe. También puede acceder a cualquiera de los archivos adjuntos directamente a través del hash de medios de mms2r, p. Medios MMS2R #. MMS2R#media está codificado por mimetype, ese valor al que hace referencia la clave es una matriz de medios de ese tipo. Por lo tanto, si hubiera dos archivos adjuntos jpeg en un correo electrónico procesado por MMS2R, accedería a ellos como una matriz al teclear el hash de medios con image/jpeg, p. Ej. MMS2R#media['image/jpeg']

Cuando MMS2R procesa primero un correo electrónico, cualquier archivo adjunto que encuentre se decodificará y almacenará en una matriz de medios de ese tipo. Como dije, esa matriz está codificada por mimetype en el hash MMS2R#media.

Comprar el libro, tengo que pagar mi hipoteca PeepCode book on receiving email with Ruby.

Answer 3

Usted podría tratar de usar un servicio como http://cloudmailin.com/

Answer 4

Hace poco escribí un demonio que recibe el correo de Postfix usando LMTP (utiliza EventMachine y es bastante rápido y robusto) y lo guarda en MongoDB. En ese sentido, elimina al intermediario (servidor IMAP + cliente IMAP). Ese enfoque da una escalabilidad y redundancia bastante ilimitada. El soporte de otros backends (MySQL, Redis, etc.) se puede agregar en prácticamente ningún momento.

received

Answer 5

Para la retransmisión de correo de Postfix para su aplicación Rails a través de HTTP, que acabo de escribir un artículo sobre cómo lo estamos haciendo.

En realidad es bastante simple, pero también estamos aprovechando la capacidad de Postfix de diferir el correo electrónico si no se puede retransmitir. No he visto eso en otro lado hasta el momento. Vea http://www.doorkeeperhq.com/developer/smtp-to-web-api para más detalles.