On Sat, Oct 31, 2020 at 8:13 PM Dave Warren via mailop <mailop@mailop.org> wrote:
> On 2020-10-30 08:25, Marcel Becker via mailop wrote: > > On Fri, Oct 30, 2020 at 1:11 AM Atro Tossavainen via mailop > > <mailop@mailop.org <mailto:mailop@mailop.org>> wrote: > > > > Why does Google bounce after accepting a message? At Google's scale, > > the potential to become the world's biggest spammer simply through > > backscatter is enormous. > > > > > > What do you prefer they do with that email if they determined it's > > malicious only after they accepted it? > > > > A: Dropping it: Folks will complain about them "behaving like Microsoft" > > > > B: Send it to the user (even spam folder): Users are not necessarily > > smart, they interact with phish mail in the spam folder; compromised > > accounts or worse > > > > C: Bounce it back: It's legally the right thing to do, it's the right > > thing to do to protect consumers. Senders get annoyed. > > > > I know what I'd do. > > The problem isn't annoying actual senders, the problem is annoying me > when I am not a sender or recipient, and instead am completely > uninvolved in the transaction. There are other options. > > > D: Process and return real-time accept/fail after DATA when possible. > When inadequate resources have been provisioned to keep up with load, > note the hash of the item (attachment, message, whatever) and temp-fail > it. If the hash is already on the list, send a temp-fail to the sender > but queue it for scanning. Eventually the decision will be made and > stored so that when the sender retries the message can be properly > accepted/rejected at SMTP time. > One issue we've seen is that a lot of servers wait 30 minutes for the first retry given it's specified as SHOULD in rfc 5321. Customers are not happy when messages are delayed that long. E: Provision adequate resources to serve your customer base. > > > F: Stop accepting new customers until adequate resources have been > provisioned. > It's not really a resources issue, though in the highly hostile world of the internet, no one would provision resources to cover every traffic spike... but those are easier anyways, you just temp fail... though, of course, temp failing just kicks the can down the road, if all of the traffic you temp fail keeps coming back and the other traffic doesn't go away, you'll just end up with even more traffic... but most of these are temp spikes. > G: Refuse to accept messages where the decision cannot be made > immediately if there isn't valid SPF/DKIM validation of the bounce > address. The rejection message can indicate that SPF/DKIM validation is > required for this type of message. Combine this with D (only temp-fail > if the sender cannot be validated, otherwise accept and queue). > I do like this one... but it's probably a no-go, unfortunately. Enterprise customers are kind of prickly about rejecting valid mail. It's a bit easier to impose that on consumers. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
