1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
|
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Postfix Virtual Domain Hosting Howto</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix
Virtual Domain Hosting Howto</h1>
<hr>
<h2>Purpose of this document</h2>
<p> This document requires Postfix version 2.0 or later. </p>
<p> This document gives an overview of how Postfix can be used for
hosting multiple Internet domains, both for final delivery on the
machine itself and for the purpose of forwarding to destinations
elsewhere. </p>
<p> The text not only describes delivery mechanisms that are built
into Postfix, but also gives pointers for using non-Postfix mail
delivery software. </p>
<p> The following topics are covered: </p>
<ul>
<li> <a href="#canonical">Canonical versus hosted versus other domains</a>
<li> <a href="#local_vs_database">Local files versus network databases</a>
<li> <a href="#local">As simple as can be: shared domains,
UNIX system accounts</a>
<li> <a href="#virtual_alias">Postfix virtual ALIAS example:
separate domains, UNIX system accounts</a>
<li> <a href="#virtual_mailbox">Postfix virtual MAILBOX example:
separate domains, non-UNIX accounts</a>
<li> <a href="#in_virtual_other">Non-Postfix mailbox store: separate
domains, non-UNIX accounts</a>
<li> <a href="#forwarding">Mail forwarding domains</a>
<li> <a href="#mailing_lists">Mailing lists</a>
<li> <a href="#autoreplies">Autoreplies</a>
</ul>
<h2><a name="canonical">Canonical versus hosted versus
other domains</a></h2>
<p>Most Postfix systems are the <b>final destination</b> for only a
few domain names. These include the hostnames and [the IP addresses]
of the machine that Postfix runs on, and sometimes also include
the parent domain of the hostname. The remainder of this document
will refer to these domains as the canonical domains. They are
usually implemented with the Postfix local domain address class,
as defined in the ADDRESS_CLASS_README file.</p>
<p> Besides the canonical domains, Postfix can be configured to be
the <b>final destination</b> for any number of additional domains.
These domains are called hosted, because they are not directly
associated with the name of the machine itself. Hosted domains are
usually implemented with the virtual alias domain address class
and/or with the virtual mailbox domain address class, as defined
in the ADDRESS_CLASS_README file. </p>
<p> But wait! There is more. Postfix can be configured as a backup
MX host for other domains. In this case Postfix is <b>not the final
destination</b> for those domains. It merely queues the mail when
the primary MX host is down, and forwards the mail when the primary
MX host becomes available. This function is implemented with the
relay domain address class, as defined in the ADDRESS_CLASS_README
file. </p>
<p> Finally, Postfix can be configured as a transit host for sending
mail across the internet. Obviously, Postfix is not the final destination
for such mail. This function is available only for authorized
clients and/or users, and is implemented by the default domain
address class, as defined in the ADDRESS_CLASS_README file. </p>
<h2><a name="local_vs_database">Local files versus network databases</a></h2>
<p> The examples in this text use table lookups from local files
such as DBM or Berkeley DB. These are easy to debug with the
<b>postmap</b> command: </p>
<blockquote>
Example: <tt>postmap -q info@example.com hash:/etc/postfix/virtual</tt>
</blockquote>
<p> See the documentation in LDAP_README, MYSQL_README and PGSQL_README
for how to replace local files by databases. The reader is strongly
advised to make the system work with local files before migrating
to network databases, and to use the <b>postmap</b> command to verify
that network database lookups produce the exact same results as
local file lookup. </p>
<blockquote>
Example: <tt>postmap -q info@example.com ldap:/etc/postfix/virtual.cf</tt>
</blockquote>
<h2><a name="local">As simple as can be: shared domains, UNIX system
accounts</a></h2>
<p> The simplest method to host an additional domain is to add the
domain name to the domains listed in the Postfix mydestination
configuration parameter, and to add the user names to the UNIX
password file. </p>
<p> This approach makes no distinction between canonical and hosted
domains. Each username can receive mail in every domain. </p>
<p> In the examples we will use "example.com" as the domain that is
being hosted on the local Postfix machine. </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
mydestination = $myhostname localhost.$mydomain ... example.com
</pre>
</blockquote>
<p> The limitations of this approach are: </p>
<ul>
<li>A total lack of separation: mail for info@my.host.name is
delivered to the same UNIX system account as mail for info@example.com.
<li> With users in the UNIX password file, administration of large
numbers of users becomes inconvenient.
</ul>
<p> The examples that follow provide solutions for both limitations.
</p>
<h2><a name="virtual_alias">Postfix virtual ALIAS example:
separate domains, UNIX system accounts</a></h2>
<p> With the approach described in this section, every hosted domain
can have its own info etc. email address. However, it still uses
UNIX system accounts for local mailbox deliveries. </p>
<p> With virtual alias domains, each hosted address is aliased to
a local UNIX system account or to a remote address. The example
below shows how to use this mechanism for the example.com domain.
</p>
<blockquote>
<pre>
1 /etc/postfix/main.cf:
2 virtual_alias_domains = example.com ...other hosted domains...
3 virtual_alias_maps = hash:/etc/postfix/virtual
4
5 /etc/postfix/virtual:
6 postmaster@example.com postmaster
7 info@example.com joe
8 sales@example.com jane
9 # Uncomment entry below to implement a catch-all address
10 # @example.com jim
11 ...virtual aliases for more domains...
</pre>
</blockquote>
<p> Notes: </p>
<ul>
<li> <p> Line 2: the virtual_alias_domains setting tells Postfix
that example.com is a so-called virtual alias domain. If you omit
this setting then Postfix will reject mail (relay access denied)
or will not be able to deliver it (mail for example.com loops back
to myself). </p>
<p> NEVER list a virtual alias domain name as a mydestination
domain! </p>
<li> <p> Lines 3-8: the /etc/postfix/virtual file contains the virtual
aliases. With the example above, mail for postmaster@example.com
goes to the local postmaster, while mail for info@example.com goes
to the UNIX account joe, and mail for sales@example.com goes to
the UNIX account jane. Mail for all other addresses in example.com
is rejected with the error message "User unknown". </p>
<li> <p> Line 10: the commented out entry (text after #) shows how
one would implement a catch-all virtual alias that receives mail
for every example.com address not listed in the virtual alias file.
This is not without risk. Spammers nowadays try to send mail from
(or mail to) every possible name that they can think of. A catch-all
mailbox is likely to receive many spam messages, and many bounces
for spam messages that were sent in the name of anything@example.com.
</p>
</ul>
<p>Execute the command "<b>postmap /etc/postfix/virtual</b>" after
changing the virtual file, and execute the command "<b>postfix
reload</b>" after changing the main.cf file. </p>
<p> Note: virtual aliases can resolve to a local address or to a
remote address, or both. They don't have to resolve to UNIX system
accounts on your machine. </p>
<p> More details about the virtual alias file are given in the
virtual(5) manual page, including multiple addresses on the right-hand
side. </p>
<p> Virtual aliasing solves one problem: it allows each domain to
have its own info mail address. But there still is one drawback:
each virtual address is aliased to a UNIX system account. As you
add more virtual addresses you also add more UNIX system accounts.
The next section eliminates this problem. </p>
<h2><a name="virtual_mailbox">Postfix virtual MAILBOX example:
separate domains, non-UNIX accounts</a></h2>
<p> As a system hosts more and more domains and users, it becomes less
desirable to give every user their own UNIX system account.</p>
<p> With the Postfix virtual(8) mailbox delivery agent, every
recipient address can have its own virtual mailbox. Unlike virtual
alias domains, virtual mailbox domains do not need the clumsy
translation from each recipient addresses into a different address,
and owners of a virtual mailbox address do not need to have a UNIX
system account.</p>
<p> The Postfix virtual(8) mailbox delivery agent looks up the user
mailbox pathname, uid and gid via separate tables that are searched
with the recipient's mail address. Maildir style delivery is turned
on by terminating the mailbox pathname with "/".</p>
<p> If you find the idea of multiple tables bothersome, remember
that you can migrate the information (once it works), to an SQL
database. If you take that route, be sure to review the <a
href="#local_vs_database"> "local files versus databases"</a>
section at the top of this document.</p>
<p> Here is an example of a virtual mailbox domain "example.com":
</p>
<blockquote>
<pre>
1 /etc/postfix/main.cf:
2 virtual_mailbox_domains = example.com ...more domains...
3 virtual_mailbox_base = /var/mail/vhosts
4 virtual_mailbox_maps = hash:/etc/postfix/vmailbox
5 virtual_minimum_uid = 100
6 virtual_uid_maps = static:5000
7 virtual_gid_maps = static:5000
8 virtual_alias_maps = hash:/etc/postfix/virtual
9
10 /etc/postfix/vmailbox:
11 info@example.com example.com/info
12 sales@example.com example.com/sales/
13 # Comment out the entry below to implement a catch-all.
14 # @example.com example.com/catchall
15 ...virtual mailboxes for more domains...
16
17 /etc/postfix/virtual:
18 postmaster@example.com postmaster
</pre>
</blockquote>
<p> Notes: </p>
<ul>
<li> <p> Line 2: The virtual_mailbox_domains setting tells Postfix
that example.com is a so-called virtual mailbox domain. If you omit
this setting then Postfix will reject mail (relay access denied)
or will not be able to deliver it (mail for example.com loops back
to myself). </p>
<p> NEVER list a virtual MAILBOX domain name as a mydestination
domain! </p>
<p> NEVER list a virtual MAILBOX domain name as a virtual ALIAS
domain! </p>
<li> <p> Line 3: The virtual_mailbox_base parameter specifies a
prefix for all virtual mailbox pathnames. This is a safety mechanism
in case someone makes a mistake. It prevents mail from being
delivered all over the file system. </p>
<li> <p> Lines 4, 10-15: The virtual_mailbox_maps parameter specifies
the lookup table with mailbox (or maildir) pathnames, indexed by
the virtual mail address. In this example, mail for info@example.com
goes to the mailbox at /var/mail/vhosts/example.com/info while mail
for sales@example.com goes to the maildir located at
/var/mail/vhosts/example.com/sales/. </p>
<li> <p> Line 5: The virtual_minimum_uid specifies a lower bound
on the mailbox or maildir owner's UID. This is a safety mechanism
in case someone makes a mistake. It prevents mail from being written
to sensitive files. </p>
<li> <p> Lines 6, 7: The virtual_uid_maps and virtual_gid_maps
parameters specify that all the virtual mailboxes are owned by a
fixed uid and gid 5000. If this is not what you want, specify
lookup tables that are searched by the recipient's mail address.
</p>
<li> <p> Line 14: The commented out entry (text after #) shows how
one would implement a catch-all virtual mailbox address. Be prepared
to receive a lot of spam, as well as bounced spam that was sent in
the name of anything@example.com. </p>
<p> NEVER put a virtual MAILBOX wild-card in the virtual ALIAS
file!! </p>
<li> <p> Lines 8, 17, 18: As you see, it is possible to mix virtual
aliases with virtual mailboxes. We use this feature to redirect
mail for example.com's postmaster address to the local postmaster.
You can use the same mechanism to redirect an address to a remote
address. </p>
<li> <p> Line 18: This example assumes that in main.cf, $myorigin
is listed under the mydestination parameter setting. If that is
not the case, specify an explicit domain name on the right-hand
side of the virtual alias table entries or else mail will go to
the wrong domain. </p>
</ul>
<p> Execute the command "<b>postmap /etc/postfix/virtual</b>" after
changing the virtual file, execute "<b>postmap /etc/postfix/vmailbox</b>"
after changing the vmailbox file, and execute the command "<b>postfix
reload</b>" after changing the main.cf file. </p>
<p> Note: mail delivery happens with the recipient's UID/GID
privileges specified with virtual_uid_maps and virtual_gid_maps.
Postfix 2.0 and earlier will not create mailDIRs in world-writable
parent directories; you must create them in advance before you can
use them. Postfix may be able to create mailBOX files by itself,
depending on parent directory write permissions, but it is safer
to create mailBOX files ahead of time. </p>
<p> More details about the virtual mailbox delivery agent are given
in the virtual(8) manual page. </p>
<h2><a name="in_virtual_other">Non-Postfix mailbox store: separate
domains, non-UNIX accounts</a></h2>
<p> This is a variation on the Postfix virtual mailbox example.
Again, every hosted address can have its own mailbox. However, most
parameters that control the virtual(8) delivery agent are no longer
applicable: only virtual_mailbox_domains and virtual_mailbox_maps
stay in effect. These parameters are needed to reject mail for
unknown recipients. </p>
<p> While non-Postfix software is being used for final delivery,
some Postfix concepts are still needed in order to glue everything
together. For additional background on this glue you may want to
take a look at the virtual mailbox domain class as defined in the
ADDRESS_CLASS_README file. </p>
<p> The text in this section describes what things should look like
from Postfix's point of view. See CYRUS_README or MAILDROP_README
for specific information about Cyrus or about Courier maildrop.
</p>
<p> Here is an example for a hosted domain example.com that delivers
to a non-Postfix delivery agent: </p>
<blockquote>
<pre>
1 /etc/postfix/main.cf:
2 virtual_transport = ...see below...
3 virtual_mailbox_domains = example.com ...more domains...
4 virtual_mailbox_maps = hash:/etc/postfix/vmailbox
5 virtual_alias_maps = hash:/etc/postfix/virtual
6
7 /etc/postfix/vmailbox:
8 info@example.com whatever
9 sales@example.com whatever
10 # Comment out the entry below to implement a catch-all.
11 # Configure the mailbox store to accept all addresses.
12 # @example.com whatever
13 ...virtual mailboxes for more domains...
14
15 /etc/postfix/virtual:
16 postmaster@example.com postmaster
</pre>
</blockquote>
<p> Notes: </p>
<ul>
<li> <p> Line 2: With delivery to a non-Postfix mailbox store for
hosted domains, the virtual_transport parameter usually specifies
the Postfix LMTP client, or the name of a master.cf entry that
executes non-Postfix software via the pipe delivery agent. Typical
examples (use only one): </p>
<blockquote>
<pre>
virtual_transport = lmtp:unix:/path/name (uses UNIX-domain socket)
virtual_transport = lmtp:hostname:port (uses TCP socket)
virtual_transport = maildrop: (uses pipe(8) to command)
</pre>
</blockquote>
<p> Postfix comes ready with support for LMTP. And an example
maildrop delivery method is already defined in the default Postfix
master.cf file. See the MAILDROP_README document for more details.
</p>
<li> <p> Line 3: The virtual_mailbox_domains setting tells Postfix
that example.com is delivered via the virtual_transport that was
discussed in the previous paragraph. If you omit this
virtual_mailbox_domains setting then Postfix will either reject
mail (relay access denied) or will not be able to deliver it (mail
for example.com loops back to myself). </p>
<p> NEVER list a virtual MAILBOX domain name as a mydestination
domain! </p>
<p> NEVER list a virtual MAILBOX domain name as a virtual ALIAS
domain! </p>
<li> <p> Lines 4, 7-13: The virtual_mailbox_maps parameter specifies
the lookup table with all valid recipient addresses. The lookup
result value is ignored by Postfix. In the above example,
info@example.com
and sales@example.com are listed as valid addresses; other mail for
example.com is rejected with "User unknown" by the Postfix SMTP
server. It's left up to the non-Postfix delivery agent to reject
non-existent recipients from local submission or from local alias
expansion. If you intend to
use LDAP, MySQL or PgSQL instead of local files, be sure to review
the <a href="#local_vs_database"> "local files versus databases"</a>
section at the top of this document! </p>
<li> <p> Line 12: The commented out entry (text after #) shows how
one would inform Postfix of the existence of a catch-all address.
Again, the lookup result is ignored by Postfix. </p>
<p> NEVER put a virtual MAILBOX wild-card in the virtual ALIAS
file!! </p>
<p> Note: if you specify a wildcard in virtual_mailbox_maps, then
you still need to configure the non-Postfix mailbox store to receive
mail for any address in that domain. </p>
<li> <p> Lines 5, 15, 16: As you see above, it is possible to mix
virtual aliases with virtual mailboxes. We use this feature to
redirect mail for example.com's postmaster address to the local
postmaster. You can use the same mechanism to redirect any addresses
to a local or remote address. </p>
<li> <p> Line 16: This example assumes that in main.cf, $myorigin
is listed under the mydestination parameter setting. If that is
not the case, specify an explicit domain name on the right-hand
side of the virtual alias table entries or else mail will go to
the wrong domain. </p>
</ul>
<p> Execute the command "<b>postmap /etc/postfix/virtual</b>" after
changing the virtual file, execute "<b>postmap /etc/postfix/vmailbox</b>"
after changing the vmailbox file, and execute the command "<b>postfix
reload</b>" after changing the main.cf file. </p>
<h2><a name="forwarding">Mail forwarding domains</a></h2>
<p> Some providers host domains that have no (or only a few) local
mailboxes. The main purpose of these domains is to forward mail
elsewhere. The following example shows how to set up example.com
as a mail forwarding domain: </p>
<blockquote>
<pre>
1 /etc/postfix/main.cf:
2 virtual_alias_domains = example.com ...other hosted domains...
3 virtual_alias_maps = hash:/etc/postfix/virtual
4
5 /etc/postfix/virtual:
6 postmaster@example.com postmaster
7 joe@example.com joe@somewhere
8 jane@example.com jane@somewhere-else
9 # Uncomment entry below to implement a catch-all address
10 # @example.com jim@yet-another-site
11 ...virtual aliases for more domains...
</pre>
</blockquote>
<p> Notes: </p>
<ul>
<li> <p> Line 2: The virtual_alias_domains setting tells Postfix
that example.com is a so-called virtual alias domain. If you omit
this setting then Postfix will reject mail (relay access denied)
or will not be able to deliver it (mail for example.com loops back
to myself). </p>
<p> NEVER list a virtual alias domain name as a mydestination
domain! </p>
<li> <p> Lines 3-11: The /etc/postfix/virtual file contains the
virtual aliases. With the example above, mail for postmaster@example.com
goes to the local postmaster, while mail for joe@example.com goes
to the remote address joe@somewhere, and mail for jane@example.com
goes to the remote address jane@somewhere-else. Mail for all other
addresses in example.com is rejected with the error message "User
unknown". </p>
<li> <p> Line 10: The commented out entry (text after #) shows how
one would implement a catch-all virtual alias that receives mail
for every example.com address not listed in the virtual alias file.
This is not without risk. Spammers nowadays try to send mail from
(or mail to) every possible name that they can think of. A catch-all
mailbox is likely to receive many spam messages, and many bounces
for spam messages that were sent in the name of anything@example.com.
</p>
</ul>
<p> Execute the command "<b>postmap /etc/postfix/virtual</b>" after
changing the virtual file, and execute the command "<b>postfix
reload</b>" after changing the main.cf file. </p>
<p> More details about the virtual alias file are given in the
virtual(5) manual page, including multiple addresses on the right-hand
side. </p>
<h2><a name="mailing_lists">Mailing lists</a></h2>
<p> The examples that were given above already show how to direct
mail for virtual postmaster addresses to a local postmaster. You
can use the same method to direct mail for any address to a local
or remote address. </p>
<p> There is one major limitation: virtual aliases and virtual
mailboxes can't directly deliver to mailing list managers such as
majordomo. The solution is to set up virtual aliases that direct
virtual addresses to the local delivery agent: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
listname-request@example.com listname-request
listname@example.com listname
owner-listname@example.com owner-listname
/etc/aliases:
listname: "|/some/where/majordomo/wrapper ..."
owner-listname: ...
listname-request: ...
</pre>
</blockquote>
<p> This example assumes that in main.cf, $myorigin is listed under
the mydestination parameter setting. If that is not the case,
specify an explicit domain name on the right-hand side of the
virtual alias table entries or else mail will go to the wrong
domain. </p>
<p> More information about the Postfix local delivery agent can be
found in the local(8) manual page. </p>
<p> Why does this example use a clumsy virtual alias instead of a
more elegant transport mapping? The reason is that mail for the
virtual mailing list would be rejected with "User unknown". In
order to make the transport mapping work one would still need a
bunch of virtual alias or virtual mailbox table entries. </p>
<ul>
<li> In case of a virtual alias domain, there would need to be one
identity mapping from each mailing list address to itself.
<li> In case of a virtual mailbox domain, there would need to be
a dummy mailbox for each mailing list address.
</ul>
<h2><a name="autoreplies">Autoreplies</a></h2>
<p> In order to set up an autoreply for virtual recipients while
still delivering mail as normal, set up a rule in a virtual alias
table: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
user@domain.tld user@domain.tld, user@domain.tld@autoreply.mydomain.tld
</pre>
</blockquote>
<p> This delivers mail to the recipient, and sends a copy of the
mail to the address that produces automatic replies. The address
can be serviced on a different machine, or it can be serviced
locally by setting up a transport map entry that pipes all mail
for autoreply.mydomain.tld into some script that sends an automatic
reply back to the sender. </p>
<p> DO NOT list autoreply.mydomain.tld in mydestination! </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
/etc/postfix/transport:
autoreply.mydomain.tld autoreply:
/etc/postfix/master.cf:
# =============================================================
# service type private unpriv chroot wakeup maxproc command
# (yes) (yes) (yes) (never) (100)
# =============================================================
autoreply unix - n n - - pipe
flags= user=nobody argv=/path/to/autoreply $sender $mailbox
</pre>
</blockquote>
<p> This invokes /path/to/autoreply with the sender address and
the user@domain.tld recipient address on the command line. </p>
<p> For more information, see the pipe(8) manual page, and the
comments in the Postfix master.cf file. </p>
</body>
</html>
|
