Re: [DNG] ?? chacun son go??t (was: Is it worth the effort for SPF, DMARC, DKIM, etc.?)
Quoting Simon Hobson (li...@thehobsons.co.uk): > > Sounds like a problem local to you. > > No, not in the least bit "local to me". I will be generous and assume > that you simply misunderstood what I wrote - it happens a lot :-( > > Prior to SPF, it was perfectly OK to (for example) : > > Have an account (lets say f...@example.com) so that fred can have an > email address that "goes with" his website. So, when I said 'local to you', I meant 'local to people who want to use practices that amount to forging the domain owner's Internet domain, in ways many domain owners including me no longer find tolerable and wish to make not work, i.e., to be rejected as forgeries. Since we're using the hypothetical example of Fred, my assessment then becomes 'Sounds like a problem local to Fred.' And since, as detailed below, no Fred-types are among legitimate users of _my_ domains' mail, I'm not only fine with illegitimate Freds being unable to successfully forge my domain, I'm very happy with that outcome. > For reasons we never understood*, Fred is adamant he is not prepared > (even if we configure it for him) to have a second account in his mail > client to directly collect mail from our mail server using POP or > IMAP. He just wants mail to arrive in his inbox. So instead we simply > forward his mail to his regular account - tends to be > "somegibber...@btinternet.com" and things like that). Of course, some > wanted "sales@...", "support@...", and so on as well - though mostly > these clients were prepared to do it without forwarding to an external > account. For many years that worked just fine. ONLY when more players > started implementing SPF did it break. Basically Fred relied on forging the various domains where he has accounts for mail, in the sense of originating mail from arbitrary originating IP addreseses on his outbound mail, IP addresses that the domain owners have no particular wish to be accepted as sources of their domains' mail (e.g., someone else's MTA). I have no doubt that some Internet domain owners remain oblivious to the reputation problem that results when UCE and other junk can believably impersonate their domains as the claimed sources of outbound mail -- and those oblivious domain owners can make Fred happy as long as that arrangement continues to work for both. The legitimate users of my domain linuxmafia.com (among others) do not include any Freds, because I informed all my users around the year 2000, "Hey, if you're used to sending out your [myaccount]@linuxmafia.com accounts via SMTP lists _other_ than linuxmafia.com itself, please be advised that, starting now, I'll be doing my best to ensure that any such mail fails and is rejected. Please switch to originating linuxmafia.com mail from the linuxmafia.com server ONLY. Thank you.' It's a small operation with only a small number of clueful users. Larger operations offer roving IP-address origination _of their domain's_ mail _from their authenticated users_ via the newer SMTP Submission port, 587/tcp. https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587/ If one of my users was a Fred, and he wanted his outbound linuxmafia.com mail to be acceptable to end-destinations irrespective of what IP address sent it outbound on 25/tcp, I'd say 'Sorry, Fred, not with my domain.' If you want to do that, feel welcome to register your own domain and you can risk its reputation any way you want. > We didn't change anything, others implemented policies explicitly > designed to break it. By 'others' you mean domain owners, and by 'break it', you mean break deliverability of mail from unauthorised originating IPs forging those owners' domains. And that's the thing. Fred (and you) don't own those domains. Therefore, you don't decide those domains' SMTP deliverability policies, because -not yours-. If you're unclear on the meaning of 'not yours', try to forge SMTP from linuxmafia.com, and the outcome will clarify the concept. > BTW - I did try Sender Re-Writing (this was before DMARC & DKIM were > popular). SRS was a last-ditch attempt to preserve the ability of ~/.forward and /etc/aliases ancient-style forwarding to function for cross-domain delivery in the modern age of domain owners no longer being inclined to permit SMTP forgery. IMO, it was never worth the trouble. By 2000, the handwriting was on the wall that ~/.forward and /etc/aliases cross-domain forwarding had been a casualty of the war on spammers' and others' forgeries, so with almost no regret I ceased using those two antique forwarding methods (except intra-domain). > Again no. It's not about who sends mail purporting to be me, it's > about allowing me to legitimately forward mail from "some random > person" to one of our clients - where that client just wants the email > to appear in his inbox. Basically using someone else's MTA as a relay for your client without prior arrangement. Guess what? Open relays became unacceptable even
Re: [DNG] Any parties interested in lxc ?
On Sat, 3 Oct 2020 11:04:23 +0100 g4sra via Dng wrote: > I am seeking any Devuaners with an interest in lxc to bounce ideas > off. > > I wish to move to multi-fully-containerised development but am > repeatedly stumbling along the way. Unfortunately the official lxc > resources do not help much with the (systemd-less) issues I am > having. I find bouncing (sometimes stupid - I find playing devils > advocate can really help) ideas off other people often helps > understanding and can lead to solving the problems. > > If anybody out there with practical experience or interest in lxc > would like to be electronically pestered, please reply direct to me > off list. > > Charlie. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Hello grsra, I run LXC on Devuan, and have done so even through the ascii->beowulf migration. I have some custom scripts and such for doing so, but found the devuan gitlab a little overwhelming and a lack of interest by other devuaners with LXC. If your interested in Devuan+OpenRC+LXC I'm probably your man. I would appreciate if we kept this on-board unless needed. Never know when someone in the future might find it useful. -- _ / "I honestly believe that the doctrine \ | of hell was born in the glittering eyes | | of snakes that run in frightful coils | | watching for their prey. I believe it | | was born with the yelping, howling, | | growling and snarling of wild beasts... | | I despise it, I defy it, and I hate | \ it." -- Robert G. Ingersoll / - \ \ /\ /\ //\\_//\\ \_ _// / / * * \/^^^] \_\O/_/[ ] / \_[ / \ \_ / / [ [ / \/ _/ _[ [ \ /_/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] X11: safe to remove?
> On 5 Oct 2020, at 04:23, tempforever via Dng wrote: > > Thanks for all of your responses. I did successfully remove it, with no > ill side effects to be seen so far. In my particular case, I don't use > java, or, apparently, other things that depended on X11. Not sure it > was actually necessary to remove (it wasn't) but at the very least I did > free up a little bit of disk space. :-) If in doubt next time, you can pass the “-s” argument to apt/apt-get to simulate what would happen and which packages get removed without actually removing anything. You can then inspect the all packages to be removed to ensure you don’t need any of them. If all looks ok then you run the remove/purge again without “-s” to do the actual removal. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Complete system HDD encryption w/o LLVM.
On Tue, Sep 29, 2020 at 07:57:46PM +0100, g4sra via Dng wrote: > > If you include the "initramfs" option in /etc/crypttab, keys noted in > > entries marked with that will be automatically included. > > > > Not in the scripts I had, they explicitly excluded any keys for the root > filesystem because Debian Devs know better than me (including them in an > initramfs is insecure). Ah, sorry. I was thinking of filesystems to be unlocked, not key data itself. I include "initramfs" in crypttab and I use passphrases on boot, and that keyword is what enables the prompt for the filesystem(s) in question. I sometimes have others that use keys that are on the encrypted root, and those don't specify "initramfs" as they can wait until the normal boot phase. Only vaguely related, something I haven't played with yet that I'd like to: https://github.com/latchset/clevis -- Mason Loring Blissma...@blisses.org They also surf, who only stand on waves. signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] à chacun son goût (was: Is it worth the effort for SPF, DMARC, DKIM, etc.?)
Rick Moen wrote: >> Regardless of the arguments for and against which have been done to >> death for long enough, SPF did predictably break email in many ways - >> some of which I used to use, and some which my clients used to use. > > Sounds like a problem local to you. No, not in the least bit "local to me". I will be generous and assume that you simply misunderstood what I wrote - it happens a lot :-( Prior to SPF, it was perfectly OK to (for example) : Have an account (lets say f...@example.com) so that fred can have an email address that "goes with" his website. For reasons we never understood*, Fred is adamant he is not prepared (even if we configure it for him) to have a second account in his mail client to directly collect mail from our mail server using POP or IMAP. He just wants mail to arrive in his inbox. So instead we simply forward his mail to his regular account - tends to be "somegibber...@btinternet.com" and things like that). Of course, some wanted "sales@...", "support@...", and so on as well - though mostly these clients were prepared to do it without forwarding to an external account. For many years that worked just fine. ONLY when more players started implementing SPF did it break. We didn't change anything, others implemented policies explicitly designed to break it. AFAIK there is no simple way around that, and customers took it that our system was broken regardless of how we tried to explain what the problem was and ways to get around it (they still won't countenance adding a new account to their mail client though). * If you ever think you understand the mindset of clients, I think the universe reconfigures to generate new and "more interesting" ones :D And as for the mindset of developers who simply couldn't or wouldn't understand the instruction "I will generate you a new email account login for each website**, DO NOT REUSE this login on other sites", perhaps I'd better not go there ! ** I did rate limiting and quotas on a per-account basis (useful first line of defence, limits extent of the damage if a site gets hacked), and it also allowed me to disable an individual account (rather than a whole webserver) if needed. BTW - I did try Sender Re-Writing (this was before DMARC & DKIM were popular). However, my technical skills are not up to writing software to do it myself. There was software to do it with Postfix - but it fundamentally conflicted with other software we were already using and we'd have had to stop using what was probably our most effective anti-spam measure. When I did a quick search to check I'd got the right name for that, I found that Microsoft supported it in O365 - which was a bit of a surprise. > Possibly you wish to originate port 25 mail on IP addresses you are not > prepared to declare in an SPF RR for reference by SMTP receivers. No at all, see above about assuming you simply misunderstood what I was trying to say. > Like, maybe your users think it's still 1995 and that they ought to be free > to originate outbound port 25 SMTP connections purporting to represent your > domain from arbitary, not-preplanned IP addresses at will. Again no. It's not about who sends mail purporting to be me, it's about allowing me to legitimately forward mail from "some random person" to one of our clients - where that client just wants the email to appear in his inbox. Yes, I understand there's an argument that it's "not legitimate", but it was long established practice and it broke. And it broke in exactly the ways that people knew SPF would break before they implemented it. As I said, I can't help thinking that the big players that jumped in with this first, considered such breakage as "a good thing" - why on earth should Fred be allowed to put f...@example.com on his website when he should be putting fred1234987234...@gmail.com on there instead. > What I know is that all legitimate linuxmafia.com mail originates from > my MTA's static IPv4 address, and my declaring that in an SPF RR as the > sole legitimate origin helps others definitively detect and reject > forgeries. Therefore, I publish such an SPF RR, and am happy with the > results. > > You say that for some reason you cannot gain the same benefit? I said no such thing - and now it is getting harder to assume misunderstanding. >> In a small way, by implementing SPF yourself, you've added to the >> support for something that broke existing LEGITIMATE mail activities. > > I doubt your premise that SPF 'breaks' anything It breaks mail forwarding as already mentioned. It breaks mail list managers configured as they were mostly previously configured. There's little to argue there - it's even stated in the design description for SPF that these would be broken. For list servers, there is an argument that all of the workarounds have undesirable characteristics. > and find it highly suspicious that you don't support your assertion with > anything even
Re: [DNG] X11: safe to remove?
Thanks for all of your responses. I did successfully remove it, with no ill side effects to be seen so far. In my particular case, I don't use java, or, apparently, other things that depended on X11. Not sure it was actually necessary to remove (it wasn't) but at the very least I did free up a little bit of disk space. :-) Rick Moen wrote: > Quoting wirelessduck--- via Dng (dng@lists.dyne.org): >>> On 3 Oct 2020, at 00:12, Dimitri Minaev via Dng wrote: >> >>> Because of Swing, I suppose. Java allows one to create GUI apps, >>> too. >> >> The headless jre package also has X11 dependencies. > > Though I'm certainly aboard for avoiding and eliminating bloat, I'll > point out that running selected X11 executables from a headless host, > e.g., tunneled over 'ssh -Y' to a remote X server, is a very, very > standard use case. This of course includes Java bytecode that makes > X11 calls. > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
