Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
On Thu 05/May/2022 12:55:53 +0200 Bernardo Reino via mailop wrote: On Thu, 5 May 2022, Alessandro Vesely via mailop wrote: On Fri 29/Apr/2022 18:24:04 +0200 Bernardo Reino wrote: On Fri, 29 Apr 2022, Tobias Fiebig via mailop wrote: This might be a bit of a theoretical attack thing, but looking over the bounces for my nightly outbound DMARC reports I actually started to wonder about this; (Mostly because I am getting scared by regularly sending DMARC reports to non -existing accounts on a major ESP ;-)).>>> It's scary, and your scenario looks very real. I regularly get bounces from Google due to DMARC reports being sent to non-existant addresses handled by Google. Sorry to be late... Note that example.com should set rua=mailto:dm...@example.com; that is, they should receive reports at their own domain. If they setup a recipient to an external domain, the latter must acknowledge that setting. I don't know if that is a requirement. But I have cases like e.g. with @discourse.org, where the rua is dmarc-repo...@discourse.org, so that would be "OK" as per your comment above. However, the MX for that domain is aspmx.l.google.com et al. which is what causes the/a problem. Yes, that causes some problems. My last event was this very morning, with: : host aspmx.l.google.com[108.177.14.27] said: 550-5.7.1 [65.108.69.105 12] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. y32-20020a2ebba000b0024f06a6a250si945257lje.307 - gsmtp (in reply to end of DATA command) so that is Google rejecting the DMARC report that discourse.org ASKED FOR, because it considers it to be "unsolicited". I only received two of those bounces, on March 10. None in 2020, none in 2021. I used to receive these: 8 450-4.2.1 The user you are trying to contact is receiving mail at a rate that 450-4.2.1 prevents additional messages from being delivered. Please resend your 450-4.2.1 message at a later time. If the user is able to receive mail at that 450-4.2.1 time, your message will be delivered. For more information, please 450-4.2.1 visit 450 4.2.1 https://support.google.com/mail/?p=ReceivingRate - gsmtp They used to come every day until about the end of January. Then slowed down. That's because I send reports just around midnight (and I know that I'm doing alright;-). Google limit of one message per second[*] can trigger for DMARC reporting. [*] https://support.google.com/a/answer/1366776?hl=en&ref_topic=28609 (OK, I originally mentioned non existent addresses, but being rejected as a spammer is even worse than that, in my book). I've even considered stopping sending DMARC reports entirely, as one could argue that they don't serve any positive purpose for the reporter, and may even have a negative impact, as you have described. There /are/ a couple of positive effects for reporters. One, for small senders, is to contribute scraping out a minimal footprint. If that "minimal footprint" ends with meaning "Google thinks I send unsolicited e-mails during the night to addresses that may or may not exist" then I'd rather live without that footprint ;-) I currently have 14 (manually added) domains in my "no DMARC reporting list". When I reach 20 I'll just stop reporting altogether ¯\_(ツ)_/¯ Why? I do that for abuse reporting. I have 384 addresses in my nosend list, manually added since 2020. Grepping through those is still faster than retrieving one, methinks. Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
On Thu, 5 May 2022, Alessandro Vesely via mailop wrote: On Fri 29/Apr/2022 18:24:04 +0200 Bernardo Reino wrote: On Fri, 29 Apr 2022, Tobias Fiebig via mailop wrote: This might be a bit of a theoretical attack thing, but looking over the bounces for my nightly outbound DMARC reports I actually started to wonder about this; (Mostly because I am getting scared by regularly sending DMARC reports to non -existing accounts on a major ESP ;-)). It's scary, and your scenario looks very real. I regularly get bounces from Google due to DMARC reports being sent to non-existant addresses handled by Google. Sorry to be late... Note that example.com should set rua=mailto:dm...@example.com; that is, they should receive reports at their own domain. If they setup a recipient to an external domain, the latter must acknowledge that setting. I don't know if that is a requirement. But I have cases like e.g. with @discourse.org, where the rua is dmarc-repo...@discourse.org, so that would be "OK" as per your comment above. However, the MX for that domain is aspmx.l.google.com et al. which is what causes the/a problem. My last event was this very morning, with: : host aspmx.l.google.com[108.177.14.27] said: 550-5.7.1 [65.108.69.105 12] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. y32-20020a2ebba000b0024f06a6a250si945257lje.307 - gsmtp (in reply to end of DATA command) so that is Google rejecting the DMARC report that discourse.org ASKED FOR, because it considers it to be "unsolicited". (OK, I originally mentioned non existent addresses, but being rejected as a spammer is even worse than that, in my book). I've even considered stopping sending DMARC reports entirely, as one could argue that they don't serve any positive purpose for the reporter, and may even have a negative impact, as you have described. There /are/ a couple of positive effects for reporters. One, for small senders, is to contribute scraping out a minimal footprint. If that "minimal footprint" ends with meaning "Google thinks I send unsolicited e-mails during the night to addresses that may or may not exist" then I'd rather live without that footprint ;-) I currently have 14 (manually added) domains in my "no DMARC reporting list". When I reach 20 I'll just stop reporting altogether ¯\_(ツ)_/¯ Cheers, Bernardo PS: I notice this is derailing off the original topic, which was the nice DMARC reflection attack.___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
On Fri 29/Apr/2022 18:24:04 +0200 Bernardo Reino wrote: On Fri, 29 Apr 2022, Tobias Fiebig via mailop wrote: This might be a bit of a theoretical attack thing, but looking over the bounces for my nightly outbound DMARC reports I actually started to wonder about this; (Mostly because I am getting scared by regularly sending DMARC reports to non -existing accounts on a major ESP ;-)). It's scary, and your scenario looks very real. I regularly get bounces from Google due to DMARC reports being sent to non-existant addresses handled by Google. Sorry to be late... Note that example.com should set rua=mailto:dm...@example.com; that is, they should receive reports at their own domain. If they setup a recipient to an external domain, the latter must acknowledge that setting. For example, googlemail.com addresses to an external, albeit similar, domain: ~$ dig +short _dmarc.googlemail.com txt "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-repo...@google.com"; That ought to be acknowledged by google.com: ~$ dig +short googlemail.com._report._dmarc.google.com txt "v=DMARC1" Check that before sending! I've even considered stopping sending DMARC reports entirely, as one could argue that they don't serve any positive purpose for the reporter, and may even have a negative impact, as you have described. There /are/ a couple of positive effects for reporters. One, for small senders, is to contribute scraping out a minimal footprint. As for non-existing accounts, recall that the acknowledge record —almost empty in the above example— can override the rua= tag in order to direct to a working mailbox. So, if it bounces, it is entirely their own fault, and they should be smart enough not to blame third parties. Best Ale -- ___ 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] 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
Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
On Fri, 29 Apr 2022, Tobias Fiebig via mailop wrote: Heho, This might be a bit of a theoretical attack thing, but looking over the bounces for my nightly outbound DMARC reports I actually started to wonder about this; (Mostly because I am getting scared by regularly sending DMARC reports to non -existing accounts on a major ESP ;-)). It's scary, and your scenario looks very real. I regularly get bounces from Google due to DMARC reports being sent to non-existant addresses handled by Google. I've even considered stopping sending DMARC reports entirely, as one could argue that they don't serve any positive purpose for the reporter, and may even have a negative impact, as you have described. In an ideal world, people setting DMARC records would make sure the addresses exist and work, but hey, who am I to give advice :) Cheers. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
Heho, This might be a bit of a theoretical attack thing, but looking over the bounces for my nightly outbound DMARC reports I actually started to wonder about this; (Mostly because I am getting scared by regularly sending DMARC reports to non -existing accounts on a major ESP ;-)). Maybe I am overlooking/overthinking something here, but it would be nice to hear what others think about it, and whether they think that this is actually a problem needing a solution. Assumptions: - Many major ESPs track a sending mailer's reputation; If a host tries to throw in a lot of mail for non-existing users/domains, reputation goes down. - There are spam-traps out there with pretty much the same goal; see what flies in and, e.g., populate RBLs Setup: - I create _a lot_ of subdomains - MX (I just set it; not sanctioned by the ESP) for the subdomains is either a large ESP or a spam-trap. - Create a -all SPF record and a DMARC p=reject entry and a rua=mailto:p@, as well as the _report._dmarc record for each of these sub-domains Execution: - I generate a lot of mails (one From: per subdomain) towards a target (ESP, small setup) that sends DMARC reports - The target rejects my mails (spf -all) and sends a DMARC report; Based on the MX this goes to the ESP/spam-trap. - The spam-trap/ESP get a lot of 'unknown recipient/domain' mails from my target; They don't accept them, but take note for the senders' reputation. -> Sender reputation of the target goes down With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
