[pfx] Mail archival like with always_bcc, but different BCC destinations by virtual mailbox domains
Hello, I have a Postfix installation for virtual mailboxes. It is the mail server (inbound MX and outbound) for a few domains. The server allows submission with SMTP AUTH (Dovecot SASL). At the moment I use always_bcc to "copy" / mirror any inbound AND outbound emails into an archive maildir. It's only one central archive maildir for all inbound and outbound mails of all virtual mailboxes. What approach would you use if you wanted different archive bcc mailboxes depending on the virtual domain? Example: - Postfix is mailserver for example-a.com / example-a.net and example-b.com / example-b.net. - Mails sent TO and BY example-a.com / example-a.net mailboxes go to archive.A@localhost - Mails sent TO and BY example-b.com / example-b.net mailboxes go to archive.B@localhost I guess, for INBOUND I might be able to use virtual_alias_maps like this: u...@example-a.com -> \u...@example-a.com, archive.A@localhost u...@example-b.com -> \u...@example-b.com, archive.B@localhost But what about mails that are SENT BY u...@example-a.com to (external) mailboxes? How could one capture the outbound mails as well? Separated based on the sender virtual domain? Or one dedicated archive maildir for each virtual mailbox would be fine, as well. Actually even better! Or in general, what approaches do you use with Postfix for mailbox archival? In the best case something based on Postfix configuration, or in the second best case something based on other open source software? Maybe some kind of milter? Would this work: Define a transport that invoked "myarchivalscript.sh" for any incoming mail to "@archival.local" and then use "archival@archival.local" in "always_bcc" and let the script decide on where to store an email copy? Thanks for your ideas and hints! Reg ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Multiple cascaded lookup tables for check_recipient_access possible?
Hello, Does Postfix support specifying multiple lookup tables for check_recipient_access? (If there's no match in the first table, look up in the next one.) smtpd_recipient_restrictions = reject_unauth_pipelining, reject_invalid_helo_hostname, reject_unknown_recipient_domain, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_non_fqdn_sender, permit_mynetworks, reject_unauth_destination, reject_unverified_recipient, check_recipient_access btree:/etc/postfix/first_table btree:/etc/postfix/second_table, < ... Thank you in advance! Reg ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix authenticated sender and From: header verification
> For now, enforcement of pipelining is actually available, while > enforcement of vs. is still only a hypothetical. As an average user without any special or legacy systems, I'd appreciate if one could configure Postfix as safe and secure as possible regarding this issue. So I'd value being on the safe side over being interoperable/lenient with non standard clients. If that means to convert all standalone CR or LF to CRLF (?) or reject suspicious SMTP dialogues, I'd opt-in to whatever is necessary. :) Reg ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: RFC logs_check
Hi, You could use a custom Fail2Ban regular expression to ban IP addresses that cause Postfix log entries containing certain domain names. See https://en.wikipedia.org/wiki/Fail2ban https://fail2ban.readthedocs.io/en/latest/filters.html Yours, Reg > Gesendet: Dienstag, 23. Juli 2024 um 23:14 Uhr > Von: "Bob via Postfix-users" > An: postfix-users@postfix.org > Betreff: [pfx] RFC logs_check > > Hi, > > Apologies if this a silly suggestion. I have hunted high and low for a > thing that would be simple for someone who is simple. I get the > impression from the usual sources such as stackexchange that there is > no easy or rather simple answer. > > Whilst I have spotted 'spawn' as a possibility of invoking an external > script I get the impression that I will fail because I have already > failed. Mot knowing much it looks like I would have to write my own > message handler in python or some other language. > > That's well above my intelligence grade so, just an idea... > > Would it be possible to have a logs_check thing that might for example > contain > > unknown > unavailable > user=<> > cyberresilience > binaryedge > censys-scanner.com > shadowserver.org > stretchoid.com > measurement.com > shodan.io > > Whereby when Postfix matches the words it would write to a logfile and > includes an IP address it would call an external script with that IP > address and the associated word so I could immediately drop the IP > address into IPTables as a block with a simple script? > > I realise stuff like failtoban is available but when I look at it the > wrong way, or in any way, it falls over and it only looks at logfiles > every so often and last time I broke my Pi I had to install rsyslog or > somesuch to get the logfiles back. > > Try not to be nice to me because if you are I will request other stuff > for simple minded people such as myself. > > Bob > > > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [RFC, sketch] IPv6 only trust of mail network
Hi Nico, I'm a bit worried about offering/selling IPv6-only "email" services to customers, fully independent of your web of trust idea: A large fraction of the SME (small and medium sized enterprises) and public service operators, whose networks I know from supporting some business-related software, are IPv4-only in their LANs / intranets, including their mail services. They send their normal business mail, order confirmations, parking ticket receipts, etc. over these networks. And pressure from the management / business-side to set up IPv6 in addition to the working IPv4 infrastructure is very low. So you should make clear to your email service customers, that they won't be able to receive 100% of common Internet email. Even if it was maybe 95 % due to most people using GMail etc., it won't be 100 %. Moreover, the lack of being able to receive and send IPv4 email is just done by choice for ideological agenda reasons and not because it's not possible from a technological point of view. I totally agree with Jaroslaw Rafa who wrote: > Of course, you can build such a thing, but please don't call such service > email anymore, as it contradicts the basic principles of email. Also if you > call that email, you will be misleading your users [...] None of the SME, I've mentioned above, will bother to set up some special IPv6 gateway VPN or whatever for a single certain customer who is unlucky to have been sold a special IPv6-only "email" solution. This probably would only cause your support capacities being consumed by "Help, I didn't receive the invitation/invoice/...!" tickets. Just one hour of IT support being consulted is far more expensive than having an IPv4 IP address for the mail gateway of your service. And I don't think security is a well-grounded reason to be IPv6-only because it's as weak as other "security by obscurity" approaches. And we should remember to consider ourselves as friendly supporters and business enablers. ^^ The stereotypes about grumpy, unhelpful IT staff are due to exactly this attitude: "Dear colleague, I'm missing 10 emails that municipality XY said to have sent to me." - "Pfff, our mail gateway is IPv6 only to keep the trash out. Tell them to migrate to IPv6." - "Eeehm, what?! O_o And how do I get my documents now? Thanks for nothing." Yours, Reg Bbbarclay > Gesendet: Dienstag, 15. Oktober 2024 um 11:28 Uhr > Von: "Nico Schottelius via Postfix-users" > An: "Jaroslaw Rafa via Postfix-users" > Cc: "Jaroslaw Rafa" > Betreff: [pfx] Re: [RFC, sketch] IPv6 only trust of mail network > > > Jaroslaw Rafa via Postfix-users writes: > > > Dnia 15.10.2024 o godz. 12:36:12 Nico Schottelius via Postfix-users pisze: > >> > >> You got a point there, there would be a barrier between classic email > >> and "secure email" (or whatever term comes to one's mind). > >> > >> Actually a bit similar as the split between the IPv6 and IPv4 world - > >> hence my argument for going IPv6 only might be even more valid. > > > > Your comparison to IPv6 vs IPv4 isn't very good, as everybody tries to do > > their best to level the barrier between IPv6 and IPv4, not strenghten > > it. > > tbh, I think this is only true to a small degree for DS-Lite approaches > using MAP-T or NAT64. > > > That's why dual stack still is (and probably will be in the foreseeable > > future) still a thing. > > I think you are very mistaken on that one, as dual stack complexity is > significantly higher than single stack. > > > Nobody is setting up IPv6-only servers, unless they are experimental servers > > meant to be used only by closed group of users, and not generally reachable > > from the Internet. Who would like to setup eg. an IPv6-only website, thus > > cutting themselves off of half of the Internet? > > I could send you quite some documents about IPv6 only hostings, but I > believe that is really going too far offtopic. In a nutshell, IPv6 only > hostings are much easier, more sustainable and the only thing that you > need is a border gateway/translator, if communication to the IPv4 world > is required. > > > [...] > > > Do you plan to add to your system some kind of gateways between the "secure > > email" and the "normal email" world? > > > > If yes, that kinda defeats the purpose you are building it for. If no, then > > you are cutting yourself from half of the Internet. I don't see a third > > option here... > > There is a very easy yes-and-no at the same time answer here: > > - Within the "secure mail" network, there will be no connection to > legacy systems > - However operators can choose to connect their "normal email" system > internally to securemail > > This way forwarding is not enabled, but legacy systems can interact with > secure email systems, if the operator is able to reach out. So graphical > seen: > > example.org (secure email) --[ internal ]--- example.org (normal email) > | > | > | > example.com (secure email only, allows access from example.org) > > Hope that m
[pfx] relayhost might not be reachable for weeks, long maximal_queue_lifetime as solution?
Hello, I have a system that happens to be disconnected from my LAN for 2 or 3 weeks, from time to time. I use Postfix to process mail generated locally, e.g. reports from unattended-upgrades. All email is then sent to my regular mail server which I, therefore, have configured as relayhost: relayhost = [192.168.123.10]:25 As 192.168.123.10 might not be reachable for weeks, I'd like Postfix to keep pending mails as long as necessary, e.g. for 6 weeks. Is the line maximal_queue_lifetime = 42d enough to achieve that? Thank you! Reg ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
