At 7:11 PM -0700 6/1/04, Sven imposed structure on a stream of electrons, yielding:
At 19:26 -0600 6/1/04, Lewis Butler wrote:
 The problem isn't that we've been used to relay or gotten spam.
The problem showed up when the server was tested (as it routinely
is) for vulnerabilities. The test showed that it can be used as a
relay and that means I have to take it off line or fix it or it
will be taken off line (firewalled) for me.

There are no relay exploits in 1.8b (assuming correct config).

The same hole is there in 1.8, sad but verified since the test sent me a relayed message using my server after the upgrade.

Really??? Can you share that message with all of its headers please? Can you run the test with SMTP and SYSTEM logging at the highest setting and share the logs?


The message was the same as in 1.7:

BAD HEADER Improper folded header field made up entirely of whitespace
(char 00 hex) in message header 'X-Envelope'

so it probably is a new exploit that gets both 1.7 and 1.8 and that would explain why the testing 9 months ago didn't catch it.

I'm almost totally certain that this is not an 'exploit' at all, but a broken test of some sort. SIMS does not create, detect, refold, or otherwise deal with any header named 'X-Envelope' and does not make any relay decisions based on any headers of any sort. Whatever is driving that test seems itself to be creating that header and making it bad, then complaining that SIMS is not passing judgment on the header.


This is an indication of SIMS' very good core design and related to why SIMS is becoming untenable on the modern net. SIMS' SMTP module is a pure MTA, doing mail transport based solely on proper transport rules and dealing with delivery agents and user agents through very narrow and clearly defined routes. SIMS does not care whether the content of a message meets the RFC822/2822 rules or not because it does not have any reason to care: it is not a user agent, it is a set of transport and delivery agents. In an ideal world, this means that SIMS could adapt to some change in the normal format of the mail carried over SMTP, and as long as the format retained basic SMTP and mbox compatibility, SIMS could handle it. A great concept. Sadly, the modern world includes an email environment polluted in many ways which make that excellent theoretical design impractical. For example, there are 'security' tools which test all mail systems for vulnerabilities that only exist as exploitable flaws in one family of grossly misdesigned mail server when used in concert with a grossly misdesigned mail client from the same vendor (guess who). SIMS has no mechanism for looking inside mail, and while that is good on the theoretical level and actually protects SIMS from content-based exploits like improperly folded headers with embedded nulls, it also means that SIMS can't hook into antivirus or antispam systems that depend on examining message content.

--
Bill Cole
[EMAIL PROTECTED]


############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>



Reply via email to