On Jun 25 2022 at 6:05 PM Jaroslaw Rafa wrote: > Because with such a complicated thing as configuring > a MTA (yes, it *is* complicated) you should never rely > on recipes. You should rely on reading thoroughly > the MTA documentation
> I'm not sure what *exactly* do you mean by a "catch-all" > and what do you *exactly* want to achieve, but I have > an impression that you overcomplicated things and put > a lot of unnecessary settings in your config. > please try to describe what are differences between this > and your expected outcome. 1. Thank you for your reply and your kind attention. 2. Thank you for acknowledging that yes, it *is* complicated. That is rare, unfortunately. 3. Complicated software documentation is always more complicated than the software itself. I try, but I get lost and overwhelmed. We usually want: How to drink water? 1. Find a container that you can drink from, ideally a glass. 2. Find a source of water. 3. Pour the water into the container. 4. Drink the water. What we always get: How to drink water? License Chapter 1: what is water? Chapter 2: kinds of water Chapter 3: chemical composition of water, its atoms, reactions and compounds Chapter 4: uses of water in highly industrial settings that you never even heard about Chapter 5: why water is so important in everyday life Chapter 6: how your body processes water Chapter 7: where water is found (not only on Earth!) Chapter 8: how to make water suitable for consumption Chapter 9: how to extract or otherwise obtain water Chapter 10: all about plumbing Chapter 11: how the Greeks built their aqueducts Chapter 12: how to water plants Chapter 13: glasses - what they are and why they are so useful Chapter 14: choosing the best material for your glasses I'm tired of writing this long joke so I won't go on, but you get the idea. It's really overwhelming. It gets to a point I can no longer understand what I am reading. Just trying to decide what is relevant to my interests is taxing enough. The information is there somewhere, but no chapter is ever titled "How to drink water?" That is considered bad form. Anyway, what do I want? I want to implement my own anti-spam filter. It worked very, very well when I had it before, a long time ago. It worked like this: Suppose I have a mailbox called 'realbox' at example.com. I never reveal it to anyone. Instead, I always tell people to contact me at l...@example.com. When mail comes in, the MTA realizes there is no 'Luc' user or mailbox, so the mail is sent to the catch-all account. The catch-all account is not a mailbox or maildir, it's a script. The script checks if the sender is in the list of authorized senders. If it is, the script will re-submit (inject) the message, this time to real...@example.com. That account does exist, so the MTA delivers it to that user directly. If the sender is not authorized, the message is sent to another account that is the spambox, which I may verify and clean up about two or three times a year. I know what you're thinking: what if the sender is not in the authorized list but is legitimate? Never happened. I am not very social, I interact with very few people and the authorized list was always very comprehensive. No one that mattered was ever left out. Sometimes, someone would ask me, "Hey, this person I know wants to contact you. May I share your address?" The kind of people I have in my circle do that. They are polite and considerate. So I would say, "Yes. What is their name and address? I need to add it to a list first." It always worked. The risk is minimal and I am willing to take it. From my experience, it works better than the GMail anti-spam mechanism. It works even better with subscriptions. I subscribe with the luc-s...@example.com address and add the subscription domain to my list. For example, @postfix.org. If that address gets mail from any domain that is not in the list, it goes to /dev/null. I don't even have to keep an anti-spam folder for those. Even better, I can create an infinite number of virtual addresses, one for each subscription domain (it's just a very tidy array in my script), and replace/discard them if they become compromised. I have done that, and I discovered that my bank had shared my address with third-party advertisers! The best part of it is that I don't have to learn anything about virtual addresses or domains in postfix or dovecot. It's my own system, I know it inside out, it works forever, and I can add whatever features I want whenever I want. That is what I want. I hope you won't try to persuade me to do it differently. I absolutely won't. My solution is heavenly. When I finally have it working with postfix, I will bug you people with one more question: how do I scrub the secret 'realbox' user account from the headers so it doesn't get exposed in replies? Thank you very much for your attention. I really appreciate it. Seriously. I can't wait to have my old email system working again.
