Re: [mailop] SORBS help

[Rob McEwen]

On 1/6/2017 8:49 PM, Noel Butler wrote:

 Reject HELO/EHLO 1.41%
 Reject unknown user  8.45%
 Reject sender address11.27%
 Reject unknown client host 48.03%
 Reject RBL8.31%
 Reject milter 22.54%


Noel,

Things like "Reject unknown user" are sort of a "given"... these are the 
"low hanging fruit" spams that are extremely easy to block and which are 
blocked BEFORE DNSBLs are implemented--that was sort of implied in my 
previous post. For you to include stuff like that... artificially bloats 
the denominator in your stats.


And then some of these other techniques work well in an ISP that, for 
example, has FEWER than 50K mailboxes WITH someone very sharp at the 
helm - but don't scale well and/or don't work as well if someone who is 
more average (or who is stretched very thin--forced to wear many hats!) 
is in charge of the spam filter and/or with much more mailboxes.


For example, many techniques for blocking spam that work OK for 20K 
mailboxes, can have an intolerable amount of FPs at 400K mailboxes. 
(greylisting without a significant amount of hands-on 
fine-tuning/whitelisting, is a good example)


And then there is this pesky fact - that the harder stuff to block - 
that would require the most resource-hogging content filters - are the 
spams that things like greylisting and "unknown user" - were not able to 
block. Overall, your non-RBL stats are (on average) biased towards the 
easier stuff.


Also, I've talked to people who run ISPs that have 30+ million mailboxes 
- and I can tell that they WOULD be brought to their knees if all 
sending IPv4 IP RBLs disappeared (and they are not alone). Yes, there 
are exceptions to that rule - such as smaller hosters who have put a lot 
more expertise and resources-per-user into their filters, which likely 
described your situation? But such anecdotal examples don't really 
impact my original assertion.


But I'm sure the world would be a better place if all mail systems were 
run by people with your skills AND where they deployed more 
resources-per-mailbox, as you're accustomed to seeing.


(I wish Yahoo would hire you - and would transfer Katie Couric's salary 
into your IT budget - that would be a good start!)


--
Rob McEwen


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Noel Butler]

On 07/01/2017 00:00, Vick Khera wrote:

> So if you're goal is to solve problems, then what's the point of having a 
> minimum 48 hour block when the problem is solved at the origin within 
> minutes? That's just punitive and not constructive.

Because in 99.9r% of the time, the problem is NOT solved "in minutes"
(nor hours). 

A malware infected windows pc can be a problem for days or weeks unless
an ISP suspends said client until they get their systems cleaned (About
10 years ago an ISP I worked for had policy of notifying customers and
as was typical back then, you gave them 48 hours to get the notice and
get their system offline and fixed, so they were capable of spewing out
trash for up to the next 48 hours - although if we considered it a mail
bombing type issue we would instantly filter all their outbound mail
ports). 

People go away, businesses shutdown over weekends etc, so you need time
for them to find out they have a problem and resolve it. 

-- 

Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Noel Butler]

On 07/01/2017 02:09, Rich Kulawiec wrote:

> It's always good to keep in mind that having your mail accepted somewhere
> is a privilege, not a right, and that recipient systems are free to
> cease extending that privilege in whole or in part at any time with or
> without notice and with or without reason.

I hate "+1's" on lists... but I gotta say it... 

+1 

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Noel Butler]

On 06/01/2017 14:14, Rob McEwen wrote:

> On 1/5/2017 8:21 PM, John Leslie wrote: 
> 
>> because the IP
>> blocklist model is hopelessly doomed _when_ IPv6 email becomes common
> 
> If every IPv4 blacklist provider (including spamhaus) closed down tomorrow, 
> and every internally-run IPv4 blacklist stopped working... and the world's 
> spam filters then had to rely on ALL... OTHER... means/technologies for 
> blocking spam, the majority of the world's mail servers would be brought down 
> to their knees--and there wouldn't be a quick fix.

That's not entirely true, given most ISP's carry out other "simpler"
enforcement checks before going near a DNSBL test. 
That's been the case everywhere I've been in the past 20 years plus,
DNSBL's account for only a minimal level these days, certainly nothing
that would bring any servers I know "to their knees". 10 years ago your
statement certainly would have rung a lot truer, where DNSBL's would
account for about one third or higher of rejects. 

These days a far different story, YMMV of course. This is from one
server, its typical of every server (RBL's are 4, including one internal
one), off 100% rejections we see and have seen over past 5 plus years. 

 Reject HELO/EHLO 1.41%
 Reject unknown user  8.45%
 Reject sender address11.27%
 Reject unknown client host 48.03%
 Reject RBL8.31%
 Reject milter 22.54%
Pretty much the only thing that goes in most postfix ACL's that I've
ever seen after a reject_rbl_* is a policy check, that being typically
for SPF. 

So sure, amavisd, mailscanner, or whatever other flavour you use will
have to work harder, but the only downside you'd likely risk is a bit
more spam in your inbox if you haven't refined your spam rulesets in
years.. 

-- 

Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sporadic delivery to icloud.com

[Jaren Angerbauer]

Responded off list.

--Jaren



On Fri, Jan 6, 2017 at 4:50 PM, Andrew Beverley 
wrote:

> Is there anyone here from icloud.com that can help with some rather
> sporadic delivery to user's mailboxes?
>
> Thanks,
>
> Andy
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Sporadic delivery to icloud.com

[Andrew Beverley]

Is there anyone here from icloud.com that can help with some rather
sporadic delivery to user's mailboxes?

Thanks,

Andy

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google blocked senders list

[Richard Gilbert]

> This seems like an odd place to raise this, but ok.

Thanks for replying, Brandon.

Does it make it a better place if I explain that I was writing as a
mail service operator?  When we migrated our in-house mail service to
Google our customer service people were keen that we should continue
to log all mail in and out of the University.  Because of local
address rewriting rules we needed to use an outbound gateway anyway,
but we also set up receiving routing so that all mail delivered to our
users' mailboxes was delivered to a local server for logging and then
discarding.

Twice a day we generate reports from the log files of big senders,
suspicious subjects, etc. which are sent to the customer service
people.  They add addresses to the domain wide blocked sender list if
they see fit.  But the only address they have to go on in the log
files is the envelope sender address -- they can't see the From:
address in the message headers.

(As the need for rewriting addresses has been eliminated, we plan to
turn off the outbound gateway but we will continue to log sent mail by
turning on sending routing.)

Richard

> Yes, the blocked sender could be applied to both, I'm not sure if/why it
> wasn't done that way.
>
> That said, I actually think if you're going to check one, then it's the
> RFC5322.From address which is the more logical choice.  It's also the more
> user visible choice.
>
> In many instances, messages are sent with VERP like RFC5321.From addresses,
> in the case of most mailing list software and commercial marketing mail, not
> to mention several forwarding systems.
>
> In the case of spam, I imagine that both the RFC5322.From and RFC5321.From
> are highly variable, we don't expect blocked senders to be used for the type
> of spam which mutates in an attempt to evade spam filters.  In general,
> playing whack-a-mole using filters or blocked senders for the worst type of
> spam is a fool's errand, you're much better off using the report spam
> feature and letting our systems handle it.
>
> As for the case where you only want to block the RFC5321.From and not the
> RFC5322.From, making the user have to choose which of the addresses to block
> seems poor, and blocking the RFC5321.From only seems unlikely to make sense
> to users either.
>
> Brandon
>
> On Wed, Jan 4, 2017 at 3:30 AM, Richard Gilbert 
> wrote:
>>
>> I have become aware that the Google blocked senders list is only
>> applied to the From: address, and that we cannot use it to block an
>> envelope sender address.  Is it just me who finds this surprising
>> (especially given its name)?  Why not check both?  It seems illogical
>> to accept a message from an envelope sender address which is in the
>> list.  Am I wrong in thinking that in the case of spam the From:
>> address is more variable than the envelope sender?  There will be
>> cases where we want to block an envelope sender address but unable to
>> block the (different) From: address because it is used by legitimate
>> mail.
>>
>> --
>> Richard Gilbert
>> Corporate Information and Computing Services
>> University of Sheffield, Sheffield, S10 2FN, UK
>> Phone: +44 114 222 3028
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>



-- 
Richard Gilbert
Corporate Information and Computing Services
University of Sheffield, Sheffield, S10 2FN, UK
Phone: +44 114 222 3028

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Michael Peddemors]

On 17-01-05 05:21 PM, John Leslie wrote:

   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.


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.


and I will answer why we can/cannot implement such policies/changes...

   Why you _currently_ can't implement them isn't terribly helpful.

   Instead, could you try to say what you would need in order to
implement them?

--
John Leslie 


Probably simply 'money', spammers make a lot more money that RBL 
operators, maybe when various CAN-SPAM organizations fine spammers, 
maybe they can spread the wealth to the RBL operators, and they can 
spend the money to become the 'reporting police'.. but seriously, it 
shouldn't be the job of RBL operators to let network operators know they 
have a problem, the network operators that do spend the money to monitor 
their own networks and email servers usually seldom end up on RBL lists, 
and/or can get off quickly in the case they missed something..


But asking small shops, often who are providing the service for little 
or no reward, to bear the cost of monitoring other peoples networks 
seems unrealistic.


I don't know how often I hear, 'We don't monitor our networks/customers, 
because otherwise we might be deemed responsible for the activity'


But getting off topic now..

But maybe instead of being critical, we should take time to thank those 
people who take the time out to provide that service, an obviously 
thankless job..


I think we all can agree that there are more network operators not doing 
their job (egress spam) than problem RBL operators.


Ps, how quickly should this operator expect to be removed from an RBL..

104.168.151.9 6   if1.perfecthealthadvice.com
104.168.151.107   host-10.thedesiredhealth.net
104.168.151.116   static-11.loveandhealthiness.net
104.168.151.1456   smtp.naturalhealthsaver.net
104.168.151.1548   manicmarketer.com
104.168.151.1753   mxst11.health-galleria.com
104.168.151.1857   manicmarketer.com
104.168.151.1954   abts.thedesiredhealth.net
104.168.151.2045   tgn.loveandhealthiness.net
104.168.151.4345   deadbeatmarketer.com
104.168.151.4449   deadbeatmarketer.com
104.168.151.4647   deadbeatmarketer.com
104.168.151.4749   deadbeatmarketer.com





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Steve Atkins]

> On Jan 6, 2017, at 7:27 AM, Kelly Molloy  wrote:
> 
> On Fri, Jan 6, 2017 at 9:00 AM, Vick Khera  wrote:
>> 
>> 
>> So if you're goal is to solve problems, then what's the point of having a
>> minimum 48 hour block when the problem is solved at the origin within
>> minutes? That's just punitive and not constructive.
> 
> Because the proof of the pudding is in the eating. I cannot tell you
> how many times in my umpteen years of running DNSBLs that someone has
> sworn to me that the problem is fixed and then I get more spam. DNSBL
> maintainers do what they do to protect their users. We do not do what
> we do to make things easy and convenient for senders.

Which is what makes the question "has this affected your delivery?" particularly
relevant. A blacklist that isn't used isn't relevant.

Some of the reasons that a blacklist won't be used outside the hobbyist niche
are technical - false positives or poor response to them, ineffectiveness 
against
actually bad mail and so on. Some of them are more social, such as how the
blacklist is represented in public.

Reputation services (and blacklists are a subset of reputation services) that
combine good data, professional image and behaviour and responsive support
when it's needed are the ones that tend to be widely used. And that wide use
is what gives them the clout to actually affect behaviour of senders.

Cheers,
  Steve


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Rich Kulawiec]

On Wed, Jan 04, 2017 at 08:49:47AM -0500, Vick Khera wrote:
> SORBS does not seem interested in
> solving problems, but in punishing people.

It is impossible for SORBS (or any other DNSBL/RHSBL) to punish anyone.
Even if they wanted to -- and I see no evidence that they do -- they can't.
The same is true of recipient mail systems.

It's always good to keep in mind that having your mail accepted somewhere
is a privilege, not a right, and that recipient systems are free to
cease extending that privilege in whole or in part at any time with or
without notice and with or without reason.  They can do it because the
sending host was listed by SORBS or because the sender is in a snowshoe
block or because it's Tuesday at 3 o'clock.

We can debate the merits of these choices (and we have, ad infinitum)
but even if we concur that they're insanely bad choices -- like that
last one -- none of them are punishment, because -- absent a contract
for services -- you were never entitled to those privileges in the first
place.

---rsk

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Kelly Molloy]

On Fri, Jan 6, 2017 at 9:00 AM, Vick Khera  wrote:
>
>
> So if you're goal is to solve problems, then what's the point of having a
> minimum 48 hour block when the problem is solved at the origin within
> minutes? That's just punitive and not constructive.

Because the proof of the pudding is in the eating. I cannot tell you
how many times in my umpteen years of running DNSBLs that someone has
sworn to me that the problem is fixed and then I get more spam. DNSBL
maintainers do what they do to protect their users. We do not do what
we do to make things easy and convenient for senders.

On Fri, Jan 6, 2017 at 9:00 AM, Vick Khera  wrote:
>
> On Thu, Jan 5, 2017 at 7:07 PM, Michelle Sullivan 
> wrote:
>>
>> So taking your blatant attack literally which I was under the impression
>> was against list policy, lets instead attempt to be constructive and have a
>> clam discussion...  "SORBS does not seem interested in solving problems, but
>> in punishing people." quite the opposite is in fact true, but often is could
>> be seen this way, what would *YOU* suggest we do instead, and what do *YOU*
>> perceive as "not interested in solving problems" and what do *YOU* perceive
>> as "punishment"... and I will answer why we can/cannot implement such
>> policies/changes... you never know we might come up with changes that work
>> better for everyone, though having been around this very attack many times
>> in the past, I'll be upfront and honest... I highly doubt it.
>
>
> So if you're goal is to solve problems, then what's the point of having a
> minimum 48 hour block when the problem is solved at the origin within
> minutes? That's just punitive and not constructive.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[ComKal Networks]

> So if you're goal is to solve problems, then what's the point of having a
> minimum 48 hour block when the problem is solved at the origin within
> minutes? That's just punitive and not constructive.

a) When you run an RBL, the bulk of so called abuse departments
reply that the problem is solved, then it starts again within hours
or the next day from the same IP. To many people mean solved
is when they report the spam to the spammer without actually
using a brain to analyse the problem and actually fix it.

b) Some email queues need time to clear, true, not 48 hours
normally but at least 48 hours after the last spam still helps
to reduce the re occurance of said spam.

c) There are other reasons.

48 hours is in my experience a good trade off between
several factors and what I would call constructive.
My personal RBL retains the IP for up to 5 days from
the last spam but thats because several factors are in play,
and its purely for my personal server.

Other public RBL's often include IP's for much longer
than 48 hours after the 'problem' has been solved depending
very much on the IP's (or the range) past history, so your
lucky with SORBS.

Really, if SORBS causes a problem for someone receiving
email, that provider does not have to use SORBS, that
customer doesnt have to remain with that provider. No one
is twisting anyones arm. RBL's are a trade off between
several factors, something we have to live with and work
with and or around.

Regards
Ian Manners



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Michelle Sullivan]

Vick Khera wrote:


On Thu, Jan 5, 2017 at 7:07 PM, Michelle Sullivan > wrote:


So taking your blatant attack literally which I was under the
impression was against list policy, lets instead attempt to be
constructive and have a clam discussion...  "SORBS does not seem
interested in solving problems, but in punishing people." quite
the opposite is in fact true, but often is could be seen this way,
what would *YOU* suggest we do instead, and what do *YOU* perceive
as "not interested in solving problems" and what do *YOU* perceive
as "punishment"... and I will answer why we can/cannot implement
such policies/changes... you never know we might come up with
changes that work better for everyone, though having been around
this very attack many times in the past, I'll be upfront and
honest... I highly doubt it.


So if you're goal is to solve problems, then what's the point of 
having a minimum 48 hour block when the problem is solved at the 
origin within minutes? That's just punitive and not constructive.


It was chosen as a balanced figure, the balance between stopping a 
spammer and allowing an innocent to delist, not to mention stopping a 
clueless/homeuser/enduser from delisting an ISP's mail server before the 
admins find the issue and resolve it.  Bare in mind, those with "ISP 
login" (NetManager Access and the appropriate permissions) can delist 
regardless of the 48 hours, those without the login cannot and have to 
rely on the robot if not using the IP specifically as the robot will 
also adhere to the 48 hours.


Therefore, I'm not even going to discuss the issue of 'problem solved 
within minutes' issue at this point as you will note the above covers 
where this is likely to be true, as apposed to those (who we get on a 
regular basis) who claim to have 'fixed the issue' whilst we are noting 
spam still emanating from the host(s)... (don't know if they just 
cluelessly fail to flush the queued spam to /dev/null or whether they 
are just saying anything to get delisted - I suspect both in many cases.)


Next!?

Michelle

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Vick Khera]

On Thu, Jan 5, 2017 at 7:07 PM, Michelle Sullivan 
wrote:

> So taking your blatant attack literally which I was under the impression
> was against list policy, lets instead attempt to be constructive and have a
> clam discussion...  "SORBS does not seem interested in solving problems,
> but in punishing people." quite the opposite is in fact true, but often is
> could be seen this way, what would *YOU* suggest we do instead, and what do
> *YOU* perceive as "not interested in solving problems" and what do *YOU*
> perceive as "punishment"... and I will answer why we can/cannot implement
> such policies/changes... you never know we might come up with changes that
> work better for everyone, though having been around this very attack many
> times in the past, I'll be upfront and honest... I highly doubt it.
>

So if you're goal is to solve problems, then what's the point of having a
minimum 48 hour block when the problem is solved at the origin within
minutes? That's just punitive and not constructive.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop