Am 15.01.24 um 07:54 schrieb Sebastian Nielsen via mailop:
That header is supposed to be attached by the originating MUA, and I don't
*think* transit MTAs are permitted to rewrite it...
Problem is, that when MUA or first MTA has a incorrect date set, the email
comes like last in inbox...
>>I do think it would be better to use a common key that could be used to
>>verify multiple signed user images, this way only one DNS record would need
>>to be published and the user's eMail address could be used as part of the
>>verification, sort of like how OpenVPN does this (I'm sketchy on
>> That header is supposed to be attached by the originating MUA, and I don't
>> *think* transit MTAs are permitted to rewrite it...
Problem is, that when MUA or first MTA has a incorrect date set, the email
comes like last in inbox... have seen emails set with 1970-01-01 00:00:00 Or,
even
- Original Message -
> From: "Sebastian Nielsen via mailop"
> Why is it a problem? The server ignores commands that it don't have capability
> for anyways.
>
> Only wonkiness of Samsung Mail (same in Microsoft Outlook), I have noticed, is
> that new email happens to arrive in the middle
> I envision this being a system for individual domains, ergo non-corporate
> domain owners.
> For domains with a few users, then it would require a DNS record per user yes.
That's interesting. It is, of course, easy to automate the addition
of DNS records, one per user, but then I
I envision this being a system for individual domains, ergo non-corporate
domain owners.
For domains with a few users, then it would require a DNS record per user yes.
For domains with many users, then it would be a corporation owning it, and thus
it would bear the logo for the corporation.
Let's Encrypt style automation will be necessary with a large
userbase, and even with a small userbase it will be very helpful.
How do you envision the DNS records being set up? Should there be
one DNS record for each user, or a shared DNS record with some sort
of a
I have sent this to Digicert and Entrust in a hope of creating a simple
certification BIMI process for individuals.
If this process becomes standardized, it could gain the same traction as Lets
Encrypt and eventually become free.
Remember how StartSSL had cheap code signing and SSL wildcard
Dnia 13.01.2024 o godz. 16:58:27 John Levine via mailop pisze:
>
> That's why it's not silly that BIMI tries only to show legit logos, even
> though
> it makes it impractical for anyone other than largish organizations.
Which brings us back to my original point - which you now have confirmed -
Ah, yep, thanks for catching that typo.
On 1/14/2024 4:56 PM, Andrew C Aitchison wrote:
On Sun, 14 Jan 2024, Mark Alley via mailop wrote:
This is anecdotal, but I think it illustrates even at a smaller scale
the persistent problem Microsoft currently has with their tenancy.
I did some quick
On Sun, 14 Jan 2024, Mark Alley via mailop wrote:
This is anecdotal, but I think it illustrates even at a
smaller scale the persistent problem Microsoft currently has
with their tenancy.
I did some quick perusal of the last month's data from our
email logs, and out of a total of 22,473
This is anecdotal, but I think it illustrates even at a smaller scale
the persistent problem Microsoft currently has with their tenancy.
I did some quick perusal of the last month's data from our email logs,
and out of a total of 22,473 external emails that contain a
.onmicrosoft.com
From a spam point of view, signing up for a domain is a barrier of entry
which some may consider too much trouble.
This may play into why there's a larger distribution of unwanted mail on
the freely-provided `*.onmicrosoft.com` subdomains.
--
Alex
According to Microsoft, they use the "onmicrosoft.com" domain name
for providing IMAP4 access, and as an SMTP fallback domain for
clients who don't have their own domain name:
Source:
> On Saturday 13/01/2024 at 3:59 pm, John Levine via mailop wrote:
> > It appears that Randolf Richardson, Postmaster via mailop
> > said:
> >>
> >>>
> >>> It might work to put a gold border around checked logos and a
> >>> black/red dashed
> >>> line around non-validated logos.
> >>
> >>
It appears that Russell Clemings via mailop said:
>"You can keep using the initial onmicrosoft.com domain even after you add
>your domain. It still works for email and other services, so it's your
>choice."
>
>... or am I misunderstanding?
>
>I'm tempted to block *. onmicrosoft.com completely but
You can, yes. But would anyone trust it?
I wouldn't.
Graeme
On 14 January 2024 17:49:36 Russell Clemings via mailop
wrote:
But
https://learn.microsoft.com/en-us/microsoft-365/admin/setup/domains-faq?view=o365-worldwide
says:
"You can keep using the initial onmicrosoft.com domain even
But
https://learn.microsoft.com/en-us/microsoft-365/admin/setup/domains-faq?view=o365-worldwide
says:
"You can keep using the initial onmicrosoft.com domain even after you add
your domain. It still works for email and other services, so it's your
choice."
... or am I misunderstanding?
I'm
Afternoon folks
Sadly we've how reached the point of silliness in the various sub-threads
of the recent original BIMI thread.
Unless anyone has anything new, valid, on-point and worthy of further
discussion, I'd suggest that we're done here.
Please think several times as to whether
On Saturday 13/01/2024 at 3:59 pm, John Levine via mailop wrote:
It appears that Randolf Richardson, Postmaster via mailop
said:
It might work to put a gold border around checked logos and a
black/red dashed
line around non-validated logos.
That's actually a better solution than what I
On 13 January 2024 14:07:46 "L. Mark Stone via mailop"
wrote:
Is there a list of "legitimate" subdomains of onmicrosoft.com somewhere
that we can leverage?
Wearing my "I have to administer a Microsoft 365 tenancy" hat - no.
However, your mention of best practice is bang on. The subdomains of
Dňa 14. januára 2024 7:55:13 UTC používateľ Bastian Blank via mailop
napísal:
>On Sat, Jan 13, 2024 at 07:44:22PM +, Slavko via mailop wrote:
>> Dňa 13. januára 2024 19:14:58 UTC používateľ Sebastian Nielsen via mailop
>> napísal:
>> >Then you need to reconfigure server to ignore said
On Sat, Jan 13, 2024 at 07:44:22PM +, Slavko via mailop wrote:
> Dňa 13. januára 2024 19:14:58 UTC používateľ Sebastian Nielsen via mailop
> napísal:
> >Then you need to reconfigure server to ignore said parameters.
> IMO, in other words, server (SHOULD reject) is RFC compliant, client
> is
23 matches
Mail list logo
