|
Author: H.AnS (17 May 15 12:26pm)
Yes, this is bound to happen sooner or later. And it results in mis-directed bounces and other autoresponders to the spoofed senders ( = PHP-created mail addresses).
See https://www.spamcop.net/fom-serve/cache/329.html for details.
It could be reasonably argued that mis-directed bounces, out-of-office messages, etc. are as bad as the original spam, but they don't fit the profile that PHP is looking for.
I wonder whether PHP is prepared to filter out and ignore the backscatter, which might come from the likes of Google and other reputable mailers. (Yes, gmail.com has recently sent me mis-directed bounces -- it's really disappointing that Google is not smart enough to handle this properly!) Treating backscatter as spam and blacklisting honest but not-so-smart bouncers/auto-responders would not help PHP's cause.
Not only would it not help, but it could actually be a PHP vulnerability that lets the spammers purposely undermine PHP's effectiveness. It's a non-trivial issue for PHP to solve, and just relying on frequencies will not be sufficient in the long run.
@R.Gupta7:
It would probably be fair to set the subdomain's SPF record to reject all mail coming from the donated subdomain, so that the innocent recipients can easily automate rejecting the spam, and to discourage the spoofing. This might even be necessary to avoid exposing you to litigation if PHP's actions result in problems for innocent third parties, and if it's not part of PHP's current instructions, it should probably be added.
Have you tried to set the subdomain's DMARC record to NOT produce any reports? It might be fun to see these for a while, but ultimately I wouldn't want them to mess up my real DMARC stats.
(I have honeypots running on several domains and am considering donating MX subdomains, but I haven't done so yet.)
|
