The reason for needing SMTP SASL support is because some customers = outside of our class C will need to use our SMTP server when sending since our = SMTP will be listed as their authorized sending SMTP server within their SPF data. However, their local ISPs ban outbound port 25. These customers = of ours will need a port other than 25 to connect to us on. Port 587 is recommended. However, if I open 587 without requiring SMTP AUTH on that port, then we will still be vulnerable to dictionary attacks on that = port.
We need scalability as well. If we write a separate filter for each = thing we need done, then the performance will get crushed. SMTP SASL support = is something that could best be done within XMail instead of needing to = call a separate filter. IF XMail supported in process filters (through DLL = files), then I would simply write in process filters and be done. However, = spawning separate processes for each incoming email is something that quickly = kills the ability to scale. For small operations, spawning processes is fine, = but not for big operations. ---------- >If I'm not mistaken, a "patch" for this could be created using SMTP=20 filters, if only there was a way to retrieve the port used to connect as = well as the @@USERAUTH. > >Though, of course, true SASL support is better, for obvious reasons. > >Hmm... In fact, what's wrong with adding a @@USREAUTH check to your SPF = filter? If the user is authenticated, skip the test. - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
