Re: [mailop] Anyone else seeing increase in iCloud rejections?
They’re prompter than that usually. You should get a reply soon. --srs From: mailop on behalf of Jarland Donnell via mailop Sent: Sunday, May 1, 2022 4:28:25 AM To: mailop@mailop.org Subject: Re: [mailop] Anyone else seeing increase in iCloud rejections? Of course. Could be days before I hear back so I'd like to be able to report in the meantime if this is specific to us. Blocking a whole ESP is emergency level, but I can't even reroute these to deliver out of network. On 2022-04-30 17:53, Suresh Ramasubramanian wrote: > I hope you followed that url and emailed, asking why this block > occurred? > > --srs > - > > From: mailop on behalf of Jarland Donnell > via mailop > Sent: Sunday, May 1, 2022 3:40:44 AM > To: mailop@mailop.org > Subject: [mailop] Anyone else seeing increase in iCloud rejections? > > Even changing IP space, all emails our customers send to iCloud are > currently returning: > > 454 5.7.1 [CS01] Message rejected due to local policy. Please visit > https://support.apple.com/en-us/HT204137 > > Is anyone else seeing an increase in this? I'm trying to figure out if > > this is a failure at iCloud or if they've content blocked one of our > headers. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] forwarding to gmail - problem
On 2022-04-29 at 10:28 -0700, Brandon Long wrote: > There have been other reports on this list of Gmail requiring > authenticated email. > > We don't require authenticated email... but we vastly prefer it, and > that preference has only increased over time. And the dkim replay > attacks have meant increasing the scrutiny of messages which are dkim > authn but not spf authn, which of course can hurt forwarding. > Forwarding is getting the short end of the stick in that > toss up. > > The above rejection isn't for the dkim replay case, of course, it's > for no authn at all. Yep. I completely understand it's not authenticated. The problem is, it's out of our reach to authenticate that third party email. It's the recipient who wants to receive it. > SRS style rewriting allows the forwarder to get feedback if the > forwarding destination address goes away, > and do bounce handling... > and prevent bounces from going back to the original sender, exposing > the destination address. There are good reasons to do the rewrite, > but not as likely for the average procmail user, and having a good > spam filter that doesn't forward is very important. We do some hoops here, in that we provide the original envelope to the forwarded mail server, but it if refuses to accept it, we send the bounce to the forwarding account, not to the original sender. :) This not only avoids leaking the information about forwarded accounts, but also confusing the senders. >> Gmail guidelines explicitly ask not to rewrite the envelope sender > > Yes... and gmail forwarding does ;). Mailing lists do as well. Should we then do as-it-does rather than as-it-says? :) If gmail has changed its stance, messages could be forwarded with a different envelope sender, but I suspect it wouldn't be happy either, as it would then show an envelope suspiciously unrelated to the content. > > > There's no great solution to this problem. (...) ARC is the > > > theoretical solution to this, where it can forward auth > > > information, but how to handle the forwarded auth information is > > > still a work in progress. > > > > There is a really simple solution for these Gmail customers getting > > their forwarded mail rejected. But it lies on Gmail side. > > > > Gmail already knows that the account of bl...@gmail.com is linked to > > the mailbox bl...@example.com, since bl...@gmail.com is configured to > > allow sending as bl...@example.com. It should thus detect that the > > email received from mta.example.com with a "To: bl...@example.com" is a > > forward requested by the user, and not reject it at the gateway when it > > fails SPF. > > Heuristics like this have been used in the past, but spammers often > figured them out. I was initially going to suggest that it was received by any server passing SPF for the configured external account, then noticed that perhaps that didn't work so well with those large SPF records, and mentioned just that To: (just an example, it could e.g. be detected through headers as well) but it really should have mentioned "from the right server". > > Or, in order to have a stronger command from the user and avoid > > forward-guessing, at the cost of a new configuration setting, let the > > user configure a list of IP addresses from which they are forwarding > > mail to their account. > > Then Gmail could clearly recognise what is actually happening: that the > > connecting IP adddress belongs to a border MTA of this user, and then > > walk Received: headers to fetch the actual IP address that delivered it > > to bl...@example.com, which is the one that should be taken into account > > for a proper evaluation. > > Yes, this is how workspace handles this, you would just set the list of IPs > as > the inbound gateway. Even then, there are cases like outlook.com/O365, where > the list of possible IPs is very high... or forwarding gmail to gmail, for > that matter.. Allowing users to set this as well would allow users to fix this issue where gmail would otherwise reject the mail they want forwarded. At least for those coming from a small set of ip addresses (although large ones probably use a forwarding pool). > An even better one would be ARC, it would be pretty easy to specify > one or more ARC ADMDs as trusted forwarders on a per-user basis (or > for workspace admins). > > This suffered from a chicken/egg problem on top of the general > "hard for most users to understand", and the general small usage of > regular forwarding... > the better option was to generalize the benefits of ARC to all users > automatically... but that work is still in progress. ARC would indeed be a more complete solution. However, I suspect this may be one of those cases where perfect is the enemy of the good. Specially since this doesn't solve the issue of which ADMDs to trust. I agree about the general problem of "hard for most users to understand" how to fill out ip addresses or ADMD identifiers, but given the issue that
Re: [mailop] Anyone else seeing increase in iCloud rejections?
I hope you followed that url and emailed, asking why this block occurred? --srs From: mailop on behalf of Jarland Donnell via mailop Sent: Sunday, May 1, 2022 3:40:44 AM To: mailop@mailop.org Subject: [mailop] Anyone else seeing increase in iCloud rejections? Even changing IP space, all emails our customers send to iCloud are currently returning: 454 5.7.1 [CS01] Message rejected due to local policy. Please visit https://support.apple.com/en-us/HT204137 Is anyone else seeing an increase in this? I'm trying to figure out if this is a failure at iCloud or if they've content blocked one of our headers. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
Heho, Yes; The benefit of this is also that you do not need your target to have any service you can subscribe on running; They just have to follow a proper mail setup. But I like you suggestion. Would be any of the larger ESPs who is doing sender reputation by IP up for a test? .oO( I would like to do this in coordination, as I'd use some of my own IPs for this, and would prefer not to permanently burn the whole network... ) With best regards, Tobias -Original Message- From: mailop On Behalf Of Ángel via mailop Sent: Saturday, 30 April 2022 20:47 To: mailop@mailop.org Subject: Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation That's an interesting attack. I initially thought you were going to describe placing a victim as your destination target which is something which is prevented by requiring the receiver to authorize them: https://www.rfc-editor.org/rfc/rfc7489.html#section-7.1 But this is getting a spamtrap to accept emails and treating them as intruding attempts. The onus should be on them to detect that they are the MX of the target domain, and thus the sender may be playing by the rules. Quite easy to notice if you start seeing in DMARC reports in your spamtrap, actually. But this doesn't mean that all spamtrap operators do that, or wouldn't be vulnerable to that. Note that you could perform a similar attack by subscribing a user to a number of mailing lists, promotions, etc. then changing your MX to a spamtrap, which would then blame the sender IP. Regards ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else seeing increase in iCloud rejections?
Of course. Could be days before I hear back so I'd like to be able to report in the meantime if this is specific to us. Blocking a whole ESP is emergency level, but I can't even reroute these to deliver out of network. On 2022-04-30 17:53, Suresh Ramasubramanian wrote: I hope you followed that url and emailed, asking why this block occurred? --srs - From: mailop on behalf of Jarland Donnell via mailop Sent: Sunday, May 1, 2022 3:40:44 AM To: mailop@mailop.org Subject: [mailop] Anyone else seeing increase in iCloud rejections? Even changing IP space, all emails our customers send to iCloud are currently returning: 454 5.7.1 [CS01] Message rejected due to local policy. Please visit https://support.apple.com/en-us/HT204137 Is anyone else seeing an increase in this? I'm trying to figure out if this is a failure at iCloud or if they've content blocked one of our headers. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Anyone else seeing increase in iCloud rejections?
Even changing IP space, all emails our customers send to iCloud are currently returning: 454 5.7.1 [CS01] Message rejected due to local policy. Please visit https://support.apple.com/en-us/HT204137 Is anyone else seeing an increase in this? I'm trying to figure out if this is a failure at iCloud or if they've content blocked one of our headers. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
That's an interesting attack. I initially thought you were going to describe placing a victim as your destination target which is something which is prevented by requiring the receiver to authorize them: https://www.rfc-editor.org/rfc/rfc7489.html#section-7.1 But this is getting a spamtrap to accept emails and treating them as intruding attempts. The onus should be on them to detect that they are the MX of the target domain, and thus the sender may be playing by the rules. Quite easy to notice if you start seeing in DMARC reports in your spamtrap, actually. But this doesn't mean that all spamtrap operators do that, or wouldn't be vulnerable to that. Note that you could perform a similar attack by subscribing a user to a number of mailing lists, promotions, etc. then changing your MX to a spamtrap, which would then blame the sender IP. Regards ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
