> > There are people who *don't* useTurbomailin their applications? are you > > sure? > > Can I quote you on that? ;^)
Of course :) > > Off the top of my head: > > *snip* > > and another 3 I know of in various stages of release. > > Are these all you have worked on? I see nothing about the underlying > technologies on any of them, even the one that has a blog. :) Yep, all of them run Turbogears off a base setup I've evolved since 2005. I don't tend to talk about the tech I use much. > > Quite frankly, I'm marginally astonished nobody has considered simply > > integratingTurboMailinto TG itself. > > Amusingly, I'm working fairly hard on making TurboMail TurboGears- > independent. Not every application requires mail, and some may even > do it by hand. My original understanding of TurboGears was minimal > glue holding together best-of-breed components, which is why I'm > making it more of a generalized component, useful for -all- Python > applications. That may be the case, however in my experience just about every web app requires mail sending support - certainly as many as, say, need mochikit or RSS feed support. Regardless of how you choose to package it, I think Turbogears needs a mail component installed with the base installation. But that's just my opinion, it doesn't actually make a difference to me personally :) > > 1. Error handling, how to consistently detect when a send failed, and why > > The 3.0 branch has a debugging, single-threaded manager which will > pass along exceptions so you can test. That's cool, but not the entire solution. Even in production when everything is fine, there are situations when an email does not get delivered, and in some circumstances it would be good to be able to identify the fact that it could not be delivered to enable alternative contact methods. I understand that SMTP limits this somewhat in that once it's in the local mail server you can't get anything back, but knowing that the local mailserver is unavailable, or that it rejected the mail for some reason (such as failing a spam filter test, or attempting to deliver to an address that could not be verified) would be helpful. Not a priority, as I said these are minor issues. On the whole, it works nicely. > > 2. What configuration is necessary to prevent your email from being > > immediately spam-binned by gmail regardless of content. > > Could you open a ticket with more information? That's -very- > strange. Likely if someone is using TurboMail (which adds a TurboMail > version header) to spam in large quantities, Gmail may use that as a > trigger for its filters. >_< Ouch. Nah, I think there's just a number of basic things you need to be sure of. Certain headers, ensuring the source email address exists, checking to make sure you don't have SPF set for the wrong domain etc. Regards, Richard. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
