XSF Discussion - 2020-08-07

I am using the Office365 silo, and it always ends up in SPAM there

Alex: you could inspect the mail headers for why

probably SPF

I did, my assumption maybe SPF or other Email records

its coming from nicolas.verite@nayego.net, not sure if all the records are setup correctly at TinyLetter/Mailchimo

I also think it should come from an XSF domain

Me too jcbrand, Seve Do you agree that I head for to create an official CommTeam email?

it won’t solve the problem though

Do you also think I should reach out to tinynewsletter/mailchimp about that SPF?

they can’t do anything about that

that’d be useless if they could

The right thing to do is use an xmpp.org address and for us to add the SPF records

that might work

👍

and also allow mailchimp to spam on our behalf \o/

MattJ: Thanks

so the rightest thing to do is to deploy a subdomain for which we do that.

It was too troublesome to start the newsletter going through an XSF's email address just to try the concept out. But it looks like we are ready for an official address now :)

Ok. Yes. I am sure jcbrand will support that

xsf_commteam@ xmpp.org Seve jcbrand would that be okay for you as a potential adress?

I think newsletter@xmpp.org is nicer, or otherwise comms@xmpp.org

No need to have underscores in an email address 🙂

Agree re. underscores, though I think it would be good to use a subdomain as jonas’ suggested

Was about to say exactly those

👍

please no underscores

news@letter.xmpp.org? :)

Lets keep the email general and not sticked to a task. Then I think commteam@xmpp.org is good

jonas' no please not connected to a topic

emus, but the address needs special settings because it is used for a newsletter

Ah okay. And that is such a special setting that it should not be used for other email purposes?

yes

then make it newsletter@

@somesubdomain.xmpp.org

ok

hence my proposal news@letter.xmpp.org, since it’s fun

hmm... ok

but we can also do newsletter@bulk.xmpp.org or something like that

no, news@letter.xmpp.org is fine

jcbrand seve ?

Newsletter is one word, so news@letter seems weird to me. Do we accept replies on that address? Otherwise we can do noreply@newsletter.xmpp.org

Actually I think the convention is usually no-reply@... ✏

newsletter should go altogether in my opinion. Going with the no-reply seems the way to go?

jcbrand, no-reply sounds like a plan

since we won’t set up an inbound mailbox actually :)

Super!

Now if someone can write down on the iteam issue tracker exactly what DNS records need adding, I can look at it later or make sure jonas’ has access if he wants to

I'm fine with no-reply

but wait

If this is the registered email in Tinynewsletter ... will that be a problem to access the account?

If there is no inbound?

Because in TinyNewsletter, the email you register, is the email you spam the world with

At least it seem to be the case to me

MattJ, OK, I’ll try to figure out which records we need

There is only one field for Email. Nothing else, so I guess the email you put there is used for "everything"

Authentication-Results: mail.mdosch.de; dkim=pass header.d=mail4.tinyletterapp.com; spf=pass smtp.mailfrom=bounce-tl_1278521.8561570-spam-xmpp-org=mdosch.de@mail4.tinyletterapp.com X-Spamd-Bar: -

DKIM and SPF seem to be OK.

Uh, how exactly does it work?

https://tinyletter.zendesk.com/hc/en-us/articles/360006202814--Yahoo-and-AOL-changes-to-DMARC-may-affect-deliverability

Here are all headers: https://paste.debian.net/1159517/

Thanks Martin

Holger: the Q3 application period ends this week, lets go ;-) https://wiki.xmpp.org/web/Membership_Applications_Q3_2020

Link Mauve, !!

jonas' is that an issue to have this email as the account email then? because in the end they prevent us from using the account?

emus, I don’t quite get what you mean

jonas’, tinyletter sends from the email address you sign up with

for certain definitions of "from the email address"

ah, but you want to say the issue is that they’ll try to send transactional/account related email there?

They verify it, for starters, by sending you an email

Yes, thanks MattJ

Right now I don't see an obvious reason why it doesn't go to spam ~100% of the time

Also a point

flow: re: sometimes bare JID and no to not being equivalent - 191 requires that you send stuff with no to, instead of bare JID.

(Although I think it entirely reasonable, and even desirable, to ignore that restriction on the server and process either)

(I think it was you who asked for an example the other days, sorry if I misremember)

Hmm, would we benefit from a standard boilerplate text for such situations? I.e. situations when you can use either no 'to' or put our own bare JID into to in XEPs?

Kev, I also think it was me who asked btw

Digging around the EAX XEPs right now. XEP-EAX-CAR (E2E Authentication in XMPP: CA Requirements) is in inbox since february of 2019. The council protocols state that Board has to decide whether or not to accept this specification since it is procedural.

However, I fail to find any records of this board meeting.

https://mail.jabber.org/pipermail/standards/2019-February/035815.html

Are minutes of board meetings not send to standards@?

members@

Ah

Is it possible to access the members list archive?

yes, it’s as public as standards@

https://mail.jabber.org/pipermail/members/

I didnt find it as it is not listed on https://xmpp.org/community/mailing-lists.html

Thanks :)

Yeah, it's not *quite* as public, but almost.

Hm, I still fail to find any records of a board meeting that mentions XEP-EAX-CAR.

Weren't those retracted ?

Does retracting a XEP trigger a Mail to be send out by the editor?

not in protoxep stage

https://xmpp.org/extensions/xep-0084.html#proto-data

this is wrong i think

it says the data element IS ONLY for image/png

which would mean its impossible to publish other formats

or maybe it really means that

then why the fuck are we only allowed to publish image/png

That's really what it's saying, yes. To publish anything else you have to use external links. Why I couldn't say.

Well, presumably because everyone needs to do png in order to get interop.

thats fine, thats why it says, one of the info elements must be png/image

fine, why though are other info elements not allowed to store data in pubsub

that makes zero sense

further, there is zero possibility this can lead to any confusion

a client has to read the matadata info

it reads the image-typ, then readys the pubsub item id

it knows what it has to expect if it requests the content

the XEP text sounds to me like there is no metadata

or that the XEP can be used without metadata

then this rule makes sense

seems the XEP had this in there, store all kind of images in pubsub

but it was changed to only image/png with version 0.7

or course without any comment in the changelog why

i guess i will simply ignore this, as there is no reason or motiviation given in the XEP why only image/png should be stored