I'm wondering what is the quickest and most reliable way to forward mail from an IMAP account.
My university does not allow our student-mailbox to forward to a private e-mail account (everybody uses either Gmail or Hotmail here). It's a political thing, not technical. We do have IMAP access to the mailbox. I would like to have a service which downloads the mail through IMAP, and forwards. And it would be nice to scale it, so thousands of students can use it. Eventually, I want to build a public signup page, and have it processed automatically from there.
So far, I've made a decent PHP script which connects, downloads headers and body parts, and ties it all together. I have two problems with that.
1) I'm downloading all kind of parts, and sticking them back together. I hope that every exotic attached file, weird encoded piece of text and every type of header survives this. I'm not even sure I have the complete header.
2) The to: e-mail address becomes the private e-mail address, not the original student e-mail address. I think this is lame, and inconvenient in searching and archiving.
Is the PHP script the way to go? Is there a trick using a particular linux mail service/daemon? Does IMAP have a 'forward' command, I'm missing?
You might want to look at Fetchmail, as this sounds like the problem it was designed to solve. Fetchmail retrieves mail from POP/IMAP/etc servers and forwards it to SMTP/LMTP/etc servers. Fetchmail has the advantage of a few years and lots of users ironing out problems with various IMAP servers.
Fetchmail seems like the way to go. I can use PHP to generate/edit a fetchmail command file, so that will cover the public sign-up. I'm looking for a package/script who allready does this.
The Gmail pull only works with POP3, not with IMAP.
If using Gmail you can configure GMAIL to pick up mail from other accounts.
Related
I am developing a Django-based system. It is kind of client-tracking tool.
Some users can work with different client accounts.
I would like to track the emails among users and clients within the application.
The company uses MS Outlook Server as a mail server and users are sending emails from their workstations.
The goal is to have the list of emails to/from users/client on the web page.
I see some possible ways how to do this.
Make the email form on the web page and send all emails from this page. Thus we can store the email sent.
While sending the email - manually add a CC field with the address of robot who will have access to this mail thread and can fetch messages from the inbox sorting them by the sender/recipients.
Automatically fetch messages from user mailboxes (don't want to store their passwords though)
Probably use some mail filter on the mail server to forward messages from/to specified address (don't know how to do this)
But maybe someone can give some advices? Any ideas, guys?
I had done something similar a couple years ago (with Postfix, however, not with MS Exchange).
The best approach IMO is to setup a mailserver to blind-copy each email to your script. In Postfix this called a "custom transport". This way your clients will be able to send emails using any program, not necessary through a web form. AFAIK, nearly all production email archiving solutions work that way.
Sounds like you are looking for something like the journaling feature in microsoft exchange-server. It allows you to define a special mailbox that will recieve a copy of all mails. You can find more information about this here, here and here
Once all the messages are in one mailbox you can access it from your application.
I am coding HTML emails for our company press releases and wondering what is the best way to send a multipart HTML email? Some people say outsource it to a mailchimp.com or a campaign monitor. Other's seem to use PHP on their web server.
What is the best way to send HTML email templates?
Thanks
Depends on how much back end work you want to do. ESP's like Campaign Monitor and Mailchimp are the best option for less technically savvy people. They are also pretty much plug and play. Using other services such as transactional options like Sendgrid, Mandrill or Mailjet, are more API driven. They are designed to be triggered by a program, usually in response to a user action. PHPList is an open source program you can host yourself, so that is also an option.
I would avoid reinventing the wheel, there are a lot of bad things that can happen if you are not really careful. You need to know about CAN-SPAM, unsubscribe handling and deliverability for example. If you get any of that wrong you can trash your domain or IP's reputation and end up getting blacklisted.
For your simple press release example, the easiest option would be to stick with an ESP.
What are some common reasons, or example cases, in which storing the user's IP address in a model instance would be useful? I can't think of any off the top of my head.
Reading through Django's now-deprecated Comments framework, I see that they stored the commenter's IP address in a GenericIPAddressField within the Comment model. Why? What's the point of storing it?
Several uses come to mind:
Banning IP address of uncompliant users.
Associating tokens to IP address of user who've paid for some service
Manager interface of some network applications
(More general) Any network related application which interface is written in Django
Maybe some online game.
At the end of the day, IPAddressField is just another CharField with some restrictions, someone took the time to code it because he/she needed it and why not to include it in Django's Repertoire? :)
EDIT: I know all about circumventing this IP restrictions with proxies, etc, but, for less savvy users this might be effective, and for more savvy users this may be some pain in the... restrictions :)
In the case of the Comments app, or apps like it, it is often useful to know the IP address of commentators for spam or abuse reasons. You may also want to know if someone is pretending to be someone else by posting under different usernames but using the same IP address. Or if they post something abusive or illegal you can ban their IP address. It is sometimes used to detect spam. If you are running a forum that caters to a small group in one part of the world it may be surprising to receive comments from the opposite side of the world. They can also be gathered for statistics and logging purposes.
I'm using this field in one of my models, so let me share the use case here.
There is a web API which used to be freely available over the web. But now, we want to add authentication layer in it; without changing the way our end users have integrated it.
Adding new authentication parameters will require changes at our client's end, so that was not an option.
Finally IP based authentication seemed the most feasible solution. For that I need to store the IP address of the client and authenticate whenever the request comes from a registered list of IPs.
I am seeking advice from someone with experience integrating django and newsletters.
I need to send newsletters from my django app. I see that there are a couple of packages that already do this such as 'pennyblack' and 'emencia'. Does anyone have experience with these? Which of these is the most versatile and easy to use? My users want to add their own content to the news letters with topic, and article. News letters generally have 3 articles with a couple of photos. I also want the newsletter to print nicely as both html and pdf formats. Any working expamples I could toy with before I dive into the code?
Thanks!!
You can send html email messages directly from django with a few lines of python code, as in this snippet: http://www.djangofoo.com/250/sending-html-email. Or you can use an email sending module (I like django-messages - it allows for html and plaintext variants and gives you a message queue). Of course, that doesn't help you manage the newsletter, so you'd have to do that yourself and render an html template the same way you do with any webpage. I assume you've already checked google for newsletter-specific django modules with more features, but I don't know of any.
However, you probably don't want to send a newsletter yourself through django (more importantly, from your own production server). For one thing, if it's going to a lot of people, you don't want it to use all of your bandwidth and make your site sluggish while a huge queue of emails is sent. But more importantly, it's easy to get your server blacklisted by spam filters if you're not sending from a known, reputable domain (if you're paying for hosting it might be less of an issue, but you should check with your hosting provider).
IMO, your best bet is to use a stand-alone email newsletter service like MailChimp or Cheetah Mail. I've used and highly recommend MailChimp for a small to medium number of recipients, but I imagine there are a bunch of others that do that same thing. It makes organizing your message campaigns and recipient lists easy with hooks to do things like add a new user on your site to a recipient list. I'm sure you could also figure out a way to get your user-submitted content into the newsletter from django.
Hope that helps.
check this out. A better solution for you is django-newsletter
^mail\.(.*)?|(.*)?(web|\.)mail(.*)? is the exact regex I'm looking to scrutinize.
For example,
e3.mail.yahoo.com
webmail.example.com
hotmail.com
mail.aol.com
etc.
To be totally honest, its a fruitless effort, especially because even if you do manage to somehow do a re-write of all of the email domains that referred people to your site, there are 3 reasons it won't work:
You can't possibly account for all of the email domains out there.
If the email is hosted on HTTPS, and your pages are HTTP, you won't see a referrer anyways.
A very significant portion of the email using population uses non-web mail, like Outlook, Entourage, Mac Mail, iPhone Mail, Blackberry Mail, Android Gmail, to name a few, that never have a referrer.
Instead, if you're looking to segment the referrals of all of email referrals for tracking in Google Analytics, you should use utm variables in your URLs.
If you tag your URLs with utm_source and utm_medium, you'll be able to track them, regardless of the 3 restrictions listed above.
Traditionally, you'd set utm_medium to be email, and utm_source to be the mailing list name, and utm_campaign for the name of the specific campaign.
You can get assistance in building the URLs here: http://www.google.com/support/analytics/bin/answer.py?answer=55578
Even if links in email messages should be tagged with utm_xxx parameters, I like to clean and group my referral sources into clusters as much as possible. It is the way to go to understand effectively the sources of traffic that are missing proper tagging, and then prioritize and fix them.
The regex I use is the following, and honestly it works pretty well (it catches more than 95% of webmails that show up as referrals and can be split over dozens of subdomains like for yahoo or live, thus diluting their visibility as a source)
(messag|courrier|zimbra|imp|mail)(.*)\.(.*)\..{2,4}
You may update the subdomain names with values frequent in your area. The end catches any domain using a tld of 2-4 chars, and any domain.
I output the result as
Output To -> Constructor : Campaign Source : Webmail - $A3