Feizhou wrote: > ??? The documentation: > > The following macros are defined and/or used > internally by sendmail for interpolation into argv's > for mailers or for other contexts. The ones marked * > are information passed into sendmail[16], the ones > marked # are information passed both in and out of > sendmail, and the unmarked macros are passed out of > sendmail but are not otherwise used internally. These > macros are: > > $f is unmarked. So what? Sendmail isn't using it internally. But you can still use it in the configuration file, as long as you use it after senders address is assigned to it. > If you can, please let me see the relevant section in the > Local_check_rcpt ruleset where the sender env is being used. I guess the > helo and client ip/rdns are not stored anywhere... The beginning of my Local_check_rcpt looks something like: SLocal_check_rcpt R$* $: $>3 $1 R$* $: $1 $| $>3 $&f The input workspace for Local_check_rcpt contains only the recipient. This two rules rewrites the workspace to look something like "recipient $| sender". The remaining rules (not quoted above) than work on this pair, and based on some map lookups the ruleset returns either OK or an error. Very simple. > You missed this part of my mail: [snip] > Okay, sendmail does not come with a virtual mailbox capable LDA then. I > did not very clearly highlight the MTA and LDA parts. It does not change > the truth of what I said. And you haven't really understood Sendmail's design. Sendmail does not ship with an LDA. Well, to be correct, there is this simple LDA included in the source, however it is not compiled and installed by default (you have to do it by hand). Even the readme file for it discourages its use. It is not part of Red Hat's sendmail RPM either. Procmail is not part of Sendmail. It is completely separate component. It was nothing more than Red Hat's decision to use procmail as default LDA in their default Sendmail configuration. Well Red Hat's and pretty much every other Linux distro. Solaris for example uses completely different LDA by default. Sendmail is purely and only MTA implementation. Moving email around. Not storing it. It has nothing to do with actually delivering mail into the mailboxes. There is not a single line of code in Sendmail itself that deals with storing the email into the mailbox. Any kind of mailbox. System or virtual. Berkeley format or maildir. The simple LDA that I mentioned is in completely different tree inside Sendmail sources, clearly separate from Sendmail, and I really never looked at it as part of Sendmail as such. If it was removed from the sources, there would be very few people to actually notice it. If you are using Sendmail, you must have an external LDA, and you must configure Sendmail to pass email to it. To make things simple, Sendmail distribution comes with predefined configuration directives for most common cases. Almost all operating system distributions that use Sendmail as default MTA come with preconfigured Sendmail that "just works". And to complete the circle, for most common operating system distributions, Sendmail sources come with predefined configuratin files that use default LDA for that system. So the users that do not need anything better, they simply will never notice this important detail. So again, don't blame Sendmail for limitations of particular LDA. If LDA doesn't do what you need, get another LDA that does. Nothing to do with Sendmail. > Hmm...okay, so most sendmail users are probably not only ignorant of how > sendmail works, they are lazy too now I guess. I'm lazy too. From time to time I alias something to /dev/null. However, I don't really care in what format /dev/null mailbox is. > Wietse has done a great job. Yes Wietse did a great job. However there is no universal tool that is best for everything and everybody. Let people use whatever MTA works for them. Having a choice is marvelous thing.