Ken Murchison wrote:
Thanks Ken for pointing out this issue,I'll let the CMU guys respond for themselves, but the createonpost feature seems problematic if your MTA doesn't verify the legitimacy of the recipient address before passing it to lmtpd. The only way that lmtpd knows if a recipient is allowed or not is if the INBOX for that user exists. With createonpost enabled, you'll get INBOXes created for every damn address that a spammer tries in your domain.Now, if you're MTA does user lookups in LDAP, MySQL, etc, then this is a non-issue.
To clear things out, RFC 821 requires [or at least encourage] the verification of recipient's address by the SMTP/MTA/MSA server:
The second step in the procedure is the RCPT command.
RCPT <SP> TO:<forward-path> <CRLF>
This command gives a forward-path identifying one recipient.
If accepted, the receiver-SMTP returns a 250 OK reply, and
stores the forward-path. If the recipient is unknown the
receiver-SMTP returns a 550 Failure reply. This second step of
the procedure can be repeated any number of times.
Configurations where user's verification is not even attempted [eg due to bad-implemented MTA] do not worth considering.
Now on the other hand, using the INBOX existence or not as a criterion is problematic for the cases where the MTA is able to verify the user validity. I understand that this solution is a byproduct of the fact that cyrus-imap/cyrus-sasl provides many alternatives as far as the type of the users' database is concerned [WITCH IS A GREAT FEATURE]. So checking the existence of the inbox is just an easy way out, and "fail safe".
Createonpost feature is not where the problem lies, but rather it provides a solution. For the time being i think that if someone uses the right combination of MTA and user's database, can take advantage of it. [As Ken said :)]
Nikos Voutsinas