Re: [mailop] Simple mailing list expander program for aliases files?
On 1/10/23 2:59 PM, Dan Mahoney via mailop wrote: Sometimes a problem comes across your desk that you say “wait, how is this not solved yet?”. Ya I too have wanted something like this to enhance ~/.forward files on servers that I manage, while addressing all the problems that you're describing. So I’ve gone down the rabbit hole, looking for various combinations of remailer scripts, forwarder scripts, group forwarder scripts, mailing list expanders, etc. And I’m coming up surprisingly short. I'm actually not surprised that you're coming up surprisingly short. Could I knock something together myself in perl in a half hour? Sure. This is one of those things that you can get proof of concept code in 90 minutes. Would it likely have its own untested edge cases for us to discover? Absolutely. But you'll spend too much time over the next 3 days / weeks / months dealing with edge cases. In a world of DKIM/DMarc compliance, especially, where “blow away the original headers and forward anew” is the best answer, I’m shocked to not find something like this as well. I'm convinced that the best thing to do is to attach the incoming message as message/rfc822 MIME part. 1) Don't butcher the message that you may want redacted data from. 2) Create a new message from the local source (envelope & headers) that is fully authorized and clean. I just haven't found sufficient round-2-its to sit down and do this yet, despite the fact that I would deploy it to a bunch of systems darn near immediately. It doesn't help that part of me wants to integrate the SMTP client into the script instead of relying on the local MTA stack / infrastructure. If I'm doing that I want to support TLS. I don't want to embed credentials to relay in a script. I don't want to deal with certificate based authentication AA EINSUFFICIENTROUND2ITS Our needs are simple: a unix program we can pipe a message to that will preserve the original message mime portions and subject, but discard most of the previous other headers. How in 30 years of email, something that I can’t just pkg install isn’t easily findable baffles me. Because not many people want to do this particular activity. The overlap between those that want to do so adhering to contemporary and evolving email standards is shockingly small. If someone knows of something, let me know. Pick your language de jure, burn a few hours, and fix problems as they come up. That's my plan anyway. But I'm serious about the suggestion of attaching the incoming message as a message/rfc822 MIME attachment. At least unless you have a specific reason to NOT do so. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Simple mailing list expander program for aliases files?
I remember thining about this about 6 months ago and looking around for a solution. I think I was even going to put it in my "fun projects I could do" list. Best I could find was: https://github.com/zoni/postforward but I didn't test it out. On Tue, 10 Jan 2023, Dan Mahoney via mailop wrote: All, Sometimes a problem comes across your desk that you say “wait, how is this not solved yet?”. At the day job, we have a contact list for our customers that comes from our ticket system, and it’s stuffed into an alias file with :include:. The way postfix handles these aliases, is that it preserves the original envelope sender and recipient (which we don’t want anyway), and o365 is rejecting on that envelope sender/recipient (that it’s not allowed to deliver to our internal envelope recipient, which is not unreasonable, but still surprising we haven’t hit it before. The obvious answer is: “Don’t use the :include: mechanism, just use a mailing list manager.” Which, for one alias in a system, feels like overkill. I don’t need membership management. I don’t need archiving. I don’t need bounce detection. So I’ve gone down the rabbit hole, looking for various combinations of remailer scripts, forwarder scripts, group forwarder scripts, mailing list expanders, etc. And I’m coming up surprisingly short. Could I knock something together myself in perl in a half hour? Sure. Would it likely have its own untested edge cases for us to discover? Absolutely. In a world of DKIM/DMarc compliance, especially, where “blow away the original headers and forward anew” is the best answer, I’m shocked to not find something like this as well. Our needs are simple: a unix program we can pipe a message to that will preserve the original message mime portions and subject, but discard most of the previous other headers. How in 30 years of email, something that I can’t just pkg install isn’t easily findable baffles me. If someone knows of something, let me know. -Dan ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop -- Simon Lyall | Very Busy | Web: http://www.simonlyall.com/ "To stay awake all night adds a day to your life" - Stilgar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Simple mailing list expander program for aliases files?
All, Sometimes a problem comes across your desk that you say “wait, how is this not solved yet?”. At the day job, we have a contact list for our customers that comes from our ticket system, and it’s stuffed into an alias file with :include:. The way postfix handles these aliases, is that it preserves the original envelope sender and recipient (which we don’t want anyway), and o365 is rejecting on that envelope sender/recipient (that it’s not allowed to deliver to our internal envelope recipient, which is not unreasonable, but still surprising we haven’t hit it before. The obvious answer is: “Don’t use the :include: mechanism, just use a mailing list manager.” Which, for one alias in a system, feels like overkill. I don’t need membership management. I don’t need archiving. I don’t need bounce detection. So I’ve gone down the rabbit hole, looking for various combinations of remailer scripts, forwarder scripts, group forwarder scripts, mailing list expanders, etc. And I’m coming up surprisingly short. Could I knock something together myself in perl in a half hour? Sure. Would it likely have its own untested edge cases for us to discover? Absolutely. In a world of DKIM/DMarc compliance, especially, where “blow away the original headers and forward anew” is the best answer, I’m shocked to not find something like this as well. Our needs are simple: a unix program we can pipe a message to that will preserve the original message mime portions and subject, but discard most of the previous other headers. How in 30 years of email, something that I can’t just pkg install isn’t easily findable baffles me. If someone knows of something, let me know. -Dan ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Fraudwatch?
We’ve recently received a note from FraudWatch. I’ve not seen them before. Anyone else received notices from them in the past? Feel free to contact me offline if you prefer. -- Tom Perrine tom.perr...@servicenow.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [External] Re: verizon email-to-text gateway mail deferred evening and night
It appears that Jaroslaw Rafa via mailop said: >Dnia 8.01.2023 o godz. 22:29:01 John Levine via mailop pisze: >> >- The sender can be spoofed. And you don't even have source ips to >> >check its source. >> >> No, SMS is not like VoIP. People in the phone biz tell me it is >> extremely hard to fake the source number in SMS. Look at any of the >> SMS gateway APIs and they all make you jump through hoops verifying >> the source number before they let you send anything. > >Myself I don't know any of these services, but the cybersecurity guys told >me multiple times that there are a lot of "shady" SMS gateways on the >Internet that let you easily spoof the senders number, or even put any text >(like "Google") instead of the senders number. They even demonstrated this >to me a few times. Oh, you're in Europe. Spoofing is a lot harder in the U.S. The networks are different. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
