[mailop] Admin: Thread end - SORBS help

[Simon Lyall]

All,

This thread is getting a little abrasive and appears to just be the same 
arguments about DNSBLs in general and SORBS in particular that have been 
going on for many years.


If fact, It would appear that we are coming up on the 20th anniversary of 
RBLs:


http://sunsite.uakom.sk/sunworldonline/swol-12-1997/swol-12-vixie.html

Not only were they distributed by BGP back then but Vixie still used 
capital letters.


Maybe there should be a party or something.

Simon
Mailop Mod Team

--
Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
"To stay awake all night adds a day to your life" - Stilgar


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

Re: [mailop] AOL FBL

[Lili Crowley via mailop]

We thought about this but most of those are automated on the recip
side and would be parsed and forgotten.

Thanks.

Lili

> On Jan 9, 2017, at 9:48 PM, Rich Kulawiec  wrote:
>
>> On Mon, Jan 09, 2017 at 03:18:06PM -0500, Lili Crowley via mailop wrote:
>> This went live on the blog a couple of months ago. Just in case, here it is
>> below.
>
> I suggest that you send this out to all of the registered feedback
> loop addresses, since (a) not everyone reads your blog and (b) not
> everyone reads this mailing list but -- hopefully -- everyone who
> has a registered feedback loop really does read mail from that.
>
> Also, if there are any issues with it (for example, I'll have a
> trivial issue because my procmail ruleset will need a tweak) this
> will serve to highlight those before the change goes into effect.
>
> ---rsk
>
> ___
> 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] AOL FBL

[Rich Kulawiec]

On Mon, Jan 09, 2017 at 03:18:06PM -0500, Lili Crowley via mailop wrote:
> This went live on the blog a couple of months ago. Just in case, here it is
> below.

I suggest that you send this out to all of the registered feedback
loop addresses, since (a) not everyone reads your blog and (b) not
everyone reads this mailing list but -- hopefully -- everyone who
has a registered feedback loop really does read mail from that.

Also, if there are any issues with it (for example, I'll have a
trivial issue because my procmail ruleset will need a tweak) this
will serve to highlight those before the change goes into effect.

---rsk

___
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

[Robert Mueller]

> I'm thinking that perhaps your cert is using SHA-(256|512) and
> something better than 3DES for HMAC, and therefore the remote servers
> are unable to work with the certificate as they don't have access to
> the required crypto. I sincerely hope this is not the case, but
> perhaps you can test this by using a certificate signed with "export
> grade" algorithms...


That's not a bad theory. However I just checked, and our cert was
upgraded to sha256 around Dec 2014, but based on our logs, we only had
to introduce the workarounds in Oct 2015, so it doesn't seem related to
the sha1 -> sha256 upgrade of our cert. Also from what I hear from some
others, they don't have problems with a sha256 cert either from the same
hosts we're having problems with.


Rob Mueller

r...@fastmail.fm


___
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

[Luis E. Muñoz]

This error seems similar to one we observed earlier in an unrelated 
application.


Long story short, one of our customers' SSL library was rejecting our 
certificates  with vague certificate errors. The culprit was that the 
client SSL library was configured to honor the historic export 
restrictions and considered the combination of algorithms we were using 
for HMAC, invalid. Once the client upgraded his SSL config to allow all 
algorithms, the certificates were accepted and TLS connections were 
happy again.


I'm thinking that perhaps your cert is using SHA-(256|512) and something 
better than 3DES for HMAC, and therefore the remote servers are unable 
to work with the certificate as they don't have access to the required 
crypto. I sincerely hope this is not the case, but perhaps you can test 
this by using a certificate signed with "export grade" algorithms...


Best regards

-lem


On 9 Jan 2017, at 16:04, Robert Mueller wrote:


 You may want to use this tool on your mail server(so it picks up the
same openssl version) to check what cyphers the mil server accepts:
https://testssl.sh/




I'm not sure how this would help. The problem occurs with them trying 
to
send mail to us. I know what ciphers we offer, what I don't know is 
what

they don't like about our cipher list. Sure I can use this script to
connect back to them to see what they're incoming servers accept, but 
we

don't have a problem with that, it's only when they connect to us that
they bail out with the "Certificate rejected over TLS" error.


Also based on what I've heard from others, they're quite happy to
connect to other servers with a secure TLSv1.2 cipher, one that we
actually offer. So why are they failing to use that cipher when
connecting to us? The client gets to choose, so the only thing I can
think of is they're trying to connect with a weaker cipher first, 
seeing
we accept, and then aborting any attempt to send us email at all. 
Sounds

very strange.


Hmmm, "Certificate rejected"... that doesn't sound like a cipher error
either does it. Of course, you never can be sure with error messages,
though I wonder if they just don't like wildcard certificates or
something like that?


More likely, there's some subtle protocol level incompatibility going 
on

somewhere that's going to be painful to debug.


Rob Mueller

r...@fastmail.fm




___
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] Trying to work out cause of "Certificate rejected over TLS. (unknown protocol)" error

[Robert Mueller]

> You may want to use this tool on your mail server(so it picks up the
> same openssl version) to check what cyphers the mil server accepts:
> https://testssl.sh/



I'm not sure how this would help. The problem occurs with them trying to
send mail to us. I know what ciphers we offer, what I don't know is what
they don't like about our cipher list. Sure I can use this script to
connect back to them to see what they're incoming servers accept, but we
don't have a problem with that, it's only when they connect to us that
they bail out with the "Certificate rejected over TLS" error.


Also based on what I've heard from others, they're quite happy to
connect to other servers with a secure TLSv1.2 cipher, one that we
actually offer. So why are they failing to use that cipher when
connecting to us? The client gets to choose, so the only thing I can
think of is they're trying to connect with a weaker cipher first, seeing
we accept, and then aborting any attempt to send us email at all. Sounds
very strange.


Hmmm, "Certificate rejected"... that doesn't sound like a cipher error
either does it. Of course, you never can be sure with error messages,
though I wonder if they just don't like wildcard certificates or
something like that?


More likely, there's some subtle protocol level incompatibility going on
somewhere that's going to be painful to debug.


Rob Mueller

r...@fastmail.fm


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

[mailop] AOL FBL

[Lili Crowley via mailop]

This went live on the blog a couple of months ago. Just in case, here it is
below.

*If you are keying off our current address, that will be changing*.

In order for AOL to begin to DKIM sign the Feedback Loop (FBL) mail that
AOL sends to registered recipients, we need to change the sender name on
each FBL message. Therefore, starting on *Jan 17, 2017*, the sender name on
all FBL emails will be changed from 'sc...@aol.net' to '
fbl-no-re...@postmaster.aol.com' and all FBL mail will be signed with DKIM
domain (d=) mx.postmaster.aol.com.


Thanks!
Lili



Lili Crowley
AOL Postmaster
___
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 Sat, Jan 7, 2017 at 7:04 PM, Michelle Sullivan > wrote:


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!?


Still waiting Vick...  What else needs to be solved?


I said what I needed to say, and you dismissed it out of hand. I see 
no point in continuing to discuss this topic with you, considering how 
abrasive you are.


No, I didn't dismiss you our of hand... You are referring just to 
'delisting takes a minimum of 48 hours' and you have had a reason why 
(in fact you have had multiple reasons and from some very well informed 
people that are not "SORBS supporters" but understand the issue 
perfectly) we have the limit, and you have had information that the 48 
hours is "waveable" by human interaction, though in the case that caused 
this thread there was a breakdown in process that has otherwise been 
addressed...  So yes I am abrasive, because I suspected (and you are 
proving me right) that the thread is not about solving problems, but 
about kicking me/SORBS into changing policy to do what is convenient for 
you and spammers alike regardless of SORBS' users wishes or what is 
best, tried and tested, or a compromise between good and bad for all...  
Which funnily enough is exactly what Google and Amazon are trying to do 
at the moment, and spammers have been trying to do for years...  ie 
change stuff to make their jobs simple and make it so they can just 
ignore SORBS and maximize profits at the cost of real people.


If you really want to solve problems, you need to open a dialog, and 
accept not that not all problems will be "solved" to your satisfaction 
as there may be good reasons why something seems to be a problem... and 
note "problems" (as per your email) is plural, the 48 hour default 
restriction you complained about is one 'problem' (singular)


I am willing to listen to all, and change where appropriate/possible, 
but you have to engage at a level that does not suit just "your problem" 
and instead aids with "a problem".


Regards,

Michelle


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

Re: [mailop] SORBS help

[Alberto Miscia via mailop]

I don't think that this is the best attitude for helping the email
ecosystem (and I suppose this is what we all want to accomplish).
I don't want to take anyone's side either because in the past I used to
complain about some blacklists as well and I perfectly understand where
we're coming from. But I have learned to listen to others' advices, value
their opinion and respect different positions.

Personally I consider SORBS in my short list of reputable blacklist
operators, no matter if I had arguments with them in the past. They are not
Spamhaus but they are not like "V*BL" or similar either..

The reliability of a specific blacklist operator lies in the number of
systems that are considering them in their fltering/processing. If they
were unreilable probably no one would care about them and probably they
would not have a presence here.

I can only hope this thread goes away before reaching hundreds replies..

Thanks!

Alberto Miscia | Head of Deliverability & Compliance | MailUp


2017-01-09 14:20 GMT+01:00 Vick Khera :

>
> On Sat, Jan 7, 2017 at 7:04 PM, Michelle Sullivan 
> wrote:
>
>> 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!?
>>>
>>
>> Still waiting Vick...  What else needs to be solved?
>>
>
> I said what I needed to say, and you dismissed it out of hand. I see no
> point in continuing to discuss this topic with you, considering how
> abrasive you are.
>
>
> ___
> 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] False positive on spoofing

[Scott E Bonacker CPA]

> The record does not permit messages to be sent through Office365.

Should be fixed now, we'll see.

Scott

-Original Message-
From: SM [mailto:s...@elandnews.com] 
Sent: Thursday, January 5, 2017 10:57 AM
To: Scott E Bonacker CPA ; mailop@mailop.org
Subject: Re: [mailop] False positive on spoofing

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] SORBS help

[Vick Khera]

On Mon, Jan 9, 2017 at 9:11 AM, Kelly Molloy  wrote:

> I realize that doesn't fit with your narrative that DNSBL operators
> care about nothing but punishing senders, but it is nonetheless true.
>

No, I was specific about SORBS, not all DNSBLs.
___
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

[Valdis . Kletnieks]

On Mon, 09 Jan 2017 14:48:19 +, Graeme Fowler said:
> On 9 Jan 2017, at 14:08, Franck Martin via mailop  wrote:
> > Often, it is a problem of finding an acceptable cypher to both parties...

I have to admit my first guess was that one end insisted on TLS 1.0 or later
and the other end was ancient enough to only support SSL 3.0.  It's pretty
obvious when wireshark catches it.




pgpn3KOE5Vtlk.pgp
Description: PGP signature
___
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

[Franck Martin via mailop]

You may want to use this tool on your mail server(so it picks up the same
openssl version) to check what cyphers the mil server accepts:
https://testssl.sh/

Beware, I believe one connection is open for each cypher tested, the client
offers only one cypher and see if the connection completes...



On Mon, Jan 9, 2017 at 6:48 AM, Graeme Fowler 
wrote:

> On 9 Jan 2017, at 14:08, Franck Martin via mailop 
> wrote:
>
> Often, it is a problem of finding an acceptable cypher to both parties...
>
>
> ...after...
>
> On Mon, Jan 9, 2017 at 4:21 AM, Robert Mueller  wrote:
>>
>> So it turns out we'd actually encountered this problem before (Oct
>> 2015), and had put a work around in place at the time. It appears that
>> us.af.mil servers were having problems connecting to our postfix
>> instances and at the time couldn't work out what the obvious reason was
>> so I had added this to our postfix config.
>
>
> They're finding a cipher they don't like - so far as I can ascertain, your
> host is offering an RC4 based cipher. If they're .mil, as you mention, then
> their cipher compatibility list will likely be small and hard (so to
> speak). I can't speak for why they'd not connect to you as a result, that's
> up to them.
>
> https://ssl-tools.net/mailservers/mx1.messagingengine.com
>
> Graeme
>
> ___
> 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] Trying to work out cause of "Certificate rejected over TLS. (unknown protocol)" error

[Graeme Fowler]

On 9 Jan 2017, at 14:08, Franck Martin via mailop  wrote:
> Often, it is a problem of finding an acceptable cypher to both parties...

...after...

> On Mon, Jan 9, 2017 at 4:21 AM, Robert Mueller  > wrote:
> So it turns out we'd actually encountered this problem before (Oct
> 2015), and had put a work around in place at the time. It appears that
> us.af.mil  servers were having problems connecting to our 
> postfix
> instances and at the time couldn't work out what the obvious reason was
> so I had added this to our postfix config.

They're finding a cipher they don't like - so far as I can ascertain, your host 
is offering an RC4 based cipher. If they're .mil, as you mention, then their 
cipher compatibility list will likely be small and hard (so to speak). I can't 
speak for why they'd not connect to you as a result, that's up to them.

https://ssl-tools.net/mailservers/mx1.messagingengine.com 


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

Re: [mailop] SORBS help

[Kelly Molloy]

On Mon, Jan 9, 2017 at 8:11 AM, Vick Khera  wrote:
>>
> That makes sense if you get no response from the affected sender. However,
> if they are able to show you how the problem was fixed then what's the
> purpose? Especially when you already have reputation data for that sender
> over long time periods and can see whether they should be trusted or not.

Just saying you fixed it doesn't mean it is fixed. Even with the best
intentions and skills, a sender can absolutely in good faith believe
something is fixed, but it is not. It happens all the time. A delay
allows a DNSBL operator to be sure their users are protected.

I realize that doesn't fit with your narrative that DNSBL operators
care about nothing but punishing senders, but it is nonetheless true.

___
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

[Franck Martin via mailop]

The negotiation of STARTTLS is done in clear, so a packet capture will tell
you where the problem is... Wireshark usually explains well what options
are in the packets...

Often, it is a problem of finding an acceptable cypher to both parties...

Finally, make sure your firewall is not messing up with SMTP packets...

On Mon, Jan 9, 2017 at 4:21 AM, 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)
>
> Just to update with more information.
>
> So it turns out we'd actually encountered this problem before (Oct
> 2015), and had put a work around in place at the time. It appears that
> us.af.mil servers were having problems connecting to our postfix
> instances and at the time couldn't work out what the obvious reason was
> so I had added this to our postfix config.
>
> main.cf
> ...
> # Disable starttls for some problematic hosts
> smtpd_discard_ehlo_keyword_address_maps =
> cidr:/etc/postfix/access_client-helo_keyword.cidr
>
> access_client-helo_keyword.cidr
> # us.af.mil has TLS problems. IPs taken from SPF record (e.g. dig
> us.af.mil TXT)
> 132.3.0.0/16 starttls
> ...
> 131.15.70.0/24 starttls
>
> It appears recently they must have added additional servers, since their
> SPF records have changed. Adding these:
>
> +131.9.253.0/24 starttls
> +131.27.1.0/24 starttls
>
> Fixed the problem.
>
> Ideally I'd like to actually work out what's causing the sending servers
> to fail with our TLS configuration, but it's a bit of work I haven't had
> time for, thus this work around for now.
>
> --
> Rob Mueller
> r...@fastmail.fm
>
> ___
> 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

[Rich Kulawiec]

On Thu, Jan 05, 2017 at 11:14:41PM -0500, Rob McEwen wrote:
> 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.

Only if they're very poorly architected, designed, and implemented.
Properly-built/run mail systems have their defenses built in layers --
of which DNSBLs may certainly be one, but should *not* be the first
one or the only one.  After all, there have been DNSBL outages and
shutdowns many times: by now, everyone with even modest experience
should be aware of this and should be fully prepared to cope with an
event like -- let's say -- a permanent shutdown of spamhaus.org with
no advance notice.  (Not that I'm hoping for that, of course.  Despite
my many policy disagreements with them over the years, I think that they
do what they say they do extremely well.)

The mail system here, for example, applies 29 layers of internal checks
before consulting any DNSBL.  That's good for this operation (because
it's efficient, very predictable, extremely scalable, easily monitored
and modified) and it's good for the DNSBLs, because it reduces the load
on them by a tiny increment.  The other mail systems I've been and am
involved with are similar: the number of checks and their order varies,
of course, but the principle is the same.  All of those systems (some
of which are quite large) will continue to function in the event of
a shutdown of all DNSBLs.  Yes, they'll see an increase in the FN
rate, but not a major one -- and that is a tractable problem.

(In fact, it's a problem that is being and has been continuously
addressed for years.  It's an ongoing task to analyze everything
that gets past the internal layers but is listed by a DNSBL,
in order to figure out how to improve the internal layers.)

---rsk

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

Re: [mailop] SORBS help

[Vick Khera]

On Sat, Jan 7, 2017 at 7:04 PM, Michelle Sullivan 
wrote:

> 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!?
>>
>
> Still waiting Vick...  What else needs to be solved?
>

I said what I needed to say, and you dismissed it out of hand. I see no
point in continuing to discuss this topic with you, considering how
abrasive you are.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Vick Khera]

On Fri, Jan 6, 2017 at 9:01 PM, Noel Butler  wrote:

> People go away, businesses shutdown over weekends etc, so you need time
> for them to find out they have a problem and resolve it.
>
>
That makes sense if you get no response from the affected sender. However,
if they are able to show you how the problem was fixed then what's the
purpose? Especially when you already have reputation data for that sender
over long time periods and can see whether they should be trusted or not.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Symantec blocking list issue

[Robert Mueller]

Just wondering if there's a Symantec contact here or someone else that
might know what's happening here.

A number of our users are reporting that KPN (a Netherlands ISP) are
rejecting our emails. An example in our logs a few minutes ago.

2017-01-09T07:22:13.671964-05:00 gateway1 postfix-forward/smtp[3495284]:
62B58139D: to=<...@kpnplanet.nl>,
relay=mailin.kpnmail.nl[213.75.3.30]:25, delay=0.27,
delays=0.01/0/0.26/0, dsn=4.0.0, status=deferred (host
mailin.kpnmail.nl[213.75.3.30] refused to talk to me: 421 5.5.0 Your IP
has been blacklisted. Please contact ab...@kpn.com for more
information.)
 
I contacted ab...@kpn.com and they said:

---
 We use a Zodiac list from Symantec. You can request an investigation by
 Symantec using http://ipremoval.sms.symantec.com/lookup/
---

However going to http://ipremoval.sms.symantec.com/lookup/ and entering
our sending IP gave:

---
The IP address you submitted, 66.111.4.25, does not have a negative
reputation and therefore cannot be submitted for investigation.
---

The blocking has been going on for a few days now, so I don't believe
there's any caching issue or anything here.

So I'm wondering if there's anyone on the Symantec side I can work with
to talk to KPN to find out where the actual problem is...

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

___
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

[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)

Just to update with more information.

So it turns out we'd actually encountered this problem before (Oct
2015), and had put a work around in place at the time. It appears that
us.af.mil servers were having problems connecting to our postfix
instances and at the time couldn't work out what the obvious reason was
so I had added this to our postfix config.

main.cf
...
# Disable starttls for some problematic hosts
smtpd_discard_ehlo_keyword_address_maps =
cidr:/etc/postfix/access_client-helo_keyword.cidr

access_client-helo_keyword.cidr
# us.af.mil has TLS problems. IPs taken from SPF record (e.g. dig
us.af.mil TXT)
132.3.0.0/16 starttls
...
131.15.70.0/24 starttls

It appears recently they must have added additional servers, since their
SPF records have changed. Adding these:

+131.9.253.0/24 starttls
+131.27.1.0/24 starttls

Fixed the problem.

Ideally I'd like to actually work out what's causing the sending servers
to fail with our TLS configuration, but it's a bit of work I haven't had
time for, thus this work around for now.

-- 
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)?

[Stuart Paton]

Hi,

I know the Mail Admin at UPC Austria - these guys also manage the
VirginMedia UK environment as well. Asked him to join mailop to respond
directly but don't know if he will.

Anyway this is all he sent me so far but asked for a comment on the
greylist issue:

We use and maintain the following SPF record for domains that are SPF
protected.



host -tTXT mx.spf.upcmail.net

mx.spf.upcmail.net descriptive text "v=spf1 ip4:62.179.121.0/24 ip4:
213.46.255.0/24 ip4:84.116.36.0/24 -all"



Thanks

Stuart

Open-Xchange



On 5 January 2017 at 09:19, Benoit Panizzon  wrote:

> 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
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop