Stephen Thorne:
> G'day,
>
> I've been investigating an issue with using Sender Address Verification
> using address_verify_sender.
>
> I've established that there is a problem with the implementation of
> pipelining used by Microsoft's servers, here's an example of the broken
> behaviour:
>
> # telnet 65.55.88.22 25
> Trying 65.55.88.22...
> Connected to mail.global.frontbridge.com (65.55.88.22).
> Escape character is '^]'.
> 220 TX2EHSMHS029.bigfish.com Microsoft ESMTP MAIL Service ready at Thu, 25
> Nov 2010 06:30:43 +0000
> EHLO foo.com
> 250-TX2EHSMHS029.bigfish.com Hello [150.101.177.132]
> 250-SIZE 157286400
> 250-PIPELINING
> 250-ENHANCEDSTATUSCODES
> 250-STARTTLS
> 250-AUTH
> 250-8BITMIME
> 250-BINARYMIME
> 250 CHUNKING
> RSET
> RSET
> RSET
> RSET
> QUIT
> 250 2.0.0 Resetting
> 221 2.0.0 Service closing transmission channel
> Connection closed by foreign host.
>
> What is expected is 4 consequtive '250 2.0.0 Resetting' lines, but only
> 1 is seen. This is not limited to RSET commands, but this is the
> simplest test I could compose that illustrates the problem.
Looks like Microsoft has "bluewashed" the Frontbridge software
after acquiring that company (i.e. they replaced the alien code
by their own). Bluewashing is the word at IBM for this process.
You can safely whitelist the entire 66.55 Microsoft address block:
/etc/postfix/main.cf:
smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/helo_fixes
/etc/postfix/helo_fixes
65.55.0.0/16 silent-discard pipelining
I can add a workaround to Postfix code, just like I did for a
widespread and persistent CISCO PIX bug, but it will take years
before it reaches wide deployment, because Postfix does not have
a tradition of frequent forced upgrades to the latest release.
Wietse
