Re: [mailop] SORBS help

[Rob McEwen]

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.


The infrastructure upgrades needed to block spam without that highly 
efficient "front line" of IPv4 sender-IP blacklists... would break 
budgets and break entire business models. Many ISPs and hosting and spam 
filtering companies would go from operating "in the black"... to 
operating "in the red"... instantly. Even the largest ones wouldn't be 
immune because often their ability to scale depends even more on IPv4 
sending-IP blacklists GREATLY lightening the load before the mail stream 
is processed by other filtering techniques.


Another problem is that ESPs and hosters would then care much LESS about 
keeping their IP space clean. Turns out... Scarcity of IPv4 is actually 
a "feature" in our current situation (at least with regards to the spam 
problem). Such scarcity of IPv4 IPs is sometimes the ONLY thing that 
motivates many ESP and hosters to not harbor spammers and to kick 
spammers off their networks. And even the more ethical ESPs and hosters 
would still find it difficult to be as motivated without the scarcity of 
"clean" IPv4 space causing them to so greatly value it. For even the 
best ESP and hosters, the benefits of making the next sale and getting 
paid more would start to outweigh the virtues of keeping their space 
clean, in an IPv6-for-mail-servers world.


For example, not that long ago, Brian Krebs wrote an article about a 
large hoster ("HostWinds") who cleaned up their act because they found 
that their legit customers' mail deliverability was hurting due to them 
allowing so many spammers to climb on-board. Eventually, their business 
started to implode. They then kicked the spammers off... took a huge 
financial hit doing so... but then built their business back up - the 
right way. I suspect that HostWinds would have never had to come to such 
terms in an IPv6-mail-server world. Instead, they would have found it 
very easy to just acquire more IPv6 addresses and then separate their 
spammy customers from their legit customers - and the cost and ease of 
doing business for spammers would then be LOWER than it is today! 
(multiply this scenario by thousands!... then consider the cumulative 
difference!)


Keep in mind that:

(1) yes, I'm sure we'll have to go all-IPv6 EVENTUALLY - but be careful 
what you ask for - you just might get it - a LOT sooner than the world 
is ready for it


(2) Even if mail servers stay IPv4 (for some time) - they can still 
accept SMTP-Authenticated IPv6 mail from IPv6 mail clients - which is an 
order of magnitudes larger number of computers that touch e-mail, 
compared to the number of actual MTAs--Therefore, much progress can be 
made in the shorter term - and we're the not actually nearly as much at 
risk of running out of IPv4 space for mail servers, since mail servers 
add up to a relatively small number of connections compared to mail 
clients (and everything else!).


(3) There are many good techniques for IPv6 MTAs to force more 
transparency/identity in an IPv6 world (DKIM, FCrDNS, dmarc, and related 
uses of SPF - and related domain reputation for all of these things)... 
but when so many senders STILL can't get FCrDNS right in IPv4 yet, it is 
hard to believe that these other technologies can get universally 
implemented in the foreseeable future - and these other technologies 
still don't scale nearly as well as IPv4 sending-IP blacklists, and are 
themselves somewhat limited in their ability to block spam (like many 
anti-spam technologies).


--
Rob McEwen



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

Re: [mailop] SORBS help

[Michelle Sullivan]

John Leslie wrote:

Michelle Sullivan  wrote:

...
On Tue, Jan 3, 2017 at 8:13 PM, Bryan Vest > 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 

Re: [mailop] SORBS help

[John Leslie]

Michelle Sullivan  wrote:
>>...
>> On Tue, Jan 3, 2017 at 8:13 PM, Bryan Vest > > 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.

> 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.

> 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...

   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.

   (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. :^(

   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.

   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 

___
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 Tue, Jan 3, 2017 at 8:13 PM, Bryan Vest > 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.


How much trouble is it causing you? I find it doesn't cause all that 
much trouble in terms of mail being blocked. SORBS does not seem 
interested in solving problems, but in punishing people.


SORBS is about blocking spam no matter who the sender is well for 
the moment.  Needless to say some don't like that policy and have over 
the years tried to force change by bad mouthing, suggesting that we 
don't do that, and even personal attacks against me...


There are players in the market who believe they are too big to block 
(one in particular that seems (from an external perspective) to like to 
move around the spammers and innocent end users to cause maximum 
backlash)... which means they are trying to play government...  At least 
that's how I see it (aren't governments that make laws against stealing, 
punish people in their system, then sent about systematically stripping 
assets from everyone else to line their own pockets?... or is that just 
the corruption in Malta?).. I guess your mileage and point of view will 
vary.)


So Vick...

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.


Regards,

Michelle

PS: That invitation is open to anyone and everyone who wants to join a 
civil discussion  Whether it is appropriate to this list or not I'll 
have to leave to others to decide.


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

Re: [mailop] False positive on spoofing

[SM]

Hi Scott,
At 08:06 05-01-2017, Scott E Bonacker CPA wrote:
Since upgrading to a new laptop with OEM Win10x64, and OL2016 
connected to an Office365 account, I have also been sending messages 
to various lists via POP using a domain


The messages are sent via SMTP.

different than the one registered with Office365. That has resulted 
in false positive
 alerts when messages are distributed by some systems - the alert 
below was inserted by LISTSERV-TCP/IP release 16.0.  Interestingly, 
msgs distributed by Yahoo Groups don't get


There is a SPF record for your domain name.  The record does not 
permit messages to be sent through Office365.


Regards,
-sm 



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

Re: [mailop] False positive on spoofing

[Scott E Bonacker CPA]

> At a guess it's something to do with your SPF record.
> What domain are you sending from when you get the problems? Is the SPF record 
> for that domain set up to allow sending through the Office365 account?

Thanks Paul,
OL2016 connects via IMAP to Office365 registered with a domain, but most 
outgoing messages are actually sent via POP using domain2. I had tried 
connecting the domain2 accounts to Office365, and even changing the DNS 
pointers to Office365, but the result was messages going out as "Sent by 
sco...@domain1.com on behalf of sco...@domain2.com" which was in many ways 
worse.
Sending VIA POP avoids that on-behalf-of issue, but creates another one.
I'll take a look at SPF - 
https://technet.microsoft.com/en-us/library/dn789058(v=exchg.150).aspx 
Scott

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Paul Smith
Sent: Thursday, January 5, 2017 10:24 AM
To: mailop@mailop.org
Subject: Re: [mailop] False positive on spoofing

On 05/01/2017 16:06, Scott E Bonacker CPA wrote:
> Since upgrading to a new laptop with OEM Win10x64, and OL2016 connected to an 
> Office365 account, I have also been sending messages to various lists via POP 
> using a domain different than the one registered with Office365. That has 
> resulted in false positive alerts when messages are distributed by some 
> systems - the alert below was inserted by LISTSERV-TCP/IP release 16.0.  
> Interestingly, msgs distributed by Yahoo Groups don't get a similar alert.
> Is there anything a user can do to avoid creating false-positives like this, 
> or is this just a fact of life now?

At a guess it's something to do with your SPF record.

What domain are you sending from when you get the problems? Is the SPF record 
for that domain set up to allow sending through the Office365 account?
 


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

Re: [mailop] False positive on spoofing

[Paul Smith]

On 05/01/2017 16:06, Scott E Bonacker CPA wrote:

Since upgrading to a new laptop with OEM Win10x64, and OL2016 connected to an 
Office365 account, I have also been sending messages to various lists via POP 
using a domain different than the one registered with Office365. That has 
resulted in false positive alerts when messages are distributed by some systems 
- the alert below was inserted by LISTSERV-TCP/IP release 16.0.  Interestingly, 
msgs distributed by Yahoo Groups don't get a similar alert.
Is there anything a user can do to avoid creating false-positives like this, or 
is this just a fact of life now?


At a guess it's something to do with your SPF record.

What domain are you sending from when you get the problems? Is the SPF 
record for that domain set up to allow sending through the Office365 
account?



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

[mailop] False positive on spoofing

[Scott E Bonacker CPA]

Since upgrading to a new laptop with OEM Win10x64, and OL2016 connected to an 
Office365 account, I have also been sending messages to various lists via POP 
using a domain different than the one registered with Office365. That has 
resulted in false positive alerts when messages are distributed by some systems 
- the alert below was inserted by LISTSERV-TCP/IP release 16.0.  Interestingly, 
msgs distributed by Yahoo Groups don't get a similar alert.
Is there anything a user can do to avoid creating false-positives like this, or 
is this just a fact of life now?

Thanks,

Scott Bonacker CPA – McCullough and Associates LLC – Springfield, MO
-Original Message-
From: Scott E Bonacker CPA
Sent: Thursday, January 5, 2017 9:38 AM
To: 
Subject: 

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

That's a good effort-saving idea, similar to the Adobe Acrobat plug-in for 
accountants - https://www.safesend.com/product/tic-tie-calculate/
Which might, BTW, also be useful for attorneys in some areas.

Scott Bonacker CPA – McCullough and Associates LLC – Springfield, MO

-Original Message-
From: 
Sent: Thursday, January 5, 2017 8:35 AM
To: 
Subject: 

I want it:
http://www.lawsitesblog.com/2017/01/debuting-tomorrow-keyboard-designed-just-lawyers.html


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

Re: [mailop] Trying to work out cause of "Certificate rejected over TLS. (unknown protocol)" error

[Ken O'Driscoll]

Hi Rob,

Without seeing further info my first guess is the sending MTA is forcing an
encryption protocol (like SSLv3) which your endpoint doesn't support. 

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

On Thu, 2017-01-05 at 20:51 +1100, Robert Mueller wrote:
> We've suddenly had a couple of reports from users about people sending
> to them (e.g. sending from a remote service to our servers) failing and
> bouncing with the error message:
> 
> Certificate rejected over TLS. (unknown protocol)
[...snip...]

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

[mailop] Trying to work out cause of "Certificate rejected over TLS. (unknown protocol)" error

[Robert Mueller]

We've suddenly had a couple of reports from users about people sending
to them (e.g. sending from a remote service to our servers) failing and
bouncing with the error message:

Certificate rejected over TLS. (unknown protocol)

There's not much more in the error message, I haven't managed to get
hold of a complete bounce email yet, or find out what server is being
used, but I'm trying to get hold of that information.

I don't believe anything has changed on our side (software wise or
configuration wise), so I'm not sure why we're suddenly seeing a couple
of reports of these errors.

We're using postfix 2.11. We've got a valid cert that's not expired.

$ echo | openssl s_client -starttls smtp -connect
mx1.messagingengine.com:25  2>/dev/null | openssl x509 -noout -dates
notBefore=Nov 28 00:00:00 2016 GMT
notAfter=Feb  3 12:00:00 2020 GMT

Also confirmed it's the same for all of our mx servers.

Has anyone seen this error before and/or know what causes it?

-- 
Rob Mueller
r...@fastmail.fm

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

Re: [mailop] UPC / Liberty Global: No retries after tempfail (greylisting)?

[Benoit Panizzon]

Hi David

Quick update on the issue.

A tech from UPC Switzerland just called me back.

Apparently they are having a hard time, lots of UPC Switzerland
customers complaining about the email issue. Lots of trouble tickets
opened by other swiss ISP.

Responsible for the mess is UPC Austria (chello.at) who operates the
email infrastructure in the netherlands.

And apparently they are not getting through to them either. The techs in
austria pretend the problem is with the other ISP which use greylisting.

So if you could drop the techs in austria a hint to get in contact
with me: +41 61 826 93 14 I am willing to explain the exactly what the
problem is. They would probably figure it out themself it they would
look at the logfile examples I sent with the case I opened.

Regards

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

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