Hi Mark,
absolutely. We have a hard limit of 300 e-mails per day for 99% of our
users. Even if an account gets compromised - and it does happen daily
- the damage is extremely limited. We do have reports and logs
analysis and automated action is taken against what we perceive to be
abused accounts.
Nevertheless, I find it counterproductive to not help ESPs locate
abusers in order to actually solve the problem under the guise of
maintaining secrecy, when in fact, they are asking us to locate the
spamtrap address in our logs - lol!
I don't kow how all RBLs work, but this one in particular says: "Just
grep the logs (last 7 days) on those Level 1 listed servers for
undeliverable outgoing mails at the time displayed. Since our
rejection texts are very unique it shouldn't be a big deal to figure
out who or what caused the problem and you shoould be able to take
preventative measures not to get listed again in the future."
So basically instead of saying: here, look for e-mails sent to
sdfdfgfgdg...@myrbl.com , they say: grep your logs and find a hard
bounce around with a distinctive message - and therefore I also find
their 'secret' spamtrap. Foolproof logic.
Scott
On Wednesday, 18/12/2024 at 18:59 L. Mark Stone via mailop wrote:
Scott,
I don't think anyone here, (especially if, like us, they are operating
an ESP smaller than those large ESPs whose IPs cannot be blocked) does
not sympathize with your situation.
But "find[ing] out who the abusers were" I consider our responsibility
as ESPs. Sure, some help, if available from the DNSBL doing the
blocking is appreciated, but if we can't figure who on our system is
sending what to whom and why something sent might be problematic,
that's a problem -- and I think that's what the replies you've
received here have been trying to tell you.
We host Zimbra, and while I'm not here advocating to use Zimbra (to
each their own), Zimbra's Daily Mail Report is incredibly useful for
helping us sort out when a customer is, let's say, "pushing the
envelope". That Daily Mail Report enables us to take action before the
customer's domain and/or our IPs have gotten block listed.
Put differently, in my experience, each platform has native and/or
third-party tools available to help you meet your responsibility to
"find out who the abusers were."
Hope that helps,
Mark
--
_________________________________________________________________
L. Mark Stone, Founder
North America's Leading Zimbra VAR/BSP/Training Partner
For Companies With Mission-Critical Email Needs
----- Original Message -----
| From: "Scott Q. via mailop"
| To: "Michael Peddemors" , "mailop"
| Sent: Wednesday, December 18, 2024 6:24:06 PM
| Subject: Re: [mailop] DNSBL List
| I simply wanted a way to find out who the abusers were so I can
solve the
| problem. I didn't want a removal, automatic or not.
| Not co-operating with ESPs about who the offenders are doesn't
really help
| solve anything. It's completely counter-productive.
| So basically, the logic here is the following: RBL operators won't
tell me what
| the spamtrap is because they want to keep it secret. Yet, they
expect me to
| parse thousands of lines of logs, go through who knows how many hard
bounces
| and eventually STILL FIND the spamtrap address. How does this make
any sort of
| sense ?
| Scott
| On Wednesday, 18/12/2024 at 16:53 Michael Peddemors via mailop
wrote:
|| IF you can't adequately monitor your own outbound mail queues, and
track
|| rejections, and want someone else to do your job for you, you might
like
|| to offer the RBL operators some money to do your job for you.
|| *Sheesh*
|| Eg, Twilio is a billion dollar company, and can't get a handle on
those
|| phishers abusing their systems..
|| Most RBL's do it voluntarily, or make a lot less money.. They don't
|| really have the time to tell you which accounts are being bad.. If
you
|| believe in what they do, then contribute..
|| Amazing how many ESP's simply say 'remove me' or create bots to
send
|| removal requests from RBL's.. and expect sympathy..
|| If you are worried about getting listed on Blacklists, do a better
job
|| of monitoring traffic, rather than trying to squeeze in every
suspicious
|| client, for the bottom line..
|| ITs not that hard..
|| You can tell a bit aggravated when I hear ESP's expecting other
people
|| to help them keep off blacklists for nothing..
|| And trying to compare an ESP to Gmail or o365 isn't realistic.. As
bad
|| as those two companies are for letting spam out..
|| Grr.. back to work..
|| Thanks Atro and Anne for your comments, now can we put this to bed?
|| On 2024-12-18 13:26, Scott Q. via mailop wrote:
|| > But why is it bad if legitimate hosting providers know which of
their
|| > accounts is abused so they can take action and fix the problem ?
|| > I understand you don't want spammers to know what spamtraps you
use, but
|| > surely it would be beneficial for everyone if there is a trust
circle
|| > that can easily solve problems. A feedback loop basically.
|| > Scott
|| > On Wednesday, 18/12/2024 at 07:48 Atro Tossavainen via mailop
wrote:
|| > ("List only" replies appreciated here)
|| > > ok, granted, but how else do you suppose would be a better
method
|| > > ? Can you imagine them asking Gmail to look at their logs at
around
|| > > +/- 1 minute ? We're not Gmail level but we still have lots of
data,
|| > > it's a silly way to convey information.
|| > I don't have a better way to suggest. I'm just pointing out that
|| > identifying spamtraps explicitly enables listwashing, so spamtrap
|| > operators are trying to do whatever they can to avoid it - while
|| > nonetheless trying to provide at least some useful information,
|| > in some cases.
|| > It is likely that any spamming account sent any number of similar
|| > messages around the timeframe indicated.
|| > Any entity rejecting the messages that another party tries to
send
|| > owes just about nothing to the would-be sender. At least you get
the
|| > information of WHO is responsible for the rejection here; in the
case
|| > of Cisco Talos Intelligence, the error messages don't even tell
you
|| > that you have a problem with Talos, they refer to unspecific
reputation
|| > issues where you don't even know where to start looking :-D
|| > --
|| > Atro Tossavainen, Founder, Partner
|| > Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
|| > Tallinn, Estonia
||> tel. +372-5883-4269, [ https://www.koliloks.eu/ |
https://www.koliloks.eu ] < [
|| > https://www.koliloks.eu/ | https://www.koliloks.eu ] >/
|| > _______________________________________________
|| > mailop mailing list
||> [ mailto:mailop@mailop.org | mailop@mailop.org ] < [
mailto:mailop@mailop.org |
|| > mailop@mailop.org ] >
||> [ https://list.mailop.org/listinfo/mailop |
|| > https://list.mailop.org/listinfo/mailop ]
||> < [ https://list.mailop.org/listinfo/mailop |
|| > https://list.mailop.org/listinfo/mailop ] >
|| > _______________________________________________
|| > mailop mailing list
|| > [ mailto:mailop@mailop.org | mailop@mailop.org ]
||> [ https://list.mailop.org/listinfo/mailop |
|| > https://list.mailop.org/listinfo/mailop ]
|| --
|| "Catch the Magic of Linux..."
||
------------------------------------------------------------------------
|| Michael Peddemors, President/CEO LinuxMagic Inc.
|| Visit us at [ http://www.linuxmagic.com/ |
http://www.linuxmagic.com ]
|| @linuxmagic
|| A Wizard IT Company - For More Info [ http://www.wizard.ca/ |
|| http://www.wizard.ca ]
|| "LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
||
------------------------------------------------------------------------
|| 604-682-0300 Beautiful British Columbia, Canada
|| _______________________________________________
|| mailop mailing list
|| [ mailto:mailop@mailop.org | mailop@mailop.org ]
|| [ https://list.mailop.org/listinfo/mailop |
|| 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
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
