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]
