Re: [mailop] Google bounce after accept
On Fri, Oct 30, 2020 at 8:25 AM Chris via mailop wrote: > On 2020-10-30 04:43, Hans-Martin Mosner via mailop wrote: > > > The mail server ingress needs to decide whether to accept a mail message > > based on criteria that are relatively fast to evaluate. DNSBL lookups, > > SPF-checks etc can be done fast. Part of this is applying heuristics do > > reject mails with apparently fake senders (that's where SPF can be > > useful, if you ignore the issue with forwarders). > > In order to keep up, whether a check is expensive or cheap, you still > have to be able to keep up, whether before or after acceptance. > > => which suggests that if you can afford to do it after acceptance, you > can do it before. > > I've built and run a number of largish scale filtering systems that did > arbitrary header scans, spamassassin, clamav, etc., all between the time > of DATA and ".", and issue rejects at the ".". > > No bounces. > Can you launch a virtual sandbox to open the attachment and detect malware during the smtp transaction? https://support.google.com/a/answer/7676854 (the answer is you can at p80, but you probably don't want to at p99) Some implementations do have more limitations at smtp time such as network connections that are harder to scale, and remote hosts are supposed to wait something like 30 minutes but they don't really like if you take 5 minutes to process the message either. Brandon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google bounce after accept
On Fri, 30 Oct 2020, 17:58 Brandon Long, wrote: > > On Fri, Oct 30, 2020 at 8:08 AM Chris Woods via mailop > wrote: > >> Tangentially, while not a bounce-after-accept, one user has been seeing >> this 5.7.1 NDR when emailing a contact's GSuite account. It does seem >> similar to an organisational bounce or incorrectly configured forward, >> frankly I'm not sure what to make of it. Typically you can't reach a >> Workspace support agent unless you're the admin user. >> >> : host aspmx.l.google.com[74.125.133.27] said: >> 550-5.7.1 Please be advised that your email account is not configured >> to >> send to 550 5.7.1 this email address, therefore your message has not >> been >> sent - gcdp a184si2242425wmh.22 - gsmtp (in reply to end of DATA >> command) >> > > The gcdp means it's a custom error message set by the admin > > GSuite does have the concept of a "walled garden" type of rules, usually > used with schools, such that student email accounts can't receive or send > mail outside of the school, but admin/teachers can. > https://support.google.com/a/answer/2640542 > > Brandon > Thanks for the confirmation! :-) I suspected it might be something like their account configured as internal mails only, this contact is an FMCG category buyer so I'm not very surprised. Does GSuite have a facility where an account will bounce emails from an external address until the user sends them an outbound email, or adds a contact to their address book? Cheers Chris ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Google bounce after accept
On 2020-10-30 08:25, Marcel Becker via mailop wrote: On Fri, Oct 30, 2020 at 1:11 AM Atro Tossavainen via mailop 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. E: Provision adequate resources to serve your customer base. F: Stop accepting new customers until adequate resources have been provisioned. 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). There are still edge-cases, especially when there are multiple RCPT-TO addresses with different configuration but the information needed to make the decision isn't available until after the DATA command, or when the messages are queued for delivery to a customer's server... But things could be better. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
