~begriffs

~begriffs/begriffs-test

Last active 1 year, 10 months ago
View more

Recent activity

LDLIBS in portable makefiles a month ago

From Joe Nelson to ~skeeto/public-inbox

Hi Chris, I notice that your makefile article [1] uses the macro name
LDLIBS for -l options like -lm. That's reminiscent of GNU make's .c
suffix rule [2]:

	LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)

	.c:
		$(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@

Do you know why they separate the -L flags in LDFLAGS vs -l flags in
LDLIBS? I realize that GCC's linker has trouble if the -l flags precede
the source file(s), but my question is why don't they put all the flags
(both -L and -l) together into LDFLAGS and put that macro at the end?

Re: Initial pre-release of aerc 11 months ago

From Joe Nelson to ~sircmpwn/public-inbox

> Fine, you're in love with mutt. Keep using it. But I could do without
> the ridiculous hatemails to my public-inbox. If aerc isn't for you,
> fine, no one is making you use it.

No problem, no problem -- sorry for my email having a sort of "hater"
tone. I guess I wasn't being particularly constructive, other than
pointing out what *appeared* to be your unfamiliarity with mutt, but
turned out to be deliberate and informed choices.

Re: Initial pre-release of aerc 11 months ago

From Joe Nelson to ~sircmpwn/public-inbox

TLDR; "The world's best email client" is a little premature. It pays to
invest some time learning how mature tools work rather than dismissing
them. http://www.mutt.org/doc/manual/

(But also, have fun creating stuff, sounds like a good learning
experience.)

> If you’re coming from mutt,

I am, and I'm not sure you're doing it justice.

> you’ll appreciate its more efficient & reliable networking

Can you elaborate? I fetch IMAP with mbsync into a directory tree in the

Re: Links between sites? 1 year, 7 months ago

From Joe Nelson to ~sircmpwn/sr.ht-discuss

William Casarin wrote:
> Does anyone else find it kind of awkward to navigate between the various
> subdomains? It would be nice if there were links between git/list/todo
> etc. Right now I have to jump into the url bar and do it manually.

Totally agree.
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C7CA82DDF-AE3E-4550-B1A6-EDF015807A14%40begriffs.com%3E

Re: Some sr.ht messages going to junk folder 1 year, 8 months ago

From Joe Nelson to ~sircmpwn/sr.ht-discuss

I condensed what we learned into an article so that perhaps other people will be encouraged to use mailing lists.

https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html

Re: Some sr.ht messages going to junk folder 1 year, 8 months ago

From Joe Nelson to ~sircmpwn/sr.ht-discuss

>> I think it's because it was not signed by DKIM. Thus it had to fall back to an
>> SPF check and that one failed alignment.
> 
> This seems unlikely, ProtonMail always signs outgoing messages with DKIM. I
> can't find the message you're referring to, can you point me to the lists.sr.ht
> link?

Aha, do you know what it was? The message was generated from https://todo.sr.ht/~sircmpwn/lists.sr.ht/49#comment-346

I'm guessing the message was created through the web interface, so there was no DKIM signature to relay.

Re: Some sr.ht messages going to junk folder 1 year, 8 months ago

From Joe Nelson to ~sircmpwn/sr.ht-discuss

> I'm fully satisfied in my understanding now, and see why DMARC's requirement that RFC5321.MailFrom == RFC5322.From is overzealous and broken.

The plot thickens! It turns out that DMARC checks alignment in two different ways:

1. For SPF, it checks that RFC5321.MailFrom == RFC5322.From
2. For DKIM, it checks that the message has one valid DKIM signature with "d=RFC5322.From".

(nice illustration: https://dmarcian.com/wp-content/uploads/2018/03/Header-Aligned.png)

Secondly, (and importantly!) DMARC will pass the message if *either* SPF or DKIM passes, and only fail the message if both SPF and DKIM fail. That way SPF-only and and DKIM-only messages can pass DMARC, but messages without either SPF/DKIM will always fail.

Thus I hypothesize that any domain which signs with DKIM will work fine on sr.ht even with DMARC enabled. As long as sr.ht does not modify the message in a way that breaks DKIM then it can continue to use proper From:, Sender: etc headers.

So what made that previous message I was talking about go to my spam folder? (For reference, it was message-id cmu-lmtpd-2726116-1536590260-0@sloti2d1t21) I think it's because it was not signed by DKIM. Thus it had to fall back to an SPF check and that one failed alignment.

Re: Some sr.ht messages going to junk folder 1 year, 8 months ago

From Joe Nelson to ~sircmpwn/sr.ht-discuss

> Ok, let's imagine every email is cryprographically signed by the author,
> and therefore cannot be forged.
> 
> Then, a mailing list is still possible. The list server:
> - takes a signed email it receives
> - prepends some headers like List-ID and Sender at the top,
>  before the part that is covered by a signature,
>  and leaves the From header intact
> - sends the resulting email to everyone subscribed

Nice point about List-ID. Many lists modify the subject line, prepending [foo] as identification, and this subject change violates DKIM if the subject is covered in the signature. Similarly some lists append unsubscribe links to the body of an email, but setting a List-Unsubscribe header instead can allow the body to remain unchanged.

> Then the receiving end:
> ...

Re: Some sr.ht messages going to junk folder 1 year, 8 months ago

From Joe Nelson to ~sircmpwn/sr.ht-discuss

>> what's to stop it from … impersonating me?
> 
> The DKIM signature.

Oh duh, we already determined that. I somehow lost sight of it.

Re: Some sr.ht messages going to junk folder 1 year, 8 months ago

From Joe Nelson to ~sircmpwn/sr.ht-discuss

> This isn't true, the email is *from* you. This is what the Sender header
> is for. The spec is very clear on this, DMARC is just bullshit.

Good point, the RFC does use the example of a boss and secretary, where the email is From the boss, but the Sender is the secretary. So the mailing list is playing the role of secretary in this case.

But tell me, if your server can send mail From me, what's to stop it from omitting the Sender header and simply writing to my friends and impersonating me? The internet used to be a cordial place for universities and research labs, and now it's an angry spam factory. The original RFCs were not designed for this scenario.