Feedback on Postscreen Whitelist Article

Steve Jenkins

unread,

Nov 23, 2015, 2:42:44 PM11/23/15

to

I just posted an article about how to whitelist Gmail and Hotmail/Outlook.com IP addresses for Postscreen, based on the webmaster's SPF records:

http://www.stevejenkins.com/blog/2015/11/postscreen-whitelisting-smtp-outbound-ip-addresses-large-webmail-providers/

I'd appreciate feedback from anyone on this list generous enough to offer it, so I can fix any mistakes or make the article better.

Thanks,

Steve

Steve Jenkins

st...@stevejenkins.com

Noel Jones

unread,

Nov 23, 2015, 4:04:16 PM11/23/15

to

On 11/23/2015 1:42 PM, Steve Jenkins wrote:
> I just posted an article about how to whitelist Gmail and
> Hotmail/Outlook.com IP addresses for Postscreen, based on the
> webmaster's SPF records:
>
> http://www.stevejenkins.com/blog/2015/11/postscreen-whitelisting-smtp-outbound-ip-addresses-large-webmail-providers/
>
> I'd appreciate feedback from anyone on this list generous enough to
> offer it, so I can fix any mistakes or make the article better.
>
> Thanks,
>
> Steve
>
>

> *Steve Jenkins*
> /st...@stevejenkins.com <mailto:st...@stevejenkins.com>/
>
> <http://t.sidekickopen29.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4S9MSCW3LPWyM3LjCtjVQZcFT56dvXWf7fnxkP02?t=http%3A%2F%2Fwww.stevejenkins.com%2F&si=4870762816077824&pi=a7bba61c-d5ff-4f17-ffdb-d2d16b1f8221> <http://t.sidekickopen29.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4S9MSCW3LPWyM3LjCtjVQZcFT56dvXWf7fnxkP02?t=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fsjjenkins&si=4870762816077824&pi=a7bba61c-d5ff-4f17-ffdb-d2d16b1f8221> <http://t.sidekickopen29.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4S9MSCW3LPWyM3LjCtjVQZcFT56dvXWf7fnxkP02?t=https%3A%2F%2Ftwitter.com%2Fsjjenkins%2F&si=4870762816077824&pi=a7bba61c-d5ff-4f17-ffdb-d2d16b1f8221> <https://www.facebook.com/SteveJenkinsBiz> <http://t.sidekickopen29.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4S9MSCW3LPWyM3LjCtjVQZcFT56dvXWf7fnxkP02?t=https%3A%2F%2Fplus.google.com%2F%2BSteveJenkins&si=4870762816077824&pi=a7bba61c-d5ff-4f17-ffdb-d2d16b1f8221> <http://t.sidekickopen29.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0
x6l2B9n
MJN7t5XX4S9MSCW3LPWyM3LjCtjVQZcFT56dvXWf7fnxkP02?t=https%3A%2F%2Fwww.youtube.com%2Fuser%2FFerrariSteveJenkins&si=4870762816077824&pi=a7bba61c-d5ff-4f17-ffdb-d2d16b1f8221> <http://t.sidekickopen29.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4S9MSCW3LPWyM3LjCtjVQZcFT56dvXWf7fnxkP02?t=https%3A%2F%2Finstagram.com%2Fferraristeve%2F&si=4870762816077824&pi=a7bba61c-d5ff-4f17-ffdb-d2d16b1f8221>

Maintaining a local postscreen whitelist of well-known providers is
largely obsolete.

http://www.postfix.org/postconf.5.html#postscreen_dnsbl_whitelist_threshold
http://www.postfix.org/postconf.5.html#postscreen_dnsbl_sites

a minimal main.cf example would be something like:
postscreen_dnsbl_sites = zen.spamhaus.org*1 list.dnswl.org*-1
postscreen_dnsbl_whitelist_threshold = -1

-- Noel Jones

rob...@chalmers.com.au

unread,

Nov 23, 2015, 4:48:43 PM11/23/15

to

Interesting article Steve. What happens when/if they change ip blocks in between cron runs?

and I can't help thinking this may be a little redundant though, with spf, dkim and dmarc in place the source of the email is checked and acted upon accordingly.

Sent from my iPad

On 23 Nov 2015, at 7:42 p.m., Steve Jenkins <st...@stevejenkins.com> wrote:

I just posted an article about how to whitelist Gmail and Hotmail/Outlook.com IP addresses for Postscreen, based on the webmaster's SPF records:

http://www.stevejenkins.com/blog/2015/11/postscreen-whitelisting-smtp-outbound-ip-addresses-large-webmail-providers/

I'd appreciate feedback from anyone on this list generous enough to offer it, so I can fix any mistakes or make the article better.

Thanks,

Steve

Noel Jones

unread,

Nov 23, 2015, 4:55:05 PM11/23/15

to

On 11/23/2015 3:48 PM, rob...@chalmers.com.au wrote:
> Interesting article Steve. What happens when/if they change ip
> blocks in between cron runs?
> and I can't help thinking this may be a little redundant though,
> with spf, dkim and dmarc in place the source of the email is checked
> and acted upon accordingly.
>
>

spf, dkim, dmarc, etc. don't work at the postscreen level. The only
information that is known at this point is the connecting client IP.

That's why postscreen_dnsbl_whitelist_threshold is useful here.

-- Noel Jones

>
>
> Sent from my iPad
>
> On 23 Nov 2015, at 7:42 p.m., Steve Jenkins <st...@stevejenkins.com

> <mailto:st...@stevejenkins.com>> wrote:
>
>> I just posted an article about how to whitelist Gmail and

>> Hotmail/Outlook.com <http://outlook.com> IP addresses for

>> Postscreen, based on the webmaster's SPF records:
>>
>> http://www.stevejenkins.com/blog/2015/11/postscreen-whitelisting-smtp-outbound-ip-addresses-large-webmail-providers/
>>
>> I'd appreciate feedback from anyone on this list generous enough
>> to offer it, so I can fix any mistakes or make the article better.
>>
>> Thanks,
>>
>> Steve
>>
>>

yahoo...@lazygranch.xyz

unread,

Nov 23, 2015, 5:30:07 PM11/23/15

to

‎Regarding Spamhaus, I am periodically blacklisted on my hosted Web service provider because somebody ‎sets up an account on the same service, then spews spam. Because I share the same IP, I'm declared toxic.

I have set up a VPS, which of course has its own IP, not to get in this boat. But I am so negative regarding Spamhaus due to unwarranted blocking that I refuse to use it.
‎

Viktor Dukhovni

unread,

Nov 23, 2015, 5:44:59 PM11/23/15

to

On Mon, Nov 23, 2015 at 02:29:45PM -0800, yahoo...@lazygranch.xyz wrote:

>�Regarding Spamhaus, I am periodically blacklisted on my hosted Web service

> provider because somebody �sets up an account on the same service, then
> spews spam. Because I share the same IP, I'm declared toxic.

Sounds like the listing is entirely appropriate... You might want
hosting from a provider that does a better job of controlling
outbound spam.

--
Viktor.

yahoo...@lazygranch.xyz

unread,

Nov 23, 2015, 5:59:41 PM11/23/15

to

‎If wishes were horses. ;-)

My xyz domain is on the VPS. I'm going to switch systems in a few days.
Original Message
From: Viktor Dukhovni
Sent: Monday, November 23, 2015 2:45 PM
To: postfi...@postfix.org
Reply To: postfi...@postfix.org
Subject: Re: Feedback on Postscreen Whitelist Article

Steve Jenkins

unread,

Nov 23, 2015, 6:50:42 PM11/23/15

to

On Mon, Nov 23, 2015 at 1:03 PM, Noel Jones <njo...@megan.vbhcs.org> wrote:

Maintaining a local postscreen whitelist of well-known providers is
largely obsolete.

http://www.postfix.org/postconf.5.html#postscreen_dnsbl_whitelist_threshold
http://www.postfix.org/postconf.5.html#postscreen_dnsbl_sites

a minimal main.cf example would be something like:
postscreen_dnsbl_sites = zen.spamhaus.org*1 list.dnswl.org*-1
postscreen_dnsbl_whitelist_threshold = -1

Hi, Noel. Thanks for your input (it's always appreciated).

I do use both of those directives in my main.cf, after the postscreen_access_list.

Here's what I'm currently running:

# POSTSCREEN OPTIONS v2015-06-02

postscreen_access_list = permit_mynetworks,

cidr:/etc/postfix/postscreen_access.cidr,

cidr:/etc/postfix/gmail_whitelist.cidr,

cidr:/etc/postfix/msft_whitelist.cidr,

hash:/etc/postfix/postscreen_whitelist

postscreen_blacklist_action = drop

postscreen_dnsbl_action = enforce

postscreen_greet_action = enforce

postscreen_dnsbl_threshold = 3

postscreen_dnsbl_whitelist_threshold = -4

postscreen_dnsbl_sites =

zen.spamhaus.org*3

bl.mailspike.net*2

b.barracudacentral.org*2

bl.spameatingmonkey.net

bl.spamcop.net

dnsbl.sorbs.net

psbl.surriel.com

swl.spamhaus.org*-4

list.dnswl.org=127.[0..255].[0..255].0*-2

list.dnswl.org=127.[0..255].[0..255].1*-3

list.dnswl.org=127.[0..255].[0..255].[2..255]*-4

wl.mailspike.net=127.0.0.[17;18]*-1

wl.mailspike.net=127.0.0.[19;20]*-2

Steve Jenkins

unread,

Nov 23, 2015, 6:54:54 PM11/23/15

to

On Mon, Nov 23, 2015 at 1:48 PM, rob...@chalmers.com.au <rob...@chalmers.com.au> wrote:

Interesting article Steve. What happens when/if they change ip blocks in between cron runs?
and I can't help thinking this may be a little redundant though, with spf, dkim and dmarc in place the source of the email is checked and acted upon accordingly.

Hi, Robert. As Noel pointed out, this all occurs way before SPF, DKIM, and/or DMARC come into play.

As for what happens if they IP blocks change between cron runs, a spammer would have to take control of an old Google or Microsoft netblock in order to increase any risk, which is unlikely.

And since this is a whitelist, any new IPs that haven't been picked up in the no more than 7 days since the last query would be evaluated by Postscreen per normal... and would likely still get through.

Robert Chalmers

unread,

Nov 24, 2015, 5:57:52 AM11/24/15

to

Hi Steve,

I implemented the idea, and it works treat. I’m on OSX 10.11, and apart from a few directory changes, (and my bad spelling) - no problems.

Interesting idea and an excellent script.

Thanks for the work. I understand now what it’s doing.

Robert

Robert Chalmers

rob...@chalmers.com.au Quantum Radio: http://tinyurl.com/lwwddov

Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11. 2TB Storage made up of -

Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. Lower Bay

proto

unread,

Nov 24, 2015, 1:33:19 PM11/24/15

to

Thank you Steve.
I did something similar some weeks ago because I had to get in contact
with MS Support urgently.

I remember I had to get outbound gateways IPs from
<spf.protection.outlook.com>, but I didn't use <ns1.msft.net>. Actually
in your script this NS return no SPF records (IP and includes).

I think this WL could be completed with records from:

spfa.protection.outlook.com
spfb.protection.outlook.com

a.

Il 23/11/15 20:42, Steve Jenkins ha scritto:

> I just posted an article about how to whitelist Gmail and

> Hotmail/Outlook.com IP addresses for Postscreen, based on the

Steve Jenkins

unread,

Nov 24, 2015, 10:45:38 PM11/24/15

to

On Tue, Nov 24, 2015 at 10:32 AM, proto <aless...@protodigital.net> wrote:

Thank you Steve.
I did something similar some weeks ago because I had to get in contact with MS Support urgently.

I remember I had to get outbound gateways IPs from <spf.protection.outlook.com>, but I didn't use <ns1.msft.net>. Actually in your script this NS return no SPF records (IP and includes).

I think this WL could be completed with records from:

spfa.protection.outlook.com
spfb.protection.outlook.com

a.

Alessandro:

I've updated the script to also query spf.protection.outlook.com, spfa.protection.outlook.com, and spfb.protection.outlook.com:

https://gist.github.com/stevejenkins/b8898f3632561f9999f4

My scripting and sed skills are NOT that strong, so I'm certain there are many more elegant ways to do that I'm trying to do... including better automation of parsing through the original SPF record and figuring out the right thing to do. But whatever it's worth, the script now grabs more IPs from Microsoft.

I also think it's crazy that MSFT's primary name server's aren't updated, so that I have to use two different nameservers in the script.

I've half a mind just to query Google's 8.8.8.8 nameserver for the correct MS values... because it got them all right in my tests. LOL

SJ

ale@proto

unread,

Nov 25, 2015, 7:13:29 AM11/25/15

to

I thinks it's a good starting point, Steve.
And it's much better than doing it manually as I did :-)

Anyway... I rapidly tested delivery time from my office365 account:
- WL disabled: 15 hours
- WL enabled: just a few minutes

postgrey enabled.

Thanks!
a.

Il 25/11/15 04:45, Steve Jenkins ha scritto:

> On Tue, Nov 24, 2015 at 10:32 AM, proto <aless...@protodigital.net
> <mailto:aless...@protodigital.net>> wrote:
>
> Thank you Steve.
> I did something similar some weeks ago because I had to get in
> contact with MS Support urgently.
>
> I remember I had to get outbound gateways IPs from

> <spf.protection.outlook.com <http://spf.protection.outlook.com>>,
> but I didn't use <ns1.msft.net <http://ns1.msft.net>>. Actually in

> your script this NS return no SPF records (IP and includes).
>
> I think this WL could be completed with records from:
>

> spfa.protection.outlook.com <http://spfa.protection.outlook.com>
> spfb.protection.outlook.com <http://spfb.protection.outlook.com>

>
> a.
>
>
> Alessandro:
>
> I've updated the script to also query spf.protection.outlook.com

> <http://spf.protection.outlook.com>, spfa.protection.outlook.com
> <http://spfa.protection.outlook.com>, and spfb.protection.outlook.com
> <http://spfb.protection.outlook.com>:

Steve Jenkins

unread,

Nov 25, 2015, 12:19:28 PM11/25/15

to

On Wed, Nov 25, 2015 at 4:13 AM, ale@proto <aless...@protodigital.net> wrote:

I thinks it's a good starting point, Steve.
And it's much better than doing it manually as I did :-)

Anyway... I rapidly tested delivery time from my office365 account:
- WL disabled: 15 hours
- WL enabled: just a few minutes

postgrey enabled.

Hi, Alessandro. I'd guess that 15 hours was a function of postgrey, and not of anything native to Postfix (including Postscreen).

I don't run postgrey, and have been very satisfied with the combination of Postscreen and some sensible smtpd_recipient_restrictions to block the vast majority of misconfigured mailers trying to connect to my systems.

But regardless of your config, if it's working better for you, that's awesome. :)

SJ

Robert Chalmers

unread,

Nov 26, 2015, 6:42:09 AM11/26/15

to

Hi Steve,

I’m seeing this in the mail.log

warning: cidr map /usr/local/etc/postfix/msft_whitelist.cidr, line 36: non-null host address bits in "207.68.169.173/30", perhaps you should use "207.68.169.172/30" instead: skipping this rule

Nov 26 11:39:25 zeus postfix/postscreen[29402]: warning: cidr map /usr/local/etc/postfix/msft_whitelist.cidr, line 40: non-null host address bits in "65.55.238.129/26", perhaps you should use "65.55.238.128/26" instead: skipping this rule

Nov 26 11:39:25 zeus postfix/postscreen[29402]: warning: cidr map /usr/local/etc/postfix/msft_whitelist.cidr, line 41: non-null host address bits in "65.55.238.129/26", perhaps you should use "65.55.238.128/26" instead: skipping this rule

What do you think?

Robert

Robert Chalmers

rob...@chalmers.com.au Quantum Radio: http://tinyurl.com/lwwddov

Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11. 2TB Storage made up of -

Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. Lower Bay

Ralf Hildebrandt

unread,

Nov 26, 2015, 7:46:06 AM11/26/15

to

> I’m seeing this in the mail.log
>
> warning: cidr map /usr/local/etc/postfix/msft_whitelist.cidr, line 36: non-null host address bits in "207.68.169.173/30", perhaps you should use "207.68.169.172/30" instead: skipping this rule
> Nov 26 11:39:25 zeus postfix/postscreen[29402]: warning: cidr map /usr/local/etc/postfix/msft_whitelist.cidr, line 40: non-null host address bits in "65.55.238.129/26", perhaps you should use "65.55.238.128/26" instead: skipping this rule
> Nov 26 11:39:25 zeus postfix/postscreen[29402]: warning: cidr map /usr/local/etc/postfix/msft_whitelist.cidr, line 41: non-null host address bits in "65.55.238.129/26", perhaps you should use "65.55.238.128/26" instead: skipping this rule
>
>
> What do you think?

I think postfix is right :)

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Robert Chalmers

unread,

Nov 26, 2015, 7:50:03 AM11/26/15

to

So do I.

So I’ll hand cut the cidr file for now, and wait till the author updates his code..

Robert Chalmers

rob...@chalmers.com.au Quantum Radio: http://tinyurl.com/lwwddov

Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11. 2TB Storage made up of -

Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. Lower Bay

Robert Chalmers

unread,

Nov 26, 2015, 7:53:26 AM11/26/15

to

In fact on closer inspection, the last two are duplicates.

Benny Pedersen

unread,

Nov 26, 2015, 8:38:06 AM11/26/15

to

On November 26, 2015 1:46:15 PM Ralf Hildebrandt <r...@sys4.de> wrote:

>> What do you think?
> I think postfix is right :)

wish microsoft learn to use shorewall iprange ? :)

what id have microsoft on dnswl.org ?

hmm

Steve Jenkins

unread,

Nov 26, 2015, 10:09:28 AM11/26/15

to

On Thu, Nov 26, 2015 at 3:41 AM, Robert Chalmers <rob...@chalmers.com.au> wrote:

Hi Steve,

I’m seeing this in the mail.log

warning: cidr map /usr/local/etc/postfix/msft_whitelist.cidr, line 36: non-null host address bits in "207.68.169.173/30", perhaps you should use "207.68.169.172/30" instead: skipping this rule
Nov 26 11:39:25 zeus postfix/postscreen[29402]: warning: cidr map /usr/local/etc/postfix/msft_whitelist.cidr, line 40: non-null host address bits in "65.55.238.129/26", perhaps you should use "65.55.238.128/26" instead: skipping this rule
Nov 26 11:39:25 zeus postfix/postscreen[29402]: warning: cidr map /usr/local/etc/postfix/msft_whitelist.cidr, line 41: non-null host address bits in "65.55.238.129/26", perhaps you should use "65.55.238.128/26" instead: skipping this rule

What do you think?

G'day, Robert. I think you probably didn't read the entire blog post, particularly the section titled "Microsoft Is Publishing Invalid IP Ranges in their SPF Record" where I show those exact same warnings in my own maillog. :)

Both offending IPs (which are indeed invalid) appear when you do a dig txt of _spf-ssg-b.microsoft.com. It makes me want to cry a little.

I keep going back and forth regarding whether to strip the offending ranges from the script, though the script technically is functioning properly -- it's taking the IPs reported by a mailer and including them in the whitelist. But that would be better is some way to automate verifying they're valid, rather than start coding in special cases. I'll look into that today.

SJ

Steve Jenkins

unread,

Nov 26, 2015, 11:12:32 AM11/26/15

to

On Thu, Nov 26, 2015 at 4:49 AM, Robert Chalmers <rob...@chalmers.com.au> wrote:

So do I.
So I’ll hand cut the cidr file for now, and wait till the author updates his code..

So, I've updated the code. :)

Instead of relying on multiple scripts to make multiple lists, I simplified things and created a new project called Postwhite:

https://github.com/stevejenkins/postwhite

It now relies on a small script from the spf-tools pacakge (also on GitHub) to handle the recursive SPF queries. Postwhite allows you to toggle "yes/no" as to which mailers you want to include, then and creates a single SPF-based whitelist for Postscreen that is numerically sorted and has duplicates removed.

I'm still working on a way to validate the CIDRs before they make the whitelist. It's pretty dumb for MSFT to publish invalid IPs, and it's even dumber that they don't provide any way to notify them about it.

I've updated my blog post to point to the new project. Your feedback is welcome and appreciated (feel free to file an Issue on the proejct's GitHub).

And Happy Thanksgiving to my US-based friends. :)

SteveJ

Bill Cole

unread,

Nov 26, 2015, 12:00:33 PM11/26/15

to

On 26 Nov 2015, at 11:12, Steve Jenkins wrote:

> On Thu, Nov 26, 2015 at 4:49 AM, Robert Chalmers
> <rob...@chalmers.com.au>
> wrote:
>
>> So do I.
>> So I’ll hand cut the cidr file for now, and wait till the author
>> updates
>> his code..
>>
>
> So, I've updated the code. :)
>
> Instead of relying on multiple scripts to make multiple lists, I
> simplified
> things and created a new project called Postwhite:
>
> https://github.com/stevejenkins/postwhite
>
> It now relies on a small script from the spf-tools pacakge (also on
> GitHub)
> to handle the recursive SPF queries. Postwhite allows you to toggle
> "yes/no" as to which mailers you want to include, then and creates a
> single
> SPF-based whitelist for Postscreen that is numerically sorted and has
> duplicates removed.
>
> I'm still working on a way to validate the CIDRs before they make the
> whitelist. It's pretty dumb for MSFT to publish invalid IPs, and it's
> even
> dumber that they don't provide any way to notify them about it.

Every DNS SOA should have a RP field that is supposed to be an email
address (s/@/./) for the Responsible Party who can fix problems in the
zone. Surely a big responsible company like Microsoft wouldn't get that
wrong... (or maybe they would)

If you can tolerate a dependency on a non-core Perl module, I find this
function useful enough to have in .bashrc on systems where I fiddle with
IP ranges & CIDR blocks:

cidrcon ()
{
for a in $*;
do
echo $a;
done | perl -e "use Net::CIDR::Lite; \$cidr =
Net::CIDR::Lite->new(<>) ; \$_ = join (\"\n\",\$cidr->list) ; print
\"\$_\n\";"
}

So I can do things like:

# cidrcon $( dig _spf-ssg-b.microsoft.com txt +short |tr ' ' '\n' |
grep '^ip4:.*/[0-9]*$' | sed 's/ip4://' )
65.55.33.64/28
65.55.178.128/27
65.55.238.128/26
207.46.116.128/29
207.46.132.128/27
207.68.169.172/30
207.68.176.0/26
207.68.176.96/27
213.199.161.128/27

(Being trivial, obvious, and more than slightly sloppy, that bit of
shell+perl is entirely exempt from any intellectual property law. Any 2
random monkeys stand a fair chance of writing it by pure chance, as one
already has. Use as you please AT YOUR OWN RISK)

Steve Jenkins

unread,

Nov 26, 2015, 2:34:28 PM11/26/15

to

On Thu, Nov 26, 2015 at 9:00 AM, Bill Cole <postfixli...@billmail.scconsult.com> wrote:

Every DNS SOA should have a RP field that is supposed to be an email address (s/@/./) for the Responsible Party who can fix problems in the zone. Surely a big responsible company like Microsoft wouldn't get that wrong... (or maybe they would)

I emailed the dom...@microsoft.com alias that appears in the WHOIS and got an auto-response that is clearly intended for MSFT internal personnel, since it was filled with links to intranet sites.:)

But it also included an alias to an opsimt@ account that claimed to be a 24/7 DNS support alias, so I sent the message there.

No reply yet, but it's been fun to watch my Sidekick alerts pop up every time it gets opened by someone new there. It's been opened four times in the past 26 minutes, I presume from being forwarded around.

Let's hope that's a sign that they plan on fixing their SPF record soon, so those Postscreen warnings will stop. :)

SJ

ale@proto

unread,

Nov 26, 2015, 3:03:45 PM11/26/15

to

I reviewed my logs today and I saw a lot of connections from a bunch of
MS outbound gateways before entering the "postgrey layer".

Once postscreen marked one of these gw PASS OLD postgrey put the message
in greylist (default 5 mins), but it expects another connection within
(better: after!) this time. This gw "disappeared" for 12 hours instead,
while another bunch of gateways hit my server.

I know somebody discourages the use of postscreen + postgrey. But I
don't understand those MS retries.

Here is my stripped log:

Nov 24 17:51:13 MAILSERVER postfix/postscreen[21231]: CONNECT from
[157.55.234.104]:45788 to [MAILSERVER]:25
Nov 24 17:51:20 MAILSERVER postfix/tlsproxy[21233]: CONNECT from
[157.55.234.104]:45788
Nov 24 17:51:20 MAILSERVER postfix/postscreen[21231]: NOQUEUE: reject:
RCPT from [157.55.234.104]:45788: 450 4.3.2 Service currently
unavailable; from=<user@ms>, to=<recipient@here>, proto=ESMTP,
helo=<emea01-db3-obe.outbound.protection.outlook.com>
Nov 24 17:51:20 MAILSERVER postfix/tlsproxy[21233]: DISCONNECT
[157.55.234.104]:45788
Nov 24 17:51:20 MAILSERVER postfix/postscreen[21231]: HANGUP after 0.21
from [157.55.234.104]:45788 in tests after SMTP handshake
Nov 24 17:51:20 MAILSERVER postfix/postscreen[21231]: PASS NEW
[157.55.234.104]:45788
Nov 24 17:51:20 MAILSERVER postfix/postscreen[21231]: DISCONNECT
[157.55.234.104]:45788

[...]
a lot of hit-and-run here...
[...]

Nov 25 08:55:19 MAILSERVER postfix/postscreen[31379]: CONNECT from
[157.55.234.104]:60673 to [MAILSERVER]:25
Nov 25 08:55:19 MAILSERVER postfix/postscreen[31379]: PASS OLD
[157.55.234.104]:60673
Nov 25 08:55:20 MAILSERVER postfix/smtpd[31381]: connect from
mail-db3on0104.outbound.protection.outlook.com[157.55.234.104]
Nov 25 08:55:20 MAILSERVER postgrey[3789]: action=pass, reason=triplet
found, delay=43449,
client_name=mail-db3on0104.outbound.protection.outlook.com,
client_address=157.55.234.104, sender=user@ms, recipient=recipient@here
Nov 25 08:55:20 MAILSERVER postfix/smtpd[31381]: 9E375E057:
client=mail-db3on0104.outbound.protection.outlook.com[157.55.234.104]
Nov 25 08:55:20 MAILSERVER postfix/smtpd[31381]: disconnect from
mail-db3on0104.outbound.protection.outlook.com[157.55.234.104]

12 hrs delay, but successfully delivered.

a.

Il 25/11/15 18:19, Steve Jenkins ha scritto:

Steve Jenkins

unread,

Nov 26, 2015, 3:10:32 PM11/26/15

to

On Thu, Nov 26, 2015 at 12:03 PM, ale@proto <aless...@protodigital.net> wrote:

I reviewed my logs today and I saw a lot of connections from a bunch of MS outbound gateways before entering the "postgrey layer".

Once postscreen marked one of these gw PASS OLD postgrey put the message in greylist (default 5 mins), but it expects another connection within (better: after!) this time. This gw "disappeared" for 12 hours instead, while another bunch of gateways hit my server.

I know somebody discourages the use of postscreen + postgrey. But I don't understand those MS retries.

Here is my stripped log:

Nov 24 17:51:13 MAILSERVER postfix/postscreen[21231]: CONNECT from [157.55.234.104]:45788 to [MAILSERVER]:25
Nov 24 17:51:20 MAILSERVER postfix/tlsproxy[21233]: CONNECT from [157.55.234.104]:45788
Nov 24 17:51:20 MAILSERVER postfix/postscreen[21231]: NOQUEUE: reject: RCPT from [157.55.234.104]:45788: 450 4.3.2 Service currently unavailable; from=<user@ms>, to=<recipient@here>, proto=ESMTP, helo=<emea01-db3-obe.outbound.protection.outlook.com>
Nov 24 17:51:20 MAILSERVER postfix/tlsproxy[21233]: DISCONNECT [157.55.234.104]:45788
Nov 24 17:51:20 MAILSERVER postfix/postscreen[21231]: HANGUP after 0.21 from [157.55.234.104]:45788 in tests after SMTP handshake
Nov 24 17:51:20 MAILSERVER postfix/postscreen[21231]: PASS NEW [157.55.234.104]:45788
Nov 24 17:51:20 MAILSERVER postfix/postscreen[21231]: DISCONNECT [157.55.234.104]:45788

FYI - 157.55.234.0/24 is listed in the whitelist currently generated by Postwhite, so running it would probably get that mail to you many hours sooner.

Wietse Venema

unread,

Nov 26, 2015, 3:44:11 PM11/26/15

to

ale @ proto:

> I reviewed my logs today and I saw a lot of connections from a bunch of
> MS outbound gateways before entering the "postgrey layer".
>
> Once postscreen marked one of these gw PASS OLD postgrey put the message
> in greylist (default 5 mins), but it expects another connection within
> (better: after!) this time. This gw "disappeared" for 12 hours instead,
> while another bunch of gateways hit my server.

Do not greylist sites that have many *different*
outbound MTA IP addresses. This is a greylisting problem,
not postscreen,

Wietse

Paul

unread,

Nov 26, 2015, 5:27:19 PM11/26/15

to

On 26/11/2015 20:10, Steve Jenkins wrote:

On Thu, Nov 26, 2015 at 12:03 PM, ale@proto <aless...@protodigital.net> wrote:

I reviewed my logs today and I saw a lot of connections from a bunch of MS outbound gateways before entering the "postgrey layer".

Once postscreen marked one of these gw PASS OLD postgrey put the message in greylist (default 5 mins), but it expects another connection within (better: after!) this time. This gw "disappeared" for 12 hours instead, while another bunch of gateways hit my server.

I know somebody discourages the use of postscreen + postgrey. But I don't understand those MS retries.

FYI - 157.55.234.0/24 is listed in the whitelist currently generated by Postwhite, so running it would probably get that mail to you many hours sooner.

Very useful particularly when extended to generate a postgrey (in my case) client whitelist

Paul

@lbutlr

unread,

Nov 26, 2015, 8:53:51 PM11/26/15

to

On Nov 26, 2015, at 1:03 PM, ale@proto <aless...@protodigital.net> wrote:
> I know somebody discourages the use of postscreen + postgrey. But I don't understand those MS retries.

If by “someone” you mean just about everyone including the developer of postfix, then yes, someone discourages it.

Greylisting and Postscreen go together like peanut butter and nails.

--
"There's a light that shines on everything & everyone. And it shines so
bright - brighter even than the sun". That's what Minnie thinks as she
walks to meet her brother, who is nearly two years older on a Saturday
night. He's DJ-ing at some do on the edge of town on the night that
Minnie Timperley died.

Alex JOST

unread,

Nov 27, 2015, 10:23:02 AM11/27/15

to

Am 27.11.2015 um 02:53 schrieb @lbutlr:
> On Nov 26, 2015, at 1:03 PM, ale@proto <aless...@protodigital.net> wrote:
>> I know somebody discourages the use of postscreen + postgrey. But I don't understand those MS retries.
>
> If by “someone” you mean just about everyone including the developer of postfix, then yes, someone discourages it.
>
> Greylisting and Postscreen go together like peanut butter and nails.
>

Care to explain?

While I do think that postscreen is a great tool to block the majority
of spambots it doesn't make other tools obsolete.

--
Alex JOST

ale@proto

unread,

Nov 28, 2015, 1:46:05 PM11/28/15

to

Il 26/11/15 21:43, Wietse Venema ha scritto:

>
> Do not greylist sites that have many *different*
> outbound MTA IP addresses. This is a greylisting problem,
> not postscreen,
>
> Wietse
>

Thanks for your clarification, Wietse.

I have found my (macroscopic!) configuration issue instead: Enabling 220
After tests, plus greylisting... bad idea.

a.