On Mon 2016-Jun-13 09:06:59 -0700, Brandon Long <bl...@google.com> wrote:
On Fri, Jun 10, 2016 at 12:05 PM, Hugo Slabbert <hslabb...@stargate.ca>
wrote:
On Fri 2016-Jun-10 12:32:20 -0600, Tim Starr <timstar...@gmail.com> wrote:
No guarantee that we operate at the same scale (we're probably in the
ballpark), but we don't drop messages except when explicitly asked to by
senders/receivers (usually after they've managed to mailbomb themselves).
We either reject at SMTP time or we deliver to the user's mailbox (or where
ever their routing rules tell us to deliver to)... or we bounce. We try
to
keep bounces to a minimum, but that's not always possible. I don't think
it likely we would bounce for just spam, however, usually it's due to late
ACL checks for Groups or due to split admin specified policy decisions for
messages with more than one recipient. In some pretty extreme cases, we've
bounced after >30 days in the case of some irrecoverable internal bugs, but
our goal is deliver, reject or bounce, not to drop.
We do target a huge percentage of spam at SMTP time, and we have metrics to
try and keep the spam label delivery from getting too high, since no one
appreciates forcing users to look through a lot of spam or for us to have
to hold onto it (and delivery itself is fairly expensive).
Which isn't to say that handling this volume at SMTP time isn't
complicated, and perhaps we lucked out with our spam system to be able to
do that fairly easily... or we're just willing to take the resource hit to
do it. I can imagine a different spam system which had higher latency and
wasn't able to be short-circuited for a quicker verdict with ease.
OTOH, our SMTP time rejections have their own issues, false positives are a
lot more visible and harder to deal with (user's can't mark an smtp time
rejection as "not spam"). Most of the questions/complaints on mailop about
Gmail are due to our SMTP time rejections.
Brandon
Thanks Brandon; appreciate you chiming in.
IMHO that last sentence is probably a better problem to have. I know
personally that I would much prefer dealing with an SMTP reject with
associated logs on both ends rather than having a message disappear into
the Ether. Fail early; fail loudly :)
--
Hugo
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
