John Leslie wrote:
Michelle Sullivan <miche...@sorbs.net> wrote:
...
On Tue, Jan 3, 2017 at 8:13 PM, Bryan Vest <murli...@gmail.com
<mailto:murli...@gmail.com>> wrote:
If someone from SORBS could contact me off list or on list I don't
care, either way we need to get this block removed.
...
(restoring from Bryan's post)
]
] We have been blocked for 48 hours by SORBS for an email that was in no way
] spam. It did not look like spam and was sent to a small group of email
] addresses. The ip address in question only has this one entry in their
] system and of course no replies to request for answer as to why we have to
] wait 48 hours even though this was not spam nor as to what triggered it as
] spam.
I do not know the address involved. I doubt the legitimacy of the
assertion, and without the IP cannot confirm or indicate otherwise.
Mistakes are rare now, but they do occasionally happen.
There are players in the market who believe they are too big to block
...
... lets instead attempt to be constructive and have a calm discussion...
A discussion is IMHO _very_ apprpriate -- largely because the IP
blocklist model is hopelessly doomed _when_ IPv6 email becomes common.
Agreed
what would *YOU* suggest we do instead, and what do *YOU* perceive as
"not interested in solving problems"
Obviously, that's in the eye of the beholder...
Which was sort of my point, particularly as many people come back with
stuff that has been tried and tested to not work and/or is
small/specialised list thinking not big public DNSbl thinking... It's
not as easy as some would make out.
But let me opine that one truly interested in "solving problems"
would find a way to make information on what triggered the listing
widely available to "trustworthy" parties, and would find a way to
let "trustworthy" parties report resolution of the problem.
Acutally have that already - been implemented since 2005, public since
2011, and actively been promoted since 2013... the problem is only in
one word though ... "trustworthy" ...
(I actually wrote an I-D on that subject a number of years ago.)
Fundamentally, we have to agree that an _actual_ spammer cannot
be considered a "trustworthy" party. Thus, blocklist operators are,
to a first approximation, unlikely to publish to the whole world
what it is that led to any particular listing. :^(
Well that depends... *I* always went down the path of indicating as much
as possible what caused a listing... hence why the SORBS list is a
myriad of lists that can be confusing because of the number... others
(including "the only reputable one") choose to just give a list of
possible reasons and never the actual data or even a small part of it.
But the fact remains that many "spam runs" originate from mostly
honest customers whose computer has been compromised. This will only
be cured when the owner has been notified, and has come to believe
it's worth the effort to remove the compromise.
Which is why we make delisting 48 hours from the last spam instance
caught by default... if it's important this should be enough time for
someone to notice.
How to get that information back to the responsible party, as of
today, remains unsolved. But to the casual observer, blocklist
operators don't seem to be trying at all. They don't notify the
blocklisted server at all, in most cases, and if there _is_ any way
to retrieve information about why the listing happened, it's
proprietary.
SORBS does not fall into this category completely...
If a company/ISP is registered with us for NetManager, and have chosen
to receive reports, they get emails upon listing and by default they
will have access to additional (but heavily munged) information that any
good sysadmin should be able to use to cross-reference in their logs and
locate the problem. (eg standard postfix logging of emails will provide
enough cross reference to locate the originator of the listing... it
won't show all the reasons if there are mulitple sources only the first
that caused the listing in the 24 hour period from the 'current'
detection (ie once listed we stop recording data for 24 hours, if spam
continues after 24 hours, we capture the first/triggering data and then
ignore the rest for another 24 hours).... in the case of spam.)
Listings cause by proxy, relay etc will indicate why by definition (open
port and IP recorded, and the type of proxy, just not the open-relay
method that is identifiable outside the tester.) The 'hacked' zone is a
little more ambiguous, but we give as much information as possible to
identify the cause. Virus listings we give the actual virus detected.
and what do *YOU* perceive as "punishment"...
Actually, any blocklisting without the least attempt to report
why the listing happened _looks_like_ "punishment" -- even when the
"punishment" is extremely unlikely to change the misbehavior.
Define 'report' - if you have registered with us we will tell you, if
you have not we won't spam addresses in an attempt to tell you as this
is/can be as bad as the actual spam.
and I will answer why we can/cannot implement such policies/changes...
Why you _currently_ can't implement them isn't terribly helpful.
Actually it is. I'm not saying I can't implement them, I'm saying I
will explain why such policy can't be used in practice (if
appropriate... eg home user type policies for a worldwide market leader
etc..)
Instead, could you try to say what you would need in order to
implement them?
If the reason I can't implement something is technical and nothing more
I will happily share.
Regards,
Michelle
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
