Re: secure email server
On 2013.10.23 08:44:10 +0200, BONNET, Frank wrote: > Hello > > I have to setup a "secured" email server > > - encrypted filesystem > - SSL or TLS only for SMTP and IMAPS > - Talking only to some known other same-secured servers > > Any info/links welcome ! http://www.postfix.org/TLS_README.html Maybe someone from the Dovecot list can tell how to disable 143 and use IMAPS only if you don't want to use STARTTLS. -- Best regards, Manuel
Re: secure email server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 23.10.2013 08:44, schrieb BONNET, Frank: > Hello > > I have to setup a "secured" email server > > - encrypted filesystem - SSL or TLS only for SMTP and IMAPS - > Talking only to some known other same-secured servers from the tec side thats possible, but dont await getting fully compatible to all imap/smtp stuff in the internet > > Any info/links welcome ! see ssl/tls docs postfix,dovecot > > Please do not start some flame war around this ! why should sombody do this > > I've been ordered to set up such server and I KNOW there are > probably security holes if somebody would ask me to create such "secure" setup, i simply would overlay all servers and clients via vpn, with additional tls/ssl stuff and gpg, but for sure that would be a vpn solution ( closed net ) not real internet mail stuff > but nothing's perfect so a starting point is necessary > > *Thank you for any infos* i guess you have to specify more in detail what exact youre trying to goal, so how you define secure , what is the security policy you have to setup, are you able to configure all connected servers, are you able to specify the imap client for all users as a "must have" etc Best Regards MfG Robert Schetterer - -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSZ3yGAAoJEP8jBObu0LlEyFAIAKy7OcFPYN/81uvuAU/VHvV5 iR2lm4gFzupi9YPDc+lu3xHPpwIrzcF/0jf9DcXSDjJbgASAQB+QHtaBh0cUYUkM 0bMO6HqzVLX9M/AJWnpaXXgwZ168lJwhe7zcny3+Ukw5SQKNZ1i3x3cmoJJae2cs Xb3jOkN99VXDoa9uFR/tn3c1hHID9joPGOGhHevvcOVM39UvTUg3esqttoST+Jog 5znfc82N4oK/+OstYcAckcHOt81YRy1KBxQ1tEs/ujkjRk+Z3OJAKFtQ7/wWUX3n N6TTx7D5j00w6IaLwZXIgZWs4OMMYyUjLFpE/mVuIhpVXd2E0DjjFGvV/OrKwYA= =mWgz -END PGP SIGNATURE-
dropping messages to postfix queue
Hello, I have an application that during its operation it generates lots of RFC-822 format emails. My task is to send them to a single remote email address, and I've decided that I rely on postfix to do the job. I wouldn't use a regular smtp chat with the postfix smtpd daemon, because I don't want to block the application until smtpd receives the message. I know that I may pass the message to the sendmail binary, too, but forking a program every time I need to send an email looks pretty resource heavy to me. My next idea is to just modify the application, and drop (with the link() syscall) the message directly to postfix's queue directory, and hopefully qmgr or something notices that "aha! I've got a new message to deliver." In this setup postfix wouldn't get emails from other sources, eg. from the network, just from either the sendmail binary through popen(), or the direct copy to the queue directory method. So my question is whether it's possible, and if so, then how? Best regards, Albi
Re: dropping messages to postfix queue
Kov?cs Albert: >I wouldn't use a regular smtp chat with the postfix smtpd daemon, >because I don't want to block the application until smtpd receives >the message. There is no need to "block the application". Use parallism. >My next idea is to just modify the application, and drop (with the >link() syscall) the message directly to postfix's queue directory, >and hopefully qmgr or something notices that "aha! I've got a new >message to deliver." In that case, you are on your own, with zero support. Translation: unlike the supported SMTP and sendmail iinterfaces that are maintained until eternity, your direct-to-queue submission method will break without any warning as Postfix evolves. Wietse
Re: dropping messages to postfix queue
Hello Wietse, thanks for the clarification, I'd stick to a stable and supported method. On the QSHAPE_REAME page you say that "try to keep the volume of local mail injection to a moderate level." Can you give me a rough estimation on "moderate level" for such an environment where the only source of messages is the local injection? I mean messages per second or similar. And is there a way to force the smtp utility to send multiple messages through an already established connection? Ie. instead of QUIT, continue with another MAIL FROM command (the recipient address is fixed and the same for all messages). Or the postfix smtp program is smart enough and does so whenever it's possible without instructing it? Albi On Wednesday, October 23, 2013 12:45 PM, Wietse Venema wrote: Kov?cs Albert: >I wouldn't use a regular smtp chat with the postfix smtpd daemon, >because I don't want to block the application until smtpd receives >the message. There is no need to "block the application". Use parallism. >My next idea is to just modify the application, and drop (with the >link() syscall) the message directly to postfix's queue directory, >and hopefully qmgr or something notices that "aha! I've got a new >message to deliver." In that case, you are on your own, with zero support. Translation: unlike the supported SMTP and sendmail iinterfaces that are maintained until eternity, your direct-to-queue submission method will break without any warning as Postfix evolves. Wietse
Re: secure email server
Try postfix, dovecot, forced ssl/tls, with gpg-mailgate. I only allow imaps connections then gpg-mailgate encrypts all messages with the users public key. Works perfectly. Just my 2c. Bruce
default_milter_action
Hi there, We're using Postfix for quite a while now as our default mailsystem for our world-wide organisation. We are very happy with the setup and working without any problem. Recently we purchased a Mailarchive systen (mailarchiva) to create an archive of our mails. We installed two of them; one on location A and one on location B. In Postfix, on our main mailserver, i added the following parameters to send the emails to our two mailarchive servers on location A and location B: smtpd_milters = inet:81.x.x.x:8092 inet:217.x.x.x:8092 milter_default_action = tempfail milter_connect_timeout = 10s This works perfectly without any problems. the question raised, what if the connection between the mailserver and location B is down. Is the email delivered to the mailarchive system on location A, but not location B? Will the emails not be delivered to location A and location B? etc etc. So lot of questions. Our goal is to move the emails to the hold queue if one of the mailarchive servers (location A or location B) isn't reachable by the postfix system. Then, if the connection is restored between Postfix and the mailarchive server(s), release the mails from the postfix hold queue and deliver the emails as normal to the two mailarchive servers on both locations. This way we can keep both mailarchive servers in sync. Can this be done with the 'smtp_default_action = quarantine' parameter? Thanks in advanced. Regards, Roland de Lepper
Re: dropping messages to postfix queue
Kov?cs Albert: > Hello Wietse, >thanks for the clarification, I'd stick to a stable and supported >method. Thanks. And I with I had a better answer. Speaking which, Postfix supports QMQP. This protocol is simpler than SMTP, designed by Dan Bernstein, and is based on netstrings. Netstrings are simple to implement and are already available as libraries for pupular programming languages. http://cr.yp.to/proto/qmqp.html But this does nothing to remove the file system bottleneck. >Can you give me a rough estimation on "moderate level" for such an >environment where the only source of messages is the local injection? >I mean messages per second or similar. That depends totally on the file system, and the size of messages. You can test this with the Postfix smtp-source utility. That is part of the source code distribution (untar and "make") and normally not installed. As required by SMTP (and other) rules, Postfix must fsync() each message before claiming that it has accepted the message. On rust (i.e. rotating disks) this takes many milliseconds because it involves updates of data blocks, inode blocks, bitmap blocks, most or all of which are in different locations on the drive. Even if you have a large write cache it will eventually fill up and heads will have to move and wait for sectors to fly by. On silicon (ramdisk, SSD) this takes less time because there are no head movement or rotational latency. >And is there a way to force the smtp utility to send multiple >messages through an already established connection? Ie. instead >of QUIT, continue with another MAIL FROM command (the recipient >address is fixed and the same for all messages). Or the postfix >smtp program is smart enough and does so whenever it's possible >without instructing it? As required by the SMTP protocol Postfix accepts multiple messages over one SMTP connection. But that does nothing to remove the file system bottleneck. Wietse
Re: default_milter_action
Roland de Lepper: > smtpd_milters = inet:81.x.x.x:8092 inet:217.x.x.x:8092 > milter_default_action = tempfail > milter_connect_timeout = 10s > > This works perfectly without any problems. the question raised, what if the > connection between the mailserver and location B is down. Is the email As documented no mail is delivered after Milter failure. The Postfix SMTP server will reply with an error status code (4xx) and the client will have to send the message again. The bad alternative is "milter_default_action = accept", which means that mail will be delivered but not archived. If you want both mail delivered AND mail archived, then you need to use sender_bcc_maps or recipient_bcc_maps to add recipients for archival purposes. Then, Postfix will do the retrying until the message is too old, at which time it will be returned to the sender. Wietse
Re: default_milter_action
Hi Wietse, Thanks for the reply. What about milter_default_action = quarantine ? regards, Roland de Lepper On Wed, Oct 23, 2013 at 1:24 PM, Wietse Venema wrote: > Roland de Lepper: > > smtpd_milters = inet:81.x.x.x:8092 inet:217.x.x.x:8092 > > milter_default_action = tempfail > > milter_connect_timeout = 10s > > > > This works perfectly without any problems. the question raised, what if > the > > connection between the mailserver and location B is down. Is the email > > As documented no mail is delivered after Milter failure. The Postfix > SMTP server will reply with an error status code (4xx) and the > client will have to send the message again. > > The bad alternative is "milter_default_action = accept", which means > that mail will be delivered but not archived. > > If you want both mail delivered AND mail archived, then you need > to use sender_bcc_maps or recipient_bcc_maps to add recipients for > archival purposes. > > Then, Postfix will do the retrying until the message is too old, > at which time it will be returned to the sender. > > Wietse >
Re: dropping messages to postfix queue
On 10/23/2013 6:22 AM, Kovács Albert wrote: > On the QSHAPE_REAME page you say that "try to keep the volume of > local mail injection to a moderate level." > > Can you give me a rough estimation on "moderate level" for such an > environment where the only source of messages > is the local injection? I mean messages per second or similar. This means the input rate must not exceed the output rate for an extended period. Disk throughput will likely be the bottleneck; SSD or ramdisk will help. > > And is there a way to force the smtp utility to send multiple > messages through an already established connection? This is already done automatically, but may not make much difference in a local network where the TCP setup time is short. http://www.postfix.org/CONNECTION_CACHE_README.html -- Noel Jones
Re: default_milter_action
On 10/23/2013 8:40 AM, Roland de Lepper wrote: > Hi Wietse, > > Thanks for the reply. > > What about milter_default_action = quarantine ? > The quarantine action accepts mail and puts it in the hold queue when the milter cannot run. Once mail is on hold, manual intervention is required. The milter is *not* automatically re-run when it's available, nor is the milter run when mail is released from hold. This doesn't sound particularly useful in your case. -- Noel Jones
Re: default_milter_action
Roland de Lepper: > Hi Wietse, > > Thanks for the reply. > > What about milter_default_action = quarantine ? As documented, this leaves the message in the "hold" queue. If the Milter should have done something with the message, then those things will never happen. The message is now in the queue, and the Milter is a before-queue feature. If I may ask, is the archive connected over SMTP or over a propietary protocol? I think that "defer accepting mail while the archive is down" is the safest option (i.e. leave it up to the sender to retry). Everything else requires that the message is queued in Postfix while the archive is down, for example as in this simplified picture: network -> smtpd -> queue -> smtp -> smtpd+milter -> queue -> delivery agents The part with "smtp -> smtpd+milter: would implement an SMTP-based empty after-queue filter. Wietse > regards, > > Roland de Lepper > > > On Wed, Oct 23, 2013 at 1:24 PM, Wietse Venema wrote: > > > Roland de Lepper: > > > smtpd_milters = inet:81.x.x.x:8092 inet:217.x.x.x:8092 > > > milter_default_action = tempfail > > > milter_connect_timeout = 10s > > > > > > This works perfectly without any problems. the question raised, what if > > the > > > connection between the mailserver and location B is down. Is the email > > > > As documented no mail is delivered after Milter failure. The Postfix > > SMTP server will reply with an error status code (4xx) and the > > client will have to send the message again. > > > > The bad alternative is "milter_default_action = accept", which means > > that mail will be delivered but not archived. > > > > If you want both mail delivered AND mail archived, then you need > > to use sender_bcc_maps or recipient_bcc_maps to add recipients for > > archival purposes. > > > > Then, Postfix will do the retrying until the message is too old, > > at which time it will be returned to the sender. > > > > Wietse > >
Re: TLS: Certificate signature failure -- what is the reason?
On Wed, Oct 23, 2013 at 09:39:36AM +0200, Tobias Reckhard wrote: > > with instructions on how to extract public key digests from X.509 > > certs also at: > > > > http://www.postfix.org/postconf.5.html#smtp_tls_fingerprint_digest > > Those instructions had me confused a bit, I think I now see why. I'd > used the concatenation of "openssl x509 ... | openssl rsa ... | openssl > dgst ..." to compute the fingerprint at first, which resulted in a > mismatch when connecting to the server in question. If your Postfix version is 2.9.0--2.9.5 DO NOT USE public key fingerprints, or upgrade to 2.9.6 or later. Support for public key fingerprints was added in Postfix 2.9, but was using the wrong public key digest function until 2.9.6. > Since then I've noticed that the > documentation does state that the computation of the fingerprint changed > with Postfix 2.9, I'd missed that bit previously. I probably had read > the sentence about certificate fingerprint verification being available > since Postfix 2.5, and public-key fingerprints being supported since > Postfix 2.9, but obviously I hadn't taken them to be mutually exclusive. They are not mutually exclusive. With 2.9.6 you can use either correctly computed certificate fingerprints or correctly computed public key fingerprints. With anything earlier you get only correctly computed certificate fingerprints, and with 2.9.0--2.9.5 broken support for public key fingerprints. > BTW, are there any plans for the Postfix TLS code to support CRL and/or > OCSP checks? Not at this time. -- Viktor.
possible alternative methods for exclusion to transport_maps entry
this stems from another discussion [http://archives.neohapsis.com/archives/postfix/2013-10/0454.html]. i'm currently doing: transport_maps = hash:$table_directory/transports >cat transports example.com example-internal: foo.example.com smtp: .example.comexample-internal: example-internal unix - - - - - smtp -o syslog_name=postfix/example-internal this appears to be working as desired. mail to @example.com or @.example.com is using the example-internal transport, with the exception of mail to @foo.example.com, which is using the regular smtp transport. i'm wondering if this could be done in a different manner, that wouldn't require the explicit smtp reference for foo.example.com - for example: example.com example-internal: .example.com!foo.example.comexample-internal: the essence being to say that foo.example.com will use whatever transport it would have used if transport_maps weren't in use, rather than the explicit reference to smtp: i know that specific example is not valid, but was just curious if i'd perhaps missed something in the documentation, or there was some other similar method that might be possible. -ben
Re: possible alternative methods for exclusion to transport_maps entry
On Wed, Oct 23, 2013 at 11:24:13AM -0400, btb wrote: > i'm wondering if this could be done in a different manner, that > wouldn't require the explicit smtp reference for foo.example.com - > for example: > > example.com example-internal: > .example.com!foo.example.com example-internal: http://www.postfix.org/transport.5.html RESULT FORMAT A null transport and null nexthop result means "do not change": use the delivery transport and nexthop informa- tion that would be used when the entire transport table did not exist. -- Viktor.
blocks spam (hacked account)
Hi all :-) I read a lot but not enough... I need a something to block the spam when an account email has violated... so the spammer can use that account to relay spam emails to "the world" Are there postfix options to block this (or slowing down) or I need use third parts software? Need I work on iptables, fail2ban, psad and others? Thanks for help :-) Pol
Re: blocks spam (hacked account)
Pol Hallen: > Hi all :-) > > I read a lot but not enough... > > I need a something to block the spam when an account email has violated... > so the spammer can use that account to relay spam emails to "the world" > > Are there postfix options to block this (or slowing down) or I need use > third parts software? > > Need I work on iptables, fail2ban, psad and others? Try: postfwd or policyd rate limiting. Wietse
Re: blocks spam (hacked account)
> Try: postfwd or policyd rate limiting. Sure! Thanks! A last question: real situation: sasl+tls user accounts. supposed situation: someone hack an account and take user+pass. That person do a script like this: i=0 while [ $i != 50 ]; do echo test | /usr/bin/mail -s "test message$i" "vic...@domain1.org" echo $i i=$(( $i + 1 )) done; with anvil I can only slow down the spam: anvil_rate_time_unit = 10s anvil_status_update_time = 120s smtpd_client_message_rate_limit=10 but if I modify the script that send an email spam every 5 minutes I can by-pass anvil rules :-( thanks for some advices Pol
Re: blocks spam (hacked account)
On Wed, Oct 23, 2013 at 07:25:29PM +0200, Pol Hallen wrote: Wietse: > > Try: postfwd or policyd rate limiting. > > Sure! Thanks! A last question: > > real situation: sasl+tls user accounts. > > supposed situation: someone hack an account and take user+pass. > That person do a script like this: > > i=0 > while [ $i != 50 ]; do > echo test | /usr/bin/mail -s "test message$i" "vic...@domain1.org" mail(1) by default uses sendmail(1), and this would require shell access. There are mailx implementations which can use SMTP and can even AUTH, but your typical spammer is going to be using botnets which AUTH. (Most of these botnets are comprised of Windows hosts. Compromised Unix/Linux hosts are used where possible, but they probably have a different role.) > echo $i > i=$(( $i + 1 )) > done; > > with anvil I can only slow down the spam: Not from sendmail submission. > anvil_rate_time_unit = 10s > anvil_status_update_time = 120s > smtpd_client_message_rate_limit=10 > > but if I modify the script that send an email spam every 5 minutes > I can by-pass anvil rules :-( Yes. > thanks for some advices Focus on real world attacks, and yes, it is possible that future botnet attacks will self-limit their rates. (The ones I have seen spew as much as possible as quickly as possible, their masters knowing that the target mailhost will soon be blacklisted. The goal is to pump out as much spam as possible before that happens.) If/when these botnets start trying to fly under the radar with reasonable send rates, they are still detectable through content filtering. URIBL lookups should catch these. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316
On Tue, Oct 22, 2013 at 06:07:49AM +, Viktor Dukhovni wrote:
Follow-up, comments after a brief email discussion with Paul Wouters
of RedHat:
> * Firstly, client TLS extensions are not possible when the client starts
> with an SSLv2 compatible SSL HELLO. So the list of supported curves
> is not sent by clients that are backwards compatible with SSLv2 (though
> of course by now SSLv2 should be disabled in most clients).
This is still an issue, but nobody should enable SSLv2, so perhaps
breakage when you do is tolerable. RedHat could disable client-side
ECDH ciphers for SSL connections for which SSLv2 is enabled.
> * Secondly, the OpenSSL server API does not expose the client's
> supported EC curves to the server application which is expected
> to configure the EECDH curve. Thus the extension from RFC 4492
> is almost never used, most servers choose the EECDH curve blindly.
While OpenSSL does not currently allow the server's choice of curve
to adjust to client capabilities, it does in fact check whether
the server's curve is on the client's list, and if not, the OpenSSL
server code with disable ECDH cipher-suites.
The problem turns out to be that RedHat's patch did not prune the
list of curves advertised by the TLS client! They're going to
update the code to only advertise secp{256,384}r1, which will make
connections to gmx.de work again (but without EECDH).
--
Viktor.
Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316
Am 23.10.2013 22:57, schrieb Viktor Dukhovni:
> On Tue, Oct 22, 2013 at 06:07:49AM +, Viktor Dukhovni wrote:
>
> Follow-up, comments after a brief email discussion with Paul Wouters
> of RedHat:
thank you so much for that!
>> * Firstly, client TLS extensions are not possible when the client starts
>> with an SSLv2 compatible SSL HELLO. So the list of supported curves
>> is not sent by clients that are backwards compatible with SSLv2 (though
>> of course by now SSLv2 should be disabled in most clients).
>
> This is still an issue, but nobody should enable SSLv2, so perhaps
> breakage when you do is tolerable. RedHat could disable client-side
> ECDH ciphers for SSL connections for which SSLv2 is enabled.
understood
>> * Secondly, the OpenSSL server API does not expose the client's
>> supported EC curves to the server application which is expected
>> to configure the EECDH curve. Thus the extension from RFC 4492
>> is almost never used, most servers choose the EECDH curve blindly.
>
> While OpenSSL does not currently allow the server's choice of curve
> to adjust to client capabilities, it does in fact check whether
> the server's curve is on the client's list, and if not, the OpenSSL
> server code with disable ECDH cipher-suites.
understood
> The problem turns out to be that RedHat's patch did not prune the
> list of curves advertised by the TLS client! They're going to
> update the code to only advertise secp{256,384}r1, which will make
> connections to gmx.de work again (but without EECDH)
sounds good and thank you again to point this out
so "we" can expect a fixed package soon and disable workarounds
in the meantime "smtp_tls_policy_maps" works like a charme
sooner or later i will have the whole postfix-documentatin in my configs :-)
/etc/postfix/tls_policy
gmx.de encrypt exclude=ECDH
gmx.at encrypt exclude=ECDH
gmx.net encrypt exclude=ECDH
gmx.com encrypt exclude=ECDH
Re: TLS: Certificate signature failure -- what is the reason?
Viktor Dukhovni wrote the following on 23.10.2013 16:23: > If your Postfix version is 2.9.0--2.9.5 DO NOT USE public key > fingerprints, or upgrade to 2.9.6 or later. That wasn't the problem, the documentation is quite clear in this regard. I mistakenly used the public key instructions for a pre-2.9 version of postfix. > Support for public key fingerprints was added in Postfix 2.9, ... This is stated at the beginning of the section dealing with fingerprints. Further down, where the actual openssl commands are noted, there is no such note. I'm not saying there should be one there, but had there been one, I probably wouldn't have picked the wrong set of commands. >> [...] certificate fingerprint [...] and public-key fingerprints being >> [...] mutually exclusive. > > They are not mutually exclusive. Ah, OK, thanks for the clarification. Regards, Tobias
Re: default_milter_action
Hi , The connection between Postfix and the archive is over SMTP. In my example with the smtpd_milter, will the email also go to the hold queue if only one archive connection is down? Or will it deliver the email to the archive which is online? This is an important question for me, to get both in sync. If the emails will go in the HOLD queue, that is not really a problem for me. Our monitoring will scream within a few minutes, the mailq is too big and the connection to the archive is down. This way we are noticed to take action, keep the emails on HOLD till the problem is solved with the archive or take another action if the problem is severe and take too long too solve. We can always copy the data from one archive to another. This again raise the question if the emails will go to the HOLD queue too if one archive is down. regards, Roland On Wed, Oct 23, 2013 at 4:02 PM, Wietse Venema wrote: > Roland de Lepper: > > Hi Wietse, > > > > Thanks for the reply. > > > > What about milter_default_action = quarantine ? > > As documented, this leaves the message in the "hold" queue. If the > Milter should have done something with the message, then those > things will never happen. The message is now in the queue, and the > Milter is a before-queue feature. > > If I may ask, is the archive connected over SMTP or over a > propietary protocol? > > I think that "defer accepting mail while the archive is down" is > the safest option (i.e. leave it up to the sender to retry). > Everything else requires that the message is queued in Postfix while > the archive is down, for example as in this simplified picture: > > network -> smtpd -> queue -> smtp -> smtpd+milter -> queue -> delivery > agents > > The part with "smtp -> smtpd+milter: would implement an SMTP-based > empty after-queue filter. > > Wietse > > > regards, > > > > Roland de Lepper > > > > > > On Wed, Oct 23, 2013 at 1:24 PM, Wietse Venema > wrote: > > > > > Roland de Lepper: > > > > smtpd_milters = inet:81.x.x.x:8092 inet:217.x.x.x:8092 > > > > milter_default_action = tempfail > > > > milter_connect_timeout = 10s > > > > > > > > This works perfectly without any problems. the question raised, what > if > > > the > > > > connection between the mailserver and location B is down. Is the > email > > > > > > As documented no mail is delivered after Milter failure. The Postfix > > > SMTP server will reply with an error status code (4xx) and the > > > client will have to send the message again. > > > > > > The bad alternative is "milter_default_action = accept", which means > > > that mail will be delivered but not archived. > > > > > > If you want both mail delivered AND mail archived, then you need > > > to use sender_bcc_maps or recipient_bcc_maps to add recipients for > > > archival purposes. > > > > > > Then, Postfix will do the retrying until the message is too old, > > > at which time it will be returned to the sender. > > > > > > Wietse > > > >
