Re: spamassassin & bayes

[maciejm]

Hi
Maybe use redis for bayes rules

On 27.01.2021 23:33, Richard wrote:
>
>> Date: Wednesday, January 27, 2021 19:17:48 -0300
>> From: Daniel Armando Rodriguez 
>>
>> Hi
>>
>> Suddenly I'm facing tons of this messages
>>
>> ... bayes: cannot open bayes databases
>> /home/spamd/.spamassassin/bayes_* R/W: lock failed: File exists
>>
>> A 'solution' found on the web says disable bayes, reload SA, delete
>> such files and enable bayes again.
>>
>> Increased values in
>>
>> default_process_limit
>>
>> smtpd_recipient_limit
>>
>> qmgr_message_active_limit
>> qmgr_message_recipient_limit
>>
>> Add
>>
>> disable_dns_lookups = yes
>>
>> However messages got delivered only if I disable bayes, after a
>> while
>>
> This issue has been a discussion thread on the spamassassin mailing
> list of late. You may want to look at that mailing list's archive:
>
>   
>
> to see if that helps. You may also want to take your question there
> where it's more relevant (not that people on this list can't help
> too).
>
>

Re: throttling outgoing (queue) smtp

[natan]

Hi
The simpler solution for me:

sender_dependent_default_transport_maps =
    mysql:/etc/postfix/mysql_sender_default_rotate_map.cf

cat mysql_sender_default_rotate_map.cf

query = select transport from virtual_transport where active='1' order
by rand() limit 1;

++---++
| id | transport | active |
++---++
|  1 | smtp1                    |  1 |
|  2 | smtp235            |  1 |
|  3 | smtp12  |  1 |
|  4 | smtp185            |  1 |
|  5 | smtp29              |  1 |
|  6 | smtp149            |  1 |
|  7 | smtp30              |  1 |
++---++

and you must set transportname in master.cf and rate (if you need) on
main.cf

On 27.01.2021 18:39, Wietse Venema wrote:
> combro2k combro2k:
>> Hi there,
>>
>> I've been looking for some days for a solution I need to create for a
>> customer.
>> What we want to achieve is throttling the delivery of mails in the queue.
>> Right now we are using 'default_destination_rate_delay = 1s' which allows
>> us to send approx. 3600 to each destination maximum in 1 hour timeframe.
>> But we want to be more specific like 5000 mails globally,or 16000 globally,
>> whatever we want to do.
>> I've looked into PolicyD to achieve this, but I am stuck at the
>> implementation of it at the queue system of Postfix;
>> Right now I can only see it work with the smtpd_recipient_restrictions and
>> smtpd_end_of_data_restrictions configuration option but not with the queue
>> service.
>> Am I missing something or I am overthinking it?
> You can implement sub-second rate delays with parallel deliveries.
> Below is an example from an last-year's email.
>
>   Wietse
>
> In /etc/postfix/master.cf:
>
> smtp1  unix  -   -   n   -   -   smtp
> smtp2  unix  -   -   n   -   -   smtp
> ...
> smtpN  unix  -   -   n   -   -   smtp
>
> In /etc/postfix/main.cf:
>
> smtp1_destination_rate_delay = 1
> smtp2_destination_rate_delay = 1
> ...
> smtpN_destination_rate_delay = 1
>
> transport_maps = 
> inline:{
> { $myhostname = $local_transport }
> { localhost = $local_transport }
> { localhost.$mydomain = $local_transport }
> # Other domains that don't deliver over SMTP...
> }
> randmap:{ smtp1:, smtp2:, ..., smtpN: }
>
> This syntax requires Postfix 3.0 or later.

--

Reverse canonical for a certain receiver domain only?

[Gerben Wierda]

I have an alias that I use for a certain external web site. Mail sent to that 
alias ends up in my mailbox.

Is it possible in some way to have — for mail sent to that domain only — to 
have a canonical rewrite of the from/sender address?

E.g.

External domain: externaldomain.net and I an mydomain.net
Alias:
myalias: myusername

Incoming mail sent to myal...@mydomain.net ends up in the mailbox of myusername

Now what I want is that outgoing mail from any (or a certain) local user to 
externaldomain.net only works like this:

Local user myusername sends mail to someu...@externaldomain.net
From/sender are rewritten to myal...@mydomain.net

Is that possible?

Gerben Wierda (LinkedIn )
R&A Enterprise Architecture  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

Re: throttling outgoing (queue) smtp

[combro2k combro2k]

Hi Noel, Wietse and Natan,

Thank you all for the idea's, I will have a test scenario to find if it is
fitting for the customer :-)

Kind regards,
Martijn

Op do 28 jan. 2021 om 09:45 schreef natan :

> Hi
> The simpler solution for me:
>
> sender_dependent_default_transport_maps =
> mysql:/etc/postfix/mysql_sender_default_rotate_map.cf
>
> cat mysql_sender_default_rotate_map.cf
>
> query = select transport from virtual_transport where active='1' order
> by rand() limit 1;
>
> ++---++
> | id | transport | active |
> ++---++
> |  1 | smtp1|  1 |
> |  2 | smtp235|  1 |
> |  3 | smtp12  |  1 |
> |  4 | smtp185|  1 |
> |  5 | smtp29  |  1 |
> |  6 | smtp149|  1 |
> |  7 | smtp30  |  1 |
> ++---++
>
> and you must set transportname in master.cf and rate (if you need) on
> main.cf
>
> On 27.01.2021 18:39, Wietse Venema wrote:
> > combro2k combro2k:
> >> Hi there,
> >>
> >> I've been looking for some days for a solution I need to create for a
> >> customer.
> >> What we want to achieve is throttling the delivery of mails in the
> queue.
> >> Right now we are using 'default_destination_rate_delay = 1s' which
> allows
> >> us to send approx. 3600 to each destination maximum in 1 hour timeframe.
> >> But we want to be more specific like 5000 mails globally,or 16000
> globally,
> >> whatever we want to do.
> >> I've looked into PolicyD to achieve this, but I am stuck at the
> >> implementation of it at the queue system of Postfix;
> >> Right now I can only see it work with the smtpd_recipient_restrictions
> and
> >> smtpd_end_of_data_restrictions configuration option but not with the
> queue
> >> service.
> >> Am I missing something or I am overthinking it?
> > You can implement sub-second rate delays with parallel deliveries.
> > Below is an example from an last-year's email.
> >
> >   Wietse
> >
> > In /etc/postfix/master.cf:
> >
> > smtp1  unix  -   -   n   -   -   smtp
> > smtp2  unix  -   -   n   -   -   smtp
> > ...
> > smtpN  unix  -   -   n   -   -   smtp
> >
> > In /etc/postfix/main.cf:
> >
> > smtp1_destination_rate_delay = 1
> > smtp2_destination_rate_delay = 1
> > ...
> > smtpN_destination_rate_delay = 1
> >
> > transport_maps =
> > inline:{
> > { $myhostname = $local_transport }
> > { localhost = $local_transport }
> > { localhost.$mydomain = $local_transport }
> > # Other domains that don't deliver over SMTP...
> > }
> > randmap:{ smtp1:, smtp2:, ..., smtpN: }
> >
> > This syntax requires Postfix 3.0 or later.
>
> --
>
>

Re: Reverse canonical for a certain receiver domain only?

[Viktor Dukhovni]

On Thu, Jan 28, 2021 at 04:51:13PM +0100, Gerben Wierda wrote:

> I have an alias that I use for a certain external web site. Mail sent
> to that alias ends up in my mailbox.
> 
> Is it possible in some way to have — for mail sent to that domain only
> — to have a canonical rewrite of the from/sender address?

Yes, at the cost of a dedicated transport whose master.cf entry contains
an override for smtp_generic_maps:

master.cf:
mycanon unix ... smtp
-o smtp_generic_maps=$mycanon_generic_maps

main.cf:
transport_maps = inline:{ {example.com = mycanon:} }
mycanon_generic_maps = inline:{ { @$myorigin = myal...@mydomain.net } }

-- 
Viktor.

Trouble with STARTTLS...Connection lost

[Chu, Uy]

Hi All,

I am having trouble with one of our application server not being able to 
connect to send emails.  I noticed the issue of connection lost after STARTTLS. 
 Is it a configuration on the SMTP server or the application?

Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: connect from 
crowd-prod02.slac.stanford.edu[134.79.98.190]
Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: setting up TLS connection from 
crowd-prod02.slac.stanford.edu[134.79.98.190]
Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: 
crowd-prod02.slac.stanford.edu[134.79.98.190]: TLS cipher list 
"kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES:!EXP:!MEDIUM:!LOW:!DES:!3DES:!SSLv2:!RC4:!aNULL"
Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: SSL_accept error from 
crowd-prod02.slac.stanford.edu[134.79.98.190]: 0
Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: lost connection after STARTTLS 
from crowd-prod02.slac.stanford.edu[134.79.98.190]
Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: disconnect from 
crowd-prod02.slac.stanford.edu[134.79.98.190]
Jan 28 10:52:22 mailgate15 postfix/cleanup[10941]: 207D63C0059: 
message-id=1897115133.68.1611859942...@crowd-prod02.slac.stanford.edu

Any help would be appreciated... TIA

Re: Trouble with STARTTLS...Connection lost

[Wietse Venema]

Chu, Uy:
> Hi All,
> 
> I am having trouble with one of our application server not being able to 
> connect to send emails.  I noticed the issue of connection lost after 
> STARTTLS.  Is it a configuration on the SMTP server or the application?
> 

"postconf -n" output please?

Wietse

Re: Trouble with STARTTLS...Connection lost

[Viktor Dukhovni]

On Thu, Jan 28, 2021 at 08:18:05PM +, Chu, Uy wrote:

> I am having trouble with one of our application server not being able
> to connect to send emails.  I noticed the issue of connection lost
> after STARTTLS.  Is it a configuration on the SMTP server or the
> application?
> 
> Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: setting up TLS connection 
> from crowd-prod02.slac.stanford.edu[134.79.98.190]
> Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: 
> crowd-prod02.slac.stanford.edu[134.79.98.190]:
>   TLS cipher list
>  kEECDH +kEECDH+SHA
>  kEDH +kEDH+SHA +kEDH+CAMELLIA
>  kECDH +kECDH+SHA
>  kRSA +kRSA+SHA +kRSA+CAMELLIA
>  !aNULL !eNULL !SSLv2 !RC4 !MD5 !DES !EXP !SEED !IDEA !3DES
>  !EXP !MEDIUM !LOW
>  !DES !3DES !SSLv2 !RC4
>  !aNULL

Reformatting your cipher list, it is obvious that someone who doesn't
exactly know what they're doing has customised the cipher list, in
ways I would not recommend, *but* not to the point where I'd expect
to see interoperability issues for most clients.

> Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: SSL_accept error from 
> crowd-prod02.slac.stanford.edu[134.79.98.190]: 0
> Jan 28 10:19:04 mailgate15 postfix/smtpd[10717]: lost connection after 
> STARTTLS from crowd-prod02.slac.stanford.edu[134.79.98.190]

So the above is not sufficient to identity the problem completing the
TLS handshake.  As noted by Wietse, configuration data would be best.

FWIW, connections from "posttls-finger" appear to work:

  $ posttls-finger -c -lmay "[mailgate15.slac.stanford.edu]"
posttls-finger: mailgate15.slac.stanford.edu[134.79.102.21]:25:
subject_CN=smtpout.slac.stanford.edu, issuer_CN=InCommon ECC Server CA,

fingerprint=B9:76:16:F3:63:08:EA:5D:2A:02:6A:B3:5D:2C:46:01:5F:36:13:52:03:8B:23:54:07:83:E3:72:80:C3:3F:14,

pkey_fingerprint=52:9D:09:15:67:89:1F:4D:6B:04:B4:D9:BF:27:62:2C:02:59:BC:99:40:4F:E4:A0:14:E6:3F:38:ED:B9:33:03
posttls-finger: Untrusted TLS connection established to
mailgate15.slac.stanford.edu[134.79.102.21]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Is the client configured to authenticate the server?  The server
certificate chains appears to be missing the intermediate CA, or to be
directly signed by a root CA that's not in the usual trusted CA
bundles...

 0 subject: /C=US/postalCode=94305/ST=California/L=Stanford/street=450 Jane 
Stanford Way/O=Stanford University/OU=SLAC/CN=smtpout.slac.stanford.edu
issuer: /C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon ECC 
Server CA
   cert 
digest=B9:76:16:F3:63:08:EA:5D:2A:02:6A:B3:5D:2C:46:01:5F:36:13:52:03:8B:23:54:07:83:E3:72:80:C3:3F:14
   pkey 
digest=52:9D:09:15:67:89:1F:4D:6B:04:B4:D9:BF:27:62:2C:02:59:BC:99:40:4F:E4:A0:14:E6:3F:38:ED:B9:33:03
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
04:f6:2c:5e:21:7e:bc:37:23:02:38:9d:10:8d:64:49
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, 
CN = InCommon ECC Server CA
Validity
Not Before: Oct  1 00:00:00 2020 GMT
Not After : Oct  1 23:59:59 2021 GMT
Subject: C = US, postalCode = 94305, ST = California, L = Stanford, 
street = 450 Jane Stanford Way, O = Stanford University, OU = SLAC, CN = 
smtpout.slac.stanford.edu
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:dc:7b:cc:82:61:27:1d:d0:3e:6b:ff:8e:e4:96:
00:91:07:c5:f8:71:8e:fa:14:ff:c5:d7:1b:28:bf:
dd:ed:50:7a:69:a7:fb:fa:b8:40:bb:7d:65:6d:4d:
a7:66:e7:ca:ae:e8:8a:3d:ef:28:a2:00:10:02:d4:
2d:20:cc:fd:2d:9f:47:25:d7:30:8b:de:40:b5:af:
fc:00:2e:a8:c1:d0:4e:19:9c:71:13:11:c6:e7:18:
a9:b2:43:93:a2:be:f9:1c:be:ea:ae:86:a0:9b:b5:
64:c4:bc:9a:c4:26:15:95:42:8a:f8:0e:f0:9d:e6:
f2:dc:57:ca:cc:fe:59:25:27:b0:a2:19:73:e1:90:
60:7c:bd:32:d6:36:cb:49:9a:d3:cc:ec:43:58:1a:
c7:8f:c0:23:f1:3d:ea:fb:92:9f:82:e9:35:68:f8:
54:4f:4c:21:db:27:58:0c:99:21:4e:79:ce:b0:6f:
e0:4a:8e:5c:29:92:18:0f:68:38:e1:22:f6:d3:97:
66:f9:0d:80:b2:2c:50:4d:bc:d7:50:2c:38:b3:39:
77:00:e9:2e:b3:42:fd:ce:85:59:30:35:c4:43:b4:
00:bd:14:a2:e6:19:36:bd:9f:24:4b:83:b5:5a:af:
bc:47:be:69:15:1d:c5:b5:5e:d6:30:76:73:f8:46:
98:79
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier: 

keyid:E4:B7:CF:CB:0A:94:74:A7:9C:AD:A8:12:04:3A:D0:29:5D:2E:FC:EE

X509v3 Subject Key Identifier: 
A7:C1:08:7E:76:0D:D4:B6:61:1E:7A:2C:74:99:

RE: Trouble with STARTTLS...Connection lost

[Chu, Uy]

Here is my postconf -n

alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
inet_protocols = ipv4
local_transport = error:local delivery is disabled
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 52428800
mydestination = mailgate15.slac.stanford.edu, mailgate15, 
localhost.localdomain, localhost, localhost.slac.stanford.edu, smtpout, 
smtpout.slac.stanford.edu
mydomain = slac.stanford.edu
myhostname = mailgate15.slac.stanford.edu
mynetworks = 127.0.0.0/8 134.79.0.0/16 172.16.0.0/12
myorigin = slac.stanford.edu
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
relayhost = mxa-0d04.gslb.pphosted.com
remote_header_rewrite_domain = slac.stanford.edu
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_auth_enable = no
smtp_tls_CAfile = /etc/postfix/ca.crt
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2, RC4, aNULL
smtp_tls_loglevel = 2
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_client_restrictions = permit_mynetworks,permit_sasl_authenticated, 
reject_non_fqdn_helo_hostname,permit
smtpd_tls_CAfile = /etc/postfix/ca.crt
smtpd_tls_cert_file = /etc/postfix/smtpout_slac_stanford_edu.crt
smtpd_tls_ciphers = high
smtpd_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2, RC4, aNULL
smtpd_tls_key_file = /etc/postfix/smtpout_slac_stanford_edu.key
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
tls_high_cipherlist = 
kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES
tls_medium_cipherlist = 
kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES

-Original Message-
From: owner-postfix-us...@postfix.org  On 
Behalf Of Wietse Venema
Sent: Thursday, January 28, 2021 1:00 PM
To: Postfix users 
Subject: Re: Trouble with STARTTLS...Connection lost

Chu, Uy:
> Hi All,
> 
> I am having trouble with one of our application server not being able to 
> connect to send emails.  I noticed the issue of connection lost after 
> STARTTLS.  Is it a configuration on the SMTP server or the application?
> 

"postconf -n" output please?

Wietse

Re: Trouble with STARTTLS...Connection lost

[Viktor Dukhovni]

On Thu, Jan 28, 2021 at 09:48:13PM +, Chu, Uy wrote:

> smtp_tls_CAfile = /etc/postfix/ca.crt
> smtp_tls_ciphers = high
> smtp_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2, RC4, aNULL
> smtp_tls_loglevel = 2

Not sure why you want to disable aNULL, or set the log level > 1.

> smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
> smtp_tls_protocols = !SSLv2,!SSLv3

There are default values, no need to set them explicitly.

> smtp_tls_security_level = may
> smtp_use_tls = yes

The "smtp_use_tls" settings is obsolete and redundant.  You don't have
any SMTP TLS policy table, so there's no need for "smtp_tls_CAfile", you
don't verify any certificates.

> smtpd_tls_CAfile = /etc/postfix/ca.crt

You don't need a CAfile here either, since you don't solicit client
certs.  The subject DNs of certs in the CAfile end up in the server
handshake packets, and if there are too many can cause problems.

> smtpd_tls_key_file = /etc/postfix/smtpout_slac_stanford_edu.key
> smtpd_tls_cert_file = /etc/postfix/smtpout_slac_stanford_edu.crt

Make sure this includes any requisite intermediate CA certs.

> smtpd_tls_ciphers = high
> smtpd_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2, RC4, aNULL

With these set, you should not also customise "tls_high_cipherlist" or
"tls_medium_cipherlist".

> smtpd_tls_loglevel = 2

Likely too verbose.

> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

Typically not needed, Postfix 2.10 and up support session tickets
instead.

> smtpd_use_tls = yes

Instead use "smtpd_tls_security_level = may"

> tls_high_cipherlist = 
> kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES
> tls_medium_cipherlist = 
> kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES

Drop these overrides.

-- 
Viktor.

batching all mails to one or more domains to a non-permanently-powered machine with dynamic addresses

[Hadmut Danisch]

Hi,

I'm looking for a new solution to solve a problem that was formerly
properly solved with UUCP over TLS for the last 15 years, but since UUCP
is really stone aged and not supported anymore, I'm looking for a
solution and didn't find one.


Given Problem:

A server nachine with postfix running at a hoster with permant
connectivity, acting as a regular (virtual) MX receiver for a lot of
domains.

For some domains, the postfix should forward all (high volume) traffic
for these domains (not just particular addresses) to other machines
(private machines at homes of users) that

  * are occasionally powered on only, can be down for up to two months,
still must not lose mails,
  * have dynamic IP-Adresses (DynDNS possible, but addresses can change
any time, and DynDNS not really synchronous)
  * are behind firewalls, thus not reachable from Internet
  * thus need to pull mails


uucp+rbsmtp solved that problem for many years, but simply are not
maintained anymore for more than a decade.


  * Simply delivering mails into a mailbox and fetching with pop3 works
for simple addresses, but not for domains and multiple addresses
(envelope missing)

  * There is a „multidrop” method to spool mail for multiple recipients
into a single pop3 box, but I didn't find a documented way to do
this with postfix, instead lots of comments from people having
trouble with it and considering it as not reliable.

  * One consideration is to use ETRN, but this wouldn't work directly
and reliably (dynamic ip addresses and not reachable from Internet
due to firewall restrictions)

  * Another consideration is to use ETRN, but over a VPN network, thus
giving machines a pseudo-static IP-Address, but this is some
overhead and would require to configure postfix with a queue timeout
of 2 months

  * Next consideration is the same as above, but with two postfix
instances, to have one with short timeout to keep the queue to the
internet short (<1week) and the other one long (>2months), but this
is even more overhead and not exactly what an MTA is made for.

  * There's a LMTP-to-AMQP-tool, which theoretically solves exactly that
problem, but AMQP nodes are typically not made for such huge amounts
of data, and typically have proprietary file formats, thus no way to
debug or repair in case of failure.

  * I'm considering to mimic UUCP with modern methods, i.e. store the
mails as files with envelope (i.e. smtp commands as rbsmtp did) in a
directory and give pull access over a REST API (or simply WEBDAV),
and have a small daemon at the target machines, frequently looking
for new files and fetching them, which seems to be the most simple
and reliable method, but that's homebrewn.


is there a known, proven, and stable (and, in contrast to UUCP, modern
and maintained) method to solve this problem?


regards

Hadmut