a msg I posted to the Imail list: =========================================
>Though it's not yet been seen broadly, it's only a matter of time >before infected machines authenticate. Once hacked, the plaintext of >passwords and other security information is only one or two steps >away, and often there is a very standard place to look for this data. So windows email client programs have weak or no encryption? If SMTP AUTH is easily/widely crackable by trojans, then we really do have a mess, since many front-end MXs and the mailbox servers behind them will croak. Again, it's the responsibility of the access provider doing port 25 blocking (effectively enforcing the sane policy of no-direct-to-MX from his networks. We are many years away from this being the case planet-wide) also to police the flow of outbound mail through his relays, just as if it were inbound mail. ie, we are, have been, in a situation where NO mail is to be trusted from ANY source. That's the whole point of required every msg submission to be protected by SMTP AUTH. If SMTP AUTH is not trustable..... Envelope-level rejections are still possible with STMP AUTH being cracked, when the SMTP AUTH server is relaying through a separate outbound relay like IMGate. Much of the mail from many of these zombies are forging sender and/or recipient (that's why our MXs see tons of inbound msgs to unknown recipients), so that SAV/RAV applied to mail from leaving the SMTP AUTH server (no longer a trustable source) through a separate outbound relay will provide a policing point. IMGate, instead of trusting the mailbox server (as most IMGates do now), can run at least SAV/RAV before the trust point. The reject logs of IMGate can be used to trace back to the mailbox server's log to see which (SMTP AUTH) IPs are sourcing the mail IMGate-rejected for bad sender/recipient. Len
