> I'm using a custom ruleset in Local_check_rcpt that checks the sender
> part for some heavily locked down accounts. Among other things, it
> checks if local recipient is allowed to receive mail from particular
> sender (for inbound mail), and if the local sender is allowed to send to
> particular recipient (for outbound mail). Obviously, that ruleset is
> making decions based on both sender and recipient. If you'll need it in
> the future, sender's address is stored in $f macro, as nicely documented
> in Sendmail documentation (Sendmail Installation and Operation Guide).
> There's also bunch of other macros you can use throughout your rulesets.
> So you see, it is possible, well documented, and simple.
??? 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.
I only see $f being used in:
sendmail-cf]# grep -r '$f' ./
./README:FAX_MAILER_ARGS [mailfax $u $h $f] The arguments
passed to the FAX
./README:PROCMAIL_MAILER_ARGS [procmail -Y -m $h $f $u] The arguments
passed to
./README: setreuid() call, you may need to add -f $f to
the procmail
./ostype/uxpds.m4:define(`UUCP_MAILER_ARGS', `uux - -r -a$f -gmedium
$h!rmail ($u)')dnl
./ostype/a-ux.m4:ifdef(`LOCAL_MAILER_ARGS',,
`define(`LOCAL_MAILER_ARGS', `mail -d -r $f $u')')dnl
./ostype/qnx.m4:define(`UUCP_MAILER_ARGS', `uux - -r -z -a$f $h!rmail
($u)')dnl
./mailer/fax.m4: `define(`FAX_MAILER_ARGS', faxmail -d $u@$h $f)')
./mailer/procmail.m4: `define(`PROCMAIL_MAILER_ARGS', `procmail -Y -m
$h $f $u')')
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...
> It is done this way since filters in Sendmail are multithreaded. There
> is only one instance of filter running. It's kind of more complicated
> to code multithreaded program, but on the other hand it is more
> efficient than having single filter process running for each current
> transaction (on busy email server you can have dozens or even hundreds
> of transactions running in parallel). It is very efficient, and very
> well designed filtering API for email transactions, and it would be
> really great to see this API implemented in Postfix too. I just hope it
> will be exactly the same API as in Sendmail so that all existing
> Sendmail filters can be used in Postfix, and that all future Postfix
> filters could be used in Sendmail.
Wietse designed postfix to replace sendmail...so some sendmail quirks
have also hit postfix. (undocumented sendmail behaviour but replicated
nonetheless) I just noticed that postfix 2.3 is now the stable series.
milter is now standard but I'd wait a bit more since the recent
changelogs indicated some stabilizing of milter code.
>
> If you are using MIMEDefang, you don't even need to bother with all
> that. MIMEDefang is doing all that behind the scenes for you. Your
> filter_recipient function will get the sender's address in second
> argument (as well as bunch of other info from previous stages in the
> remaining arguments).
>
>> I will concede that sendmail does a good job for what it is designed
>> to do (read no virtual mailboxes and only supporting system account
>> mbox format mailboxes).
>
> Reading the above, one would conclude that you can't have Sendmail and
> Cyrus on the same box. Cyrus does not store mail in mbox format. Cyrus
> does not use system user accounts (all users are virtual, as far as
> Cyrus is concerned). But somehow, Sendmail just works with Cyrus.
You missed this part of my mail:
"Ah, i forgot the part about procmail don't support virtual mailboxes
and therefore wasn't really what I want to put in there. postfix, qmail
and maybe exim all do that out of the box without having to resort to
using maildrop." I did not say that you cannot make any virtual mail LDA
work with sendmail. sendmail does not somehow just work with Cyrus.
Somebody wrote the necessary ruleset to be the cyrus LDA working with
sendmail.
>
> Thing is. Sendmail doesn't know about mailboxes. Period. Sendmail
> will never attempt to write a mail into a mailbox. That's the job of
> local delivery agent (mailer). You tell sendmail (M lines in
> sendmail.cf file) how to talk with the mailer. Mailer will than write
> the email into the mailbox. Sendmail doesn't care if there is
> corresponding system account for that mailbox, or what format the
> mailbox is.
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.
>
> The only way to get Sendmail to write email directly into the file on
> the disk (note that I wrote "file on the disk", not "mailbox") is using
> aliases file or dot forward file in user's home directory (if there are
> system accounts on the mail server). But this is not considered to be
> delivery into mailbox. It's just "append this to that file" quick and
> dirty feature, and yes, you are doomed to mbox format if you are lazy
> enough to actually use it.
Hmm...okay, so most sendmail users are probably not only ignorant of how
sendmail works, they are lazy too now I guess.
>
> Of course, if there are system accounts, there's a feature or two extra
> that Sendmail will offer (like dot forward file). But you do not need
> to have system accounts on the mail server for Sendmail to work.
Yes and dot qmail offers much more over dot forward.
Wietse has done a great job. Probably a good thing he and DJB had a
major spat since DJB has not done a thing since 1998 about qmail. Wished
he write a dot-qmail compatible LDA though.