SMTP STARTTLS iRule

Hey all, revisiting this one. I got real close to production with this rule, until I found that some hosts cannot send (namely messagelabs cannot not negotiate TLS with this iRule), they are spitting back an error that TLS was not supported.

 

 

In my own testing, using various POP clients or checkTLS.com, everything works, SSL is negotiated properly.

 

 

So then I tried out OpenSSL as suggested here, and I seem to be getting the dreaded "250 Chunking" error the OP got earlier. SSL appears to be negotiated, but every subsequent command in the session returns an "unrecognized command" from the SMTP server in the pool. I can see in the SMTP logs what the server sees, it is getting unprintable characters added on to the end of the commands I input. So say I connect open ssl, I negotiate TLS, and I type "ehlo" the server log will show that I connected and typed ehlo(Open SSL does this), TLS nego is then done unknown to the SMTP server, then I type "ehlo" but the SMTP server sees "ehlo█" in the log .

 

 

I am not quite sure what is going on here. I am guessing the "250 chunking" is a bit of a red herring, as in the problem is not the "chunking" but it is telling that that is the last line of the server response to the client "ehlo" greeting, the one the iRule inserts the "250 Starttls" into. So I am thinking some sort of collection buffer issue with the BIGIP, due to the way the rule is formatted. Why that makes every command after TLS negotiation corrupt is beyond me! It is getting way over my head to udnerstand what is going on.

 

 

I also tried the exact rule from this thread and the repository, as it was when it "worked" for the OP here, but it still has this "250 Chunking" issue.

 

 

There was a discussion of fixing this issue from the earlier rules, but neither Nat nor Damion explained why this probem happened? If I knew why it happened with the earlier versions of this iRule I might have a better idea of what is wrong with this one.

 

 

I am about give up on TLS offloading with the BIGIP, too bad because it would have save much time and effort being able to run multiple mailhosts with TLS off the same server pool.