Thanks so much, Philippe. That explanation is exactly what I needed for my use case. I wanted to use LMTP, but I also had some people that wanted to have it forwarded elsewhere. Since I don't have many users, this was best done through the virtual type of alias file.
The problem was making sure the LMTP rule wasn't matched until after the virtual expansion. Since my users wanted their email both at the intended address and the forward I was stuck until Gilles mention that after expansion , the message is tagged as local. I was still stuck until I saw how you split the two parts up. Here's my working (I hope--I'm still testing) example: accept from local for domain <vdomains> recipient <vrecipient> relay via lmtp://localhost:24 accept from any for domain <vdomains> virtual <vusers-test> <vdomains> is just a table of domains <vrecipient> is just a table of recipients <vusers-test> is a virtual table. For example, [email protected] [email protected], [email protected] Developers, thanks for the great smtp program. Philippe, thanks for your posts on LMTP and dovecot. John Grasty On Tue, Dec 10, 2013 at 8:57 PM, Philippe Lelédy < [email protected]> wrote: > Le 10/12/13 11:52, Gilles Chehade a C)crit : > > I have started thinking about a new man smtpd.conf. Here are very partial > result, for getting feedback. It's only about the bigger part, the > accept/reject rules, it is far from complete and sometimes false when > describing would like feature. > > -------------- man smtpd.conf ---- ACCEPT/REJECT ---------------- > > NOTATION: we use <<...>> to give a name to some part of a rule. > > OVERVIEW: a rule is made of the two or three parts, in this order > <<match rule>> <<alias expansion>> <<outgoing process>> > The first group is mandatory, one of the two others can be omitted but not > both. > > MATCH RULE: > It is made of <<origin restriction>> <<dest restriction>>, one of these > can be omitted but not both > Semantic: it expresses one or more conditions for an entering mail to > match the rule. All the conditions > in the MATCH RULE are ANDed. If a mail matches the MATCH RULE, the > remaining of the accept/reject rule is applied to the mail. > When a condition is preceded by !, it is reversed. > > ORIGIN RESTRICTION It is written > from [!] <<domain specification>> sender [!] <<mailaddress table>>. > If the first part is omitted, from local is implied. If the second part is > omitted, no restriction applies to the sender mailaddress > DEST RESTRICTION It is written > for [!] <<domain specification>> recipient [!] <<mailaddress table>> > Only the second part can be omitted and means no restriction applies to > the sender mailaddress. > DOMAIN SPECIFICATION > local | any | <<domain name>> | <domain names table> > <<domain name>> can contain wild card > > ALIAS EXPANSION It is written > alias <alias user table> | virtual <virtual user table>> > In using an <alias user table>, the key searched is always the user part > of the dest mailaddress, but <virtual user table> gives more possibilities. > If the look-up fails > In case of alias, processing continue which implies that an <<outgoing > process>> part must be present in this rule. > In case of virtual the mail mail is rejected > If the look-up is successful > The mail is wrapped in a new envelope, with local as the origin domain and > the new dest resulting from the key search. > The new envelope enters the accept/reject rule selection process, from the > beginning. > > OUTGOING PROCESS is either > [userinfo c > relay <<relay specification>> > BEFORE DELIVERY > a look-up is made in thec > not. I case of failure, the mail is rejected. > DELIVERY SPECIFICATION is one of > lmtp [host:port | socket] > maildir path > mbox > mda program > RELAY SPECIFICATION is > <<relay mode>> <<relay dialog specification>> > RELAY MODE is either > via host [auth c > relay [backup [mx]] > RELAY DIALOG SPECIFICATION is > [as address] [source source] [hostname ] [hostnames <names>] [pki pkiname] > [tls | verify] > > TABLES express the OR logic. The have to be introducted by > table <<table type>> <<table name>> <<table-specification>> > TABLE-TYPE is one of > inetaddress > mailaddress > addrname > userinfo > ..... > TABLE SPECIFICATION is one of > file:<<filename>> > db:<<filename>> > { <<inline content>>} > ----------------------------------- > > > > > > -- > You received this mail because you are subscribed to [email protected] > To unsubscribe, send a mail to: [email protected] > >
