>> The open source eco-system has failed to produce useful alternatives to
>> Outlook/Exchange(Online) or GSuite.
>
> Never having had to use either in anger, or had the perspective of an SMB,
> what is missing from the open source offerings ?
Calendar. Calendar delegation. Calendar sharing.
> What I’ve said elsewhere is that what consumers, enterprises, and SMBs all
> need is a healthy selection of services from which to choose. The problem
> with the entry costs is that you have to be able to leverage a cloud
> infrastructure to play these days. That’s not cheap.
The main
Apparently ExchangeOnline is not adding the X-MS-Exchange-CrossTenant-* headers
any more. Lots of fun if you have tools in your outbound mail flow that
interact with multiple MS365 tenants and separates them based on the
X-MS-Exchange-CrossTenant-id header (amongst other use cases).
So far
>> How would it know the difference if it was Thunderbird, or the user?
>
> You can guess by timing.
>
> If the message is moved to spam folder immediately after being fetched by
> client, then it is an automated filter action. If there is at least a few
> seconds delay, then it is probably the
> I used Postfix along time but my experience is that it is incredible
> difficult to implement custom logic especially across the different
> binaries/processes it uses to fulfil a mail delivery transaction. Its
> designed in the "unix philosophy" and has good performance - great but
>
Does it produce a bounce?
We see cases where eg Recipient verification on MS365 customers simply does not
work (apparently depending on which cluster they are hosted). Instead of
rejecting with some 5xx it will bounce later.
— Matthias
Von meinem iPhone gesendet
> Am 20.10.2020 um 12:45
> S/MIME offers more traditional digital signatures using CA signed
> certificates. I would
> not call that widely deployed, I certainly have never seen it from any
> marketing/transactional
> mail, maybe once or twice from a medical insurance company. Support in mail
> clients is
> fairly
Mimecast is apparently sending from 185.58.84.0/24 (specifically
eu-smtp-delivery-42.mimecast.com / 185.58.84.42). This is not included in what
customers apparently have in their SPF records
("include:eu._netblocks.mimecast.com" and
"include:us._netblocks.mimecast.com“), with the obvious
> there is a feature in O365 that forwards mails (in/out/both..) to an
> archive-mailbox for long-term archiving.
>
> We grab this mails via pop. However our available mail-readers (Thunderbird,
> Kopano) show the original mail as attachment.
>
This is the „envelope wrapper“ format. It
For some of our clients who use MS365, we noticed that recipient verification
_sometimes_ fails (actually, it fails more than it succeeds). What I mean by
„fail“ (lightly edited for privacy reasons):
> > (EHLO and STARTTLS ...)
> < 220 2.0.0 SMTP server ready
> > EHLO (ourserver)
> < 250
At dnswl.org, we collect (DNS) logs to identify abusers of our service. During
last week, the logs increased by a factor of 10 (usually this is pretty stable,
going up an down a few percents), so we thought we’d investigate. And we found
something new (to us).
From one particular IPv6 range,
Experienced this as well. Customer mentioned this, and I did not believe him
until I checked myself…
— Matthias
> Am 14.06.2019 um 14:42 schrieb Stefan Bauer via mailop :
>
> Hi,
>
> can anyone confirm that I'm just blind or that this is not possible with
> Microsofts Exchange Online
12 matches
Mail list logo
