This is were I wish there was some standardization of bounce messages. If email server operators could receive reports of X number of bounces reliably it may cut down on the number of compromised accounts considerably, by scripting some sort of shutdown of the account.
At the current state it seems like Exim, Exchange, SmarterTools, sendmail, et al all have their own format which makes this error prone to say the least. SmarterTools is trying bounce.io to inform the end-client, but as I’m sure you are all aware that they will just delete and continue like it’s just more spam. > On Feb 13, 2015, at 7:36 PM, W Kern <[email protected]> wrote: > > >> On the other hand, when I've had actual compromised accounts that start >> spamming, AOL's SCOMPs have always been the first external report, so I >> actually find them quite useful. Only once did they notice a problem before >> I did (or my systems) found and plugged the hole, but still, it's nice to >> have the feedback. Other feedback loops seem far less useful to me, most >> sent more messages in the verification/signup phase than have sent actual >> ARF reports. Maybe I just don't send enough spam to get value out of the >> other FBLs out there? >> > > Yes, AOL SCOMPs are invaluable for that. Unfortunately, we have seen > situations where the SCOMP WAS our notification because rather than being > obvious and sending out spam/malware full blast, the spammer was being sly > and throttling the output to a couple a second, where it blended in with real > email. > > > > _______________________________________________ > mailop mailing list > [email protected] > http://chilli.nosignal.org/mailman/listinfo/mailop _______________________________________________ mailop mailing list [email protected] http://chilli.nosignal.org/mailman/listinfo/mailop
