Re: [mailop] Cisco PIX Mailguard Oddity

[Al Iverson]

The Cisco PIX rears its ugly head yet again.

http://www.spamresource.com/2009/12/receiving-duplicate-list-messages.html

Cheers,
Al

--
Al Iverson
www.aliverson.com
(312)725-0130


On Thu, May 5, 2016 at 8:00 PM, Steve Atkins  wrote:
>
>> On May 5, 2016, at 5:08 PM, Todd Herr  wrote:
>>
>> Forgive me if this is off topic, but I don't know where else to turn.
>>
>> I've got a customer who's having trouble sending mail to two domains with 
>> nothing obvious (to me) in common save for one thing; both domain's primary 
>> MXen look to be sitting behind Cisco PIX devices with Mailguard turned on. I 
>> know this because of the greeting I get from both:
>>
>> 220 ***
>>
>> Now, everything I can find about these devices says that they only allow 
>> seven SMTP commands:
>>
>> HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT
>>
>> And they're supposed to respond with OK to everything else. These two 
>> domains, again not obviously related, mail servers in different /8s, don't 
>> even do that, though; both of them are responding in unsuspected ways even 
>> to commands from the above list, to wit:
>>
>> RSET
>> 500 Syntax error, command unrecognized
>> QUIT
>> 500 Syntax error, command unrecognized
>>
>> I've never wrangled one of these beasts (haven't even *seen* evidence of one 
>> in many years) so I'd like to ask you fine folks if you've ever seen 
>> anything like this from one of these, and what it means for their 
>> configuration? I mean, is this a common bug/misconfiguration, or have I just 
>> hit the lottery?
>
> I've seen them do that when they get out of sequence. Are you doing the 
> transaction above by hand (and with a real HELO and so on), or is it from MTA 
> logs?
>
> Also, if you're seeing connections drop during data there were several nasty 
> PIX traffic inspection bugs that triggered on DKIM signed mail that would 
> cause that. I have CSCsy28792, CSCsi01498, and CSCsh33982 bugs in my notes on 
> that.
>
> Cheers,
>   Steve
> ___
> 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] Cisco PIX Mailguard Oddity

[Dave Warren]

On 2016-05-05 17:08, Todd Herr wrote:

Forgive me if this is off topic, but I don't know where else to turn.

I've got a customer who's having trouble sending mail to two domains 
with nothing obvious (to me) in common save for one thing; both 
domain's primary MXen look to be sitting behind Cisco PIX devices with 
Mailguard turned on. I know this because of the greeting I get from both:


220 ***

Now, everything I can find about these devices says that they only 
allow seven SMTP commands:​


​ HELO, ​
MAIL
​, ​
RCPT
​, ​
DATA
​, ​
RSET
​, ​
NOOP
​, ​
QUIT
​


And they're supposed to respond with OK to everything else. These two 
domains, again not obviously related, mail servers in different /8s, 
don't even do that, though; both of them are responding in

​ unsuspected ways even to commands from the above list, to wit:

RSET
500 Syntax error, command unrecognized
QUIT
500 Syntax error, command unrecognized
​

​ I've never wrangled one of these beasts (haven't even *seen* 
evidence of one in many years) so I'd like to ask you fine folks if 
you've ever seen anything like this​ from one of these, and what it 
means for their configuration? I mean, is this a common 
bug/misconfiguration, or have I just hit the lottery?




They're broken by design and not fit for purpose. Among their many 
flaws, they don't even make it to RFC821 3.1, the MAIL command, which is 
described as the following:


MAIL  FROM: 

Instead, when they receive a "M" in a packet alone, they interpret it as 
an invalid command and don't bother to parse the rest of the command. 
However, if you deliver the whole command in one TCP packet, they will 
accept it; This is patently stupid.


Although TCP won't generally break up such a short string into multiple 
packets there's actually nothing wrong with doing so and there's no 
requirement in RFC 821 to send each command in a single packet. It also 
makes troubleshooting difficult since telnet and similar tools often 
send each byte as you type it rather than waiting for the . If you 
can configure your tool to send whole lines, you'll run into other 
stupidity, but it will at least attempt to recognize commands.


Given that RFC 821 is from August of 1982, I would wholeheartedly 
recommend unplugging them until they catch up to at least 1984, or if 
that's not possible, at least disable the SMTP-breaking "feature". Even 
Microsoft published a how-to article on the topic: 
https://support.microsoft.com/en-us/kb/320027


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

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

Re: [mailop] Cisco PIX Mailguard Oddity

[Steve Atkins]

> On May 5, 2016, at 5:08 PM, Todd Herr  wrote:
> 
> Forgive me if this is off topic, but I don't know where else to turn.
> 
> I've got a customer who's having trouble sending mail to two domains with 
> nothing obvious (to me) in common save for one thing; both domain's primary 
> MXen look to be sitting behind Cisco PIX devices with Mailguard turned on. I 
> know this because of the greeting I get from both:
> 
> 220 ***
> 
> Now, everything I can find about these devices says that they only allow 
> seven SMTP commands:​
> 
> ​HELO, ​MAIL​, ​RCPT​, ​DATA​, ​RSET​, ​NOOP​, ​QUIT​
> 
> And they're supposed to respond with OK to everything else. These two 
> domains, again not obviously related, mail servers in different /8s, don't 
> even do that, though; both of them are responding in​ unsuspected ways even 
> to commands from the above list, to wit:
> 
> RSET
> 500 Syntax error, command unrecognized
> QUIT
> 500 Syntax error, command unrecognized
> ​
> ​I've never wrangled one of these beasts (haven't even *seen* evidence of one 
> in many years) so I'd like to ask you fine folks if you've ever seen anything 
> like this​ from one of these, and what it means for their configuration? I 
> mean, is this a common bug/misconfiguration, or have I just hit the lottery?

I've seen them do that when they get out of sequence. Are you doing the 
transaction above by hand (and with a real HELO and so on), or is it from MTA 
logs?

Also, if you're seeing connections drop during data there were several nasty 
PIX traffic inspection bugs that triggered on DKIM signed mail that would cause 
that. I have CSCsy28792, CSCsi01498, and CSCsh33982 bugs in my notes on that.

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

Re: [mailop] Cisco PIX Mailguard Oddity

[Jim Cheetham]

Common "feature". Cisco devices by default allow only SMTP, not ESMTP.
These defaults keep coming back to bite admins, year after year after
year.

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113423-asa-esmtp-smtp-inspection.html
provides one example of how to switch off their policy, you need to check
for the product that you're actually using.

-jim

Excerpts from Todd Herr's message of 2016-05-06 12:08:40 +1200:
> Forgive me if this is off topic, but I don't know where else to turn.
> 
> I've got a customer who's having trouble sending mail to two domains with
> nothing obvious (to me) in common save for one thing; both domain's primary
> MXen look to be sitting behind Cisco PIX devices with Mailguard turned on.
> I know this because of the greeting I get from both:
> 
> 220 ***
> 
> Now, everything I can find about these devices says that they only allow
> seven SMTP commands:​
> 
> ​HELO, ​
> MAIL
> ​, ​
> RCPT
> ​, ​
> DATA
> ​, ​
> RSET
> ​, ​
> NOOP
> ​, ​
> QUIT
> ​
> 
> 
> And they're supposed to respond with OK to everything else. These two
> domains, again not obviously related, mail servers in different /8s, don't
> even do that, though; both of them are responding in
> ​ unsuspected ways even to commands from the above list, to wit:
> 
> RSET
> 500 Syntax error, command unrecognized
> QUIT
> 500 Syntax error, command unrecognized
> ​
> 
> ​I've never wrangled one of these beasts (haven't even *seen* evidence of
> one in many years) so I'd like to ask you fine folks if you've ever seen
> anything like this​ from one of these, and what it means for their
> configuration? I mean, is this a common bug/misconfiguration, or have I
> just hit the lottery?
> 
> Thanks.
> 

-- 
Jim Cheetham, Information Security, University of Otago, Dunedin, N.Z.
✉ jim.cheet...@otago.ac.nz☏ +64 3 470 4670☏ m +64 21 279 4670
⚷ OpenPGP: B50F BE3B D49B 3A8A 9CC3 8966 9374 82CD C982 0605


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

[mailop] Cisco PIX Mailguard Oddity

[Todd Herr]

Forgive me if this is off topic, but I don't know where else to turn.

I've got a customer who's having trouble sending mail to two domains with
nothing obvious (to me) in common save for one thing; both domain's primary
MXen look to be sitting behind Cisco PIX devices with Mailguard turned on.
I know this because of the greeting I get from both:

220 ***

Now, everything I can find about these devices says that they only allow
seven SMTP commands:​

​HELO, ​
MAIL
​, ​
RCPT
​, ​
DATA
​, ​
RSET
​, ​
NOOP
​, ​
QUIT
​


And they're supposed to respond with OK to everything else. These two
domains, again not obviously related, mail servers in different /8s, don't
even do that, though; both of them are responding in
​ unsuspected ways even to commands from the above list, to wit:

RSET
500 Syntax error, command unrecognized
QUIT
500 Syntax error, command unrecognized
​

​I've never wrangled one of these beasts (haven't even *seen* evidence of
one in many years) so I'd like to ask you fine folks if you've ever seen
anything like this​ from one of these, and what it means for their
configuration? I mean, is this a common bug/misconfiguration, or have I
just hit the lottery?

Thanks.

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

[mailop] Anyone from AOL on this list?

[Josh Nason]

Hi all -- we have some AOL caching questions and are curious if someone
from there is on this list.

If so, I'd love to hear from you. Thanks!

-- 

[image: Dyn logo, Dyn.com] 
[image: Dyn facebook
account] [image:
Dyn LinkedIn account] 

Josh Nason / Email Reputation Manager
 +1 603-289-1244 | @JoshNason 

Email is hot! This is why

it's the original form of social media.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DNS Errors for Microsoft Hostnames

[Michael Wise]

And we don't do EDNS, so it seems, from the guys I've spoken to ... That we 
don't, and some diagnostic tools are making assumptions that they perhaps 
shouldn't.

I can't say.
I don't know.
The people whose eyes I have put this in front of assert we're acting according 
to the RFC.

They're getting tired of my pestering.

Aloha,
Michael.
--
Sent from my Windows Phone

From: Franck Martin
Sent: ‎5/‎5/‎2016 11:37 AM
To: Michael Wise
Cc: Rob Heilman; 
mailop@mailop.org
Subject: Re: [mailop] DNS Errors for Microsoft Hostnames

I use this tool because it checks everything DNS (including DNSSEC) and makes a 
pretty graph. The two errors are not related to DNSSEC, so seems you have 
something to fix ;)

On Wed, May 4, 2016 at 5:03 PM, Michael Wise 
> wrote:

Microsoft officially doesn’t do DNSSEC.
(or at least not now anyway)

Aloha,
Michael.
--
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting 
Tool ?

From: Franck Martin [mailto:fmar...@linkedin.com]
Sent: Wednesday, May 4, 2016 4:20 PM
To: Rob Heilman >
Cc: Michael Wise 
>; 
mailop@mailop.org

Subject: Re: [mailop] DNS Errors for Microsoft Hostnames

I like to use this tool to tell me everything...

I used it on the first domain, told me there are 2 errors:
http://dnsviz.net/d/alleghenycourts-us.mail.protection.outlook.com/dnssec/

On Wed, May 4, 2016 at 8:45 AM, Rob Heilman 
> wrote:
Got a fresh batch of DNS failures in the logs.  Below is a sampling.  From the 
BIND source code resolver.c:

} else if (result != ISC_R_SUCCESS) {
/*
 * Something bad happened.
 */
fctx_done(fctx, result, __LINE__);
return;
}

Has anyone seen this before or know what might be happening?  If not I will try 
to escalate to ISC to see if they can help diagnose.

-Rob Heilman

04-May-2016 09:46:22.236 query-errors: debug 1: client 10.10.10.95#44080 
(alleghenycourts-us.mail.protection.outlook.com):
 query failed (SERVFAIL) for 
alleghenycourts-us.mail.protection.outlook.com/IN/A
 at query.c:7004
04-May-2016 09:46:22.236 query-errors: debug 1: client 10.10.10.95#44080 
(courts-phila-gov.mail.protection.outlook.com):
 query failed (SERVFAIL) for 
courts-phila-gov.mail.protection.outlook.com/IN/A
 at query.c:7004
04-May-2016 09:46:22.236 query-errors: debug 2: fetch completed at 
resolver.c:3074 for 
alleghenycourts-us.mail.protection.outlook.com/A
 in 0.000122: failure/success 
[domain:mail.protection.outlook.com,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
04-May-2016 09:46:22.236 query-errors: debug 2: fetch completed at 
resolver.c:3074 for 
courts-phila-gov.mail.protection.outlook.com/A
 in 0.000272: failure/success 
[domain:mail.protection.outlook.com,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
04-May-2016 09:46:49.389 query-errors: debug 1: client 10.10.10.96#48950 
(petersoncpa-com02b.mail.protection.outlook.com):
 query failed (SERVFAIL) for 
petersoncpa-com02b.mail.protection.outlook.com/IN/A
 at query.c:7004
04-May-2016 09:46:49.389 query-errors: debug 2: fetch completed at 
resolver.c:3074 for 
petersoncpa-com02b.mail.protection.outlook.com/A
 in 0.78: failure/success 
[domain:mail.protection.outlook.com,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
04-May-2016 09:47:22.030 query-errors: debug 1: client 10.10.10.96#48950 
(supervaluinc.mail.protection.outlook.com):
 query failed (SERVFAIL) for 
supervaluinc.mail.protection.outlook.com/IN/A
 at query.c:7004
04-May-2016 09:47:22.030 query-errors: debug 

Re: [mailop] DNS Errors for Microsoft Hostnames

[Franck Martin via mailop]

This page, provides a way to test EDNS:
https://www.dns-oarc.net/oarc/services/replysizetest

Bind acts this way.

Makes an EDNS query of full size, if no answer, makes a DNS query and
request the response to be limited to a 512bytes answer, there it usually
will get an answer, that the result is too big to fit in such UDP packet
therefore, bind finally makes the query over TCP and gets the result needed.

With low TTL, overloaded TXT records, it is not rare that the mail server
does not get the SPF record in time for a non null but significant portion
of emails from a domain.

UDP fragments are not a security issue, they are essential for DNS.

On Thu, May 5, 2016 at 3:29 AM, Tony Finch  wrote:

> Michael Wise  wrote:
> >
> > So is the FORMERR ... just the resolver noting that EDNS is not
> supported?
> >
> > If so, I'm uncertain of the issue.
>
> There has been some discussion of this problem on the bind-users list, see
> https://lists.isc.org/pipermail/bind-users/2016-May/thread.html
>
> The problems seem to be:
>
> (1) Very short TTL on the NS records, which means that most attempts to
> resolve the names have to go through iterative name server discovery.
>
> (2) Only two NS records, but each server has a large number of IP
> addresses, and the sets of IP addresses overlap.
>
> (3) Lack of EDNS support means more work has to be done by a resolver each
> time the TTL expires.
>
> The way to fix this would be to increase the stability of the name server
> records - the NS records and associated address records. Give them
> decently long TTLs, have a few more NS records, with few non-overlapping
> IP addresses each.
>
> Add support for EDNS to your server - you don't need to support any
> special EDNS features (no need for large packets), just handle OPT
> records, so that resolvers don't have to do error recovery.
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Irish Sea: South 4 or 5 becoming variable 3 or 4. Slight or moderate.
> Occasional drizzle, fog patches in north. Moderate or good, occasionally
> very
> poor in north.
>
> ___
> 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] DNS Errors for Microsoft Hostnames

[Franck Martin via mailop]

I use this tool because it checks everything DNS (including DNSSEC) and
makes a pretty graph. The two errors are not related to DNSSEC, so seems
you have something to fix ;)

On Wed, May 4, 2016 at 5:03 PM, Michael Wise 
wrote:

>
>
> Microsoft officially doesn’t do DNSSEC.
> (or at least not now anyway)
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* Franck Martin [mailto:fmar...@linkedin.com]
> *Sent:* Wednesday, May 4, 2016 4:20 PM
> *To:* Rob Heilman 
> *Cc:* Michael Wise ; mailop@mailop.org
>
> *Subject:* Re: [mailop] DNS Errors for Microsoft Hostnames
>
>
>
> I like to use this tool to tell me everything...
>
>
>
> I used it on the first domain, told me there are 2 errors:
>
> http://dnsviz.net/d/alleghenycourts-us.mail.protection.outlook.com/dnssec/
>
>
>
> On Wed, May 4, 2016 at 8:45 AM, Rob Heilman  wrote:
>
> Got a fresh batch of DNS failures in the logs.  Below is a sampling.  From
> the BIND source code resolver.c:
>
>
>
> } else if (result != ISC_R_SUCCESS) {
> /*
>  * Something bad happened.
>  */
> fctx_done(fctx, result, __LINE__);
> return;
> }
>
>
>
> Has anyone seen this before or know what might be happening?  If not I
> will try to escalate to ISC to see if they can help diagnose.
>
>
>
> -Rob Heilman
>
>
>
> 04-May-2016 09:46:22.236 query-errors: debug 1: client 10.10.10.95#44080 (
> alleghenycourts-us.mail.protection.outlook.com): query failed (SERVFAIL)
> for alleghenycourts-us.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:46:22.236 query-errors: debug 1: client 10.10.10.95#44080 (
> courts-phila-gov.mail.protection.outlook.com): query failed (SERVFAIL)
> for courts-phila-gov.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:46:22.236 query-errors: debug 2: fetch completed at
> resolver.c:3074 for alleghenycourts-us.mail.protection.outlook.com/A
> in 0.000122: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:46:22.236 query-errors: debug 2: fetch completed at
> resolver.c:3074 for courts-phila-gov.mail.protection.outlook.com/A
> in 0.000272: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:46:49.389 query-errors: debug 1: client 10.10.10.96#48950 (
> petersoncpa-com02b.mail.protection.outlook.com): query failed (SERVFAIL)
> for petersoncpa-com02b.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:46:49.389 query-errors: debug 2: fetch completed at
> resolver.c:3074 for petersoncpa-com02b.mail.protection.outlook.com/A
> in 0.78: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:22.030 query-errors: debug 1: client 10.10.10.96#48950 (
> supervaluinc.mail.protection.outlook.com): query failed (SERVFAIL) for
> supervaluinc.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:22.030 query-errors: debug 2: fetch completed at
> resolver.c:3074 for supervaluinc.mail.protection.outlook.com/A in
> 0.84: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:25.817 query-errors: debug 1: client 10.10.10.96#48950 (
> casella-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> casella-com.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:25.817 query-errors: debug 2: fetch completed at
> resolver.c:3074 for casella-com.mail.protection.outlook.com/A in
> 0.92: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:26.792 query-errors: debug 1: client 10.10.10.95#44080 (
> ghscoslaw-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> ghscoslaw-com.mail.protection.outlook.com/IN/A at query.c:7004
> 04-May-2016 09:47:26.792 query-errors: debug 2: fetch completed at
> resolver.c:3074 for ghscoslaw-com.mail.protection.outlook.com/A in
> 0.93: failure/success [domain:mail.protection.outlook.com
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> 04-May-2016 09:47:27.855 query-errors: debug 1: client 10.10.10.95#44080 (
> casella-com.mail.protection.outlook.com): query failed (SERVFAIL) for
> 

[mailop] amazon vs starttls

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

relay=amazon-smtp.amazon.com. [207.171.189.228], dsn=4.0.0,
stat=Deferred: 421 #4.4.5 Too many TLS sessions at this time

So amazon accepts the inbound port 25 connection, advertises starttls in
response to ehlo, and then complains when we try to use tls. What, you
don't have enough cpu power to run tls on all your inbound connections,
even with your amazon cloud?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlcrjWsACgkQL6j7milTFsFTMACdGJ7qUJYOjVybvKigWi+Tj9jd
WDYAn3iNcafYvD9ffr9oz8HKwhgUMeTQ
=4zDM
-END PGP SIGNATURE-



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

Re: [mailop] DNS Errors for Microsoft Hostnames

[Michael Wise]

" All this is stating is that DNS++ does not support RFC 2671 EDNS protocol 
extensions.  
" DNS++ is responding per the RFC by sending the FORMERR back to the requestor. 
 

We don't support *ANY* EDNS features at present, at all.
That would appear to include the ... OPT records?

As to the, "Why?" I don't know. There appear to be internal load balancing 
issues in play, but that's a guess.
Not my department at all.

Aloha,
Michael.
-- 
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting Tool ?

-Original Message-
From: Tony Finch [mailto:fa...@hermes.cam.ac.uk] On Behalf Of Tony Finch
Sent: Thursday, May 5, 2016 3:29 AM
To: Michael Wise 
Cc: mailop@mailop.org
Subject: Re: [mailop] DNS Errors for Microsoft Hostnames

Michael Wise  wrote:
>
> So is the FORMERR ... just the resolver noting that EDNS is not supported?
>
> If so, I'm uncertain of the issue.

There has been some discussion of this problem on the bind-users list, see 
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.isc.org%2fpipermail%2fbind-users%2f2016-May%2fthread.html=01%7c01%7cMichael.Wise%40microsoft.com%7cc8be6a025d804f03da5c08d374d019f9%7c72f988bf86f141af91ab2d7cd011db47%7c1=9g%2bvN%2bth9lLTwzURPBBuCZugYPu5D1zCjVGAORY2GzE%3d

The problems seem to be:

(1) Very short TTL on the NS records, which means that most attempts to resolve 
the names have to go through iterative name server discovery.

(2) Only two NS records, but each server has a large number of IP addresses, 
and the sets of IP addresses overlap.

(3) Lack of EDNS support means more work has to be done by a resolver each time 
the TTL expires.

The way to fix this would be to increase the stability of the name server 
records - the NS records and associated address records. Give them decently 
long TTLs, have a few more NS records, with few non-overlapping IP addresses 
each.

Add support for EDNS to your server - you don't need to support any special 
EDNS features (no need for large packets), just handle OPT records, so that 
resolvers don't have to do error recovery.

Tony.
--
f.anthony.n.finch    
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdotat.at%2f=01%7c01%7cMichael.Wise%40microsoft.com%7cc8be6a025d804f03da5c08d374d019f9%7c72f988bf86f141af91ab2d7cd011db47%7c1=9fMp8vbpmPGSBeK67zHvf5CVxooK%2f%2fi%2bywkAMco1A1Y%3d
  -  I xn--zr8h punycode Irish Sea: South 4 or 5 becoming variable 3 or 4. 
Slight or moderate.
Occasional drizzle, fog patches in north. Moderate or good, occasionally very 
poor in north.

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

Re: [mailop] Microsoft POP3 Troubles

[Michael Peddemors]

Generally an increase in POP is only related to two things:

* Email Client has short time out's and long query times.

Seems some* email clients will attempt to download messages, but if the 
re-query time comes around, it will terminate the first connection and 
then restart from the beginning.


* Unique identifier related to the message keeps changing.

The email client trusts that the server ID for the message is correct, 
so if it changes, the email client will consider this as new.


This occurs usually when migrating data stores.



On 16-05-05 06:40 AM, Joseph B wrote:

I was reviewing my flow records and I can see in the last 24h we have
started doing a much larger amount of POP3 traffic to Microsoft than
usual. As an example, some of the IP's that are making the POP3
connections are:


Yes, we started seeing these logins from around April 18th.

Some users have gone from 5MB a day of POP traffic to 25GB per day :-\

May  5 17:31:52 server dovecot: pop3-login: Login:
user=, method=PLAIN, rip=40.100.16.125,
lip=45.xx.xx.xx, mpid=294947, session=<7VRKwRMytG4oZBB9>
May  5 17:31:52 server dovecot: pop3(u...@domain.com): Disconnected:
Logged out top=0/0, retr=0/0, del=0/512, size=223773360, bytes=24/12306

May  5 17:32:17 server dovecot: pop3-login: Login:
user=, method=PLAIN, rip=40.100.16.125,
lip=45.xx.xx.xx, mpid=295053, session=
May  5 17:40:34 server dovecot: pop3(u...@domain.com): Disconnected:
Logged out top=2/3772, retr=1024/447566492, del=0/512, size=223773360,
bytes=10074/447591247

Cheers,

Joseph


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





--
"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] Microsoft POP3 Troubles

[Joseph B]

> I was reviewing my flow records and I can see in the last 24h we have 
> started doing a much larger amount of POP3 traffic to Microsoft than 
> usual. As an example, some of the IP's that are making the POP3 
> connections are:

Yes, we started seeing these logins from around April 18th.

Some users have gone from 5MB a day of POP traffic to 25GB per day :-\

May  5 17:31:52 server dovecot: pop3-login: Login:
user=, method=PLAIN, rip=40.100.16.125,
lip=45.xx.xx.xx, mpid=294947, session=<7VRKwRMytG4oZBB9>
May  5 17:31:52 server dovecot: pop3(u...@domain.com): Disconnected:
Logged out top=0/0, retr=0/0, del=0/512, size=223773360, bytes=24/12306

May  5 17:32:17 server dovecot: pop3-login: Login:
user=, method=PLAIN, rip=40.100.16.125,
lip=45.xx.xx.xx, mpid=295053, session=
May  5 17:40:34 server dovecot: pop3(u...@domain.com): Disconnected:
Logged out top=2/3772, retr=1024/447566492, del=0/512, size=223773360,
bytes=10074/447591247

Cheers,

Joseph


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

Re: [mailop] DNS Errors for Microsoft Hostnames

[Tony Finch]

Michael Wise  wrote:
>
> So is the FORMERR ... just the resolver noting that EDNS is not supported?
>
> If so, I'm uncertain of the issue.

There has been some discussion of this problem on the bind-users list, see
https://lists.isc.org/pipermail/bind-users/2016-May/thread.html

The problems seem to be:

(1) Very short TTL on the NS records, which means that most attempts to
resolve the names have to go through iterative name server discovery.

(2) Only two NS records, but each server has a large number of IP
addresses, and the sets of IP addresses overlap.

(3) Lack of EDNS support means more work has to be done by a resolver each
time the TTL expires.

The way to fix this would be to increase the stability of the name server
records - the NS records and associated address records. Give them
decently long TTLs, have a few more NS records, with few non-overlapping
IP addresses each.

Add support for EDNS to your server - you don't need to support any
special EDNS features (no need for large packets), just handle OPT
records, so that resolvers don't have to do error recovery.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: South 4 or 5 becoming variable 3 or 4. Slight or moderate.
Occasional drizzle, fog patches in north. Moderate or good, occasionally very
poor in north.

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

Re: [mailop] Microsoft POP3 Troubles

[Michael Wise]

I don't know who would be responsible for this, but will ask around in the 
morning. 3am here currently. :(

Aloha,
Michael.
--
Sent from my Windows Phone

From: Chris via mailop
Sent: ‎5/‎5/‎2016 2:37 AM
To: mailop@mailop.org
Subject: Re: [mailop] Microsoft POP3 Troubles


On 05/05/2016 5:16 PM, Michael Wise wrote:

But by virtue of the, "admin" I'd want whomever owns that domain to be advised?

It might be some Dev doing something with their own mailbox, or ... I have no 
idea, sorry.

Hi Michael,

The issue is its not just this one particular mailbox, this just happened to 
the first one I checked. This is happening for about 15 different domains we 
host, all with different mailboxes and they are all different customers. The 
issue started happening about the same time (+- 30 minutes from each other) on 
all of them as well - I don't think this is anything to do with what the 
customers have setup. I have tried contacting a couple of the customers but 
they have no clue what they have setup, they will check in with their tech to 
see.

It's not really a big problem it just appears to be wasting a fair bit of 
bandwidth, it would be nice if it stopped though. The other option I have is 
firewalling these off and see what breaks but that's a last resort...

As we are not a MS customer, is there any way I can get in contact with someone 
at MS who would be able to follow this up?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft POP3 Troubles

[Michael Wise]

You'd think some rDNS, but...
It's not Azure.

I have no idea, sorry.

But by virtue of the, "admin" I'd want whomever owns that domain to be advised?

It might be some Dev doing something with their own mailbox, or ... I have no 
idea, sorry.

Aloha,
Michael.
--
Sent from my Windows Phone

From: Chris via mailop
Sent: ‎5/‎4/‎2016 10:53 PM
To: mailop@mailop.org
Subject: [mailop] Microsoft POP3 Troubles

Hi all,

Not sure if this is the right list to post this to.

I was reviewing my flow records and I can see in the last 24h we have
started doing a much larger amount of POP3 traffic to Microsoft than
usual. As an example, some of the IP's that are making the POP3
connections are:

40.96.25.117
40.100.0.132
40.100.1.237
40.96.18.165
40.96.47.101
40.96.2.53
40.96.15.165
40.100.2.29

I have reviewed the mail server logs on my end and found that it looks
like these IP's are grabbing complete copies of the same mailbox over
and over again. I have put an example of the pop3 logs from dovecot
below from one of our servers which show the repeated downloads. For
this particular domain the user has 1.7GB of emails total in all
mailboxes but I can see in the last 24H Microsoft has downloaded the
mailbox multiple times totalling over 180GB...

I am not exactly sure what on the MS end these IP's belong to and I am
not sure what the customers have setup, I am waiting to hear back from a
few. This is happening across a bunch of different servers on different
mailboxes.

I would be interested to hear if anyone else has experienced this
recently, it appears to still be happening now.

May  5 04:31:36 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=2/2831, retr=2204/957869252, del=0/1102, size=478908339,
bytes=22081/957917270
May  5 04:56:21 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=442,
session=<4FwzdQoylAkoYBKl>
May  5 04:56:21 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=0/0, retr=0/0, del=0/1102, size=478908339, bytes=24/25908
May  5 04:56:25 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=475,
session=
May  5 05:03:29 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=2/2831, retr=2204/957869252, del=0/1102, size=478908339,
bytes=22081/957917270
May  5 05:20:03 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=37159,
session=
May  5 05:20:03 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=0/0, retr=0/0, del=0/1102, size=478908339, bytes=24/25908
May  5 05:20:06 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=37344,
session=
May  5 05:25:53 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=2/2831, retr=2204/957869252, del=0/1102, size=478908339,
bytes=22081/957917270
May  5 05:47:11 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=89853,
session=
May  5 05:47:12 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=0/0, retr=0/0, del=0/1102, size=478908339, bytes=24/25908
May  5 05:47:15 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=89886,
session=
May  5 05:54:00 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=2/2831, retr=2204/957869252, del=0/1102, size=478908339,
bytes=22081/957917270
May  5 06:16:53 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=127954,
session=
May  5 06:16:54 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=0/0, retr=0/0, del=0/1102, size=478908339, bytes=24/25908
May  5 06:16:58 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=128036,
session=
May  5 06:22:31 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=2/2831, retr=2204/957869252, del=0/1102, size=478908339,
bytes=22081/957917270
May  5 06:51:20 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=170010,
session=
May  5 06:51:20 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=0/0, retr=0/0, del=0/1102, size=478908339, bytes=24/25908
May  5 06:51:29 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=170137,
session=
May  5 06:58:51 server47 dovecot: pop3(admin@X): Disconnected:
Logged out top=2/2831, retr=2204/957869252, del=0/1102, size=478908339,
bytes=22081/957917270
May  5 07:24:25 server47 dovecot: pop3-login: Login: user=,
method=PLAIN, rip=40.96.18.165, lip=27.124.XXX.XX, mpid=211166,
session=
May  5 07:24:25