111–119 of 119 posts
Earlier quoted context omitted.
Running a mail server is simple, even for programmers. Running a mail server with reliable outbound delivery, and inbound spam filtering, is anything but simple.
A reliable mail stack is configuring postfix+dovecot or cyrus, adding dspam, opendmarc, opendkim and a bunch of dns records. How is this any harder than anything else in computing?
Earlier quoted context omitted.
Hi Chris, > This issue should be limited to new applications where the trust signal might be a bit lower. Thus existing apps / customers shouldn’t be experiencing issues. 1. My app is not new. It's been running without issue for 2 or 3 years. 2. My app is not on the free tier. 3. On average, my app sends out under 8 emails a day, and it's done the same for over 2 years. How your algorithm considers my app a spam risk…
Hi, if you haven't already sent Chris an email, can you send me the details of your account and I'll get answers for you today? lilkim@google.com
I sent him an email 14 hours ago and haven't received a response. I'll wait a day and if I still don't hear from him, will contact you.
Earlier quoted context omitted.
> I agree with you that some measure of notification that there's spam filtering would be good, but it's Google we're talking about. There's spam filtering. Nonsense! I had no idea this was a feature of GAE. I pay for the use of GAE, and so long as I send less than my quota of emails, it's not Google's business what the content of those emails are. There's no reason that there should be silent spam filtering on outgo…
Nope, I don't think there's an outgoing spam filter. My guess is that individual messages are only stopped when they enter a gmail account; if there's an abuse filter for email senders, it's probably on the whole account after a manual complaint process. The point: G is accepting cash from one group of people to send a ton of messages (mostly unwanted by addressees) and earning ad dollars from another group to stop u…
That's been tested for and eliminated. My app logs that an email has created and is going to be sent. The send_email function is called to send the email. Then my app logs that the email has been sent.
The emails are sent to addresses hosted at both gmail and outlook. They are not received. They do not appear in spam bins.
GAE has a bounce api that will log if an email is bounced back. In my case, no reports are logged by my bounce handler.
The content of my emails has not changed for 2 years. For 2 years both gmail and outlook received my emails in their inboxes (not spam bins).
Given all this, I'm pretty sure there is an outgoing spam filter.
Earlier quoted context omitted.
> I agree with you that some measure of notification that there's spam filtering would be good, but it's Google we're talking about. There's spam filtering. Nonsense! I had no idea this was a feature of GAE. I pay for the use of GAE, and so long as I send less than my quota of emails, it's not Google's business what the content of those emails are. There's no reason that there should be silent spam filtering on outgo…
> it's not Google's business what the content of those emails are You are very wrong about this. Senders of email need to make sure they aren't being used for spam or they get blacklisted.
But then they should have notified me: "We suspect you're using the service in violation of our TOS, so you are suspended" or something like that.
I'm paying for a service, they continued to take my money while pretending to provide that service.
Hey Folks, The issue reported here is linked to App Engine and Gmail tightening up their spam filters. The root cause was an increase in organizations sharding out their spam systems to utilize App Engine’s free tier in such a way that is (a) in direct violation of our ToS and (b) making all of our lives suck a bit more (raise your hand if you want spam). It’s unfortunate that while App Engine is trying to provide a…
Chris, you say Gmail tightened up their spam filters... Did this take place in the last ~6 weeks or so? I've noticed the spam filter on Gmail for Google Apps has gotten significantly less accurate recently, resulting in far more false-positives than usual. Any ideas if this is a known issue? I can only presume it's more accurate overall, but it was definitely a noticeable change for our organisation.
Earlier quoted context omitted.
A reliable mail stack is configuring postfix+dovecot or cyrus, adding dspam, opendmarc, opendkim and a bunch of dns records. How is this any harder than anything else in computing?
DKIM + SPF + DMARC does not guarantee reliable delivery. Not even close.
At work, we handle pretty large traffic for mail, with self-hosted mail servers as well - those are exim. No delivery issues either, although these are only the real, important, not even remotely spam-like, core business messages. Spam-like newsletters are done via sendgrid there.
Earlier quoted context omitted.
They should be working on a migration tool for users of AppEngine to migrate to Google Container Engine.
We wouldn't use it. To me, the whole point of Appengine is to abstract out system administration. GCE (like AWS) abstracts out the systems, but not the administration - you suddenly become responsible for all the scaling, fault-tolerance, and all the subsystems that Appengine manages for you.
My request is for a tool which would provide this functionality in the form of code which exposes an App Engine like interface to the developer, except it's running in Container Engine. Given Container Engine has the required code to restart processes that fail and oodles of other automated goodies, this give the fault tolerance desired.
> We wouldn't use it.
Given the "tool" doesn't appear to exist IRL, that statement is illogical. You can't not use something that doesn't exist. And, if there really did exist a migration tool that provided additional operational abstraction inside the framework you were migrating to, you'd run the risk of being in conflict if you didn't consider using it.
Earlier quoted context omitted.
I can't comment on the paid support. I've just noticed that the non-paid support engineers seems to be under pressure. I feel little bit bad for them sometimes. They don't seem to have the time to look into problems. It must be quite a boring job for those assigned on the public issues. Maybe their higher-ups aren't aware of that.
Hi, I manage the team. Do you have some recent examples I can show to the higher-ups? Our incentives are built around quality of work, not speed, so what you're describing is definitely not working as intended.
Form my perspective: sometimes when I report a bug it's more so that other users don't waste their time troubleshooting it than to have it fixed immediately.
Maybe sometimes I'm not 100% clear but it is a bit discouraging to have to send follow-up messages on clear-cut issues like these: https://code.google.com/p/googleappengine/issues/detail?id=1... https://code.google.com/p/googleappengine/issues/detail?id=1... (the comment #10 of the former issue was written a bit too quickly don't you think?)
Then there are issues that "work as intended" but that seem like bad product design: https://code.google.com/p/googleappengine/issues/detail?id=1...
Do they really reach a product manager?
Finally there are issues like these ones that are not clear cut but that I can't investigate myself because it requires time and resources (they eventually cost me a few bucks running instances for testing purposes). https://code.google.com/p/googleappengine/issues/detail?id=1...
You guys have a good product. I think that the promise of not having to manage infrastructure hit a cord with many people. However you do have many bugs to fix to make the platform more stable and (non intentionally) discouraging people from reporting issues will make things improve at a slower rate.
Good luck!
Earlier quoted context omitted.
Yes, Mandrill should have kept the free quota after DKIM and SPF verification. Now, I will be trying out the competitors (Sendgrid and Mailgun) and if I find them at par with Mandrill then for paid projects, I might use them rather than Mandrill.
For our clients, the appeal of Mandrill is the Mailchimp Template Editor. I think this is where their focus is going and so if you don't need that, then definitely check out competitors.
Anyways, it's up to Mandrill to choose who they want to serve. I really liked the service though. Best of Luck.