Feedback by UserVoice

Mikko

My feedback

  1. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Office 365 Admin » Exchange Admin  ·  Flag idea as inappropriate…  ·  Admin →
    Mikko supported this idea  · 
  2. 27 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Mikko supported this idea  · 
  3. 61 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Mikko supported this idea  · 
  4. 9 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Office 365 Admin Mobile  ·  Flag idea as inappropriate…  ·  Admin →
    Mikko supported this idea  · 
  5. 16 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Office 365 Admin » Exchange Admin  ·  Flag idea as inappropriate…  ·  Admin →
    Mikko supported this idea  · 
  6. 351 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    14 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Mikko supported this idea  · 
  7. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Well, this shows that there's plenty of room for competing solutions still...

  8. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    This would be a real bother to implement due to how printer drivers work. Microsoft could probably do this with the Microsoft official PDF print tool, but not with those made by others. And that's just local printers, anything on a server is going to be even more difficult.

  9. 33 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Um. In the "mail flow" rules, there's a "The message has an SCL greater than or equal to" condition available already.

    I've used this to do a multi-stage filter for a customer.

    However, the per-mailbox ("inbox" rules) side doesn't seem to have that directly available, which is a bother.

    I made some transport rules to add custom headers based on the SCL steps used that are easier to check for in the per-mailbox stage.

  10. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Really not this simple, this needs to be configurable by mailbox instead of a hard rule.

    While the boss / secretary case is probably valid as such, consider also the case of a customer-service mailbox with potentially sensitive customer data.

    I believe the customer-service mailbox needs to have at a minimum an Azure Information Protection license, right? That means it'll have to be a "user" mailbox with a license attached and not a "shared" mailbox, even if it's mostly used like a shared mailbox.

    Even so, whoever of the customer service workers happens to be on duty may need to be able to read those.

    Therefore, needs to be configurable.

  11. 26 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Well...

    From https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/Encrypt-only-rolling-out-starting-today-in-Office-365-Message/ba-p/162718 dated Feb 22, 2018:

    "The inline reading experience for Outlook desktop (Windows and Mac) will be available in the coming months. In the meantime, Office 365 users using Outlook desktop will see the encrypted mail as an html mail with an rpmsg_v2 attachment."

    So, which release channel are you on?

    Though I don't see this mentioned even for the monthly channel yet, so...

    https://technet.microsoft.com/en-us/office/mt465751.aspx

  12. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Not really about the OneDrive for Business specifically I guess, as long as there'll be an option to archive *somewhere*...? (Would a mailbox interface with server-side decrypt be secure enough?)

  13. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Hm, probably need the rules engine to be able to handle S/MIME at least for a bit, first.

    Right now it can't even tell S/MIME signed/clear apart from encrypted... much less decide on keys for sign/encrypt, where signing obivously needs to have sender keys unlocked on the server and...

  14. 2 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Seen this kind of problem even between E3 users, absent the exact error message can't be sure if it's the exact same one.

    I think this may not belong in "Message Encryption & Rights Management", though.

  15. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko supported this idea  · 
  16. 18 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    The part about detecting multiple external domains might be possible with current rules engine, but probably would require a complicated regexp match.

    However, once you have that, you could use it to cause the message to be rejected.

  17. 2 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Um. Like the "Activate this rule on the following date:" and "Deactivate this rule on the following date:" options that are already there?

    Those do work already even if they don't autocomment themselves... don't remember checking if they do but would expect not

  18. 53 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Server-side rules are able to designate mail as spam / not spam already.

    You can also assign the otherwise unused spamminess levels of 2-4 that way and use them, as well as do conditional processing via editing headers.

    It may not be optimal but it's better than not being able to do that at all.

    Also please make the distinction between server-level (Exchange admin -> Mail flow) and individual (Inbox) rules, to avoid confusion.

  19. 43 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    The link in the comment dated Ocr 27, 2015 seems to be dead.

    For the usage case where the mail is supposed to be delivered to an encryption-unaware application, the server-side decryption is an important requirement. This should be possible at least for mails sent from the same tenant, as well as replies by externals made in the encryption portal web interface.

    Application-type recipients are usually on IMAP or the like, too - no MAPI or Outlook-specific features.

    As of right now this works in the "old" OME but not OMEv2. Therefore anyone who needs this is unable to move to OMEv2. Please provide a way to enable this for compatibility.

  20. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mikko commented  · 

    Which encryption scheme would this be?

    Sent mails aren't usually processed through the server, they're just stored. For server-side encryption to do this, you'd need to replace "save to 'sent' folder" by "BCC to $self, rule-based move incoming messages sent by $self to 'sent' folder".

    A message to several recipients may be delivered encrypted to some of them and clear to some.
    Also if it's OME or OMEv2 and the server allows anyone to request a login link with one-time codes if they have access to the mailbox (like it now seems to do), messages encrypted by that system are also compromised if the account is breached.

    So, the behavior needs to be configurable. (It also tends to work right already if using an external encryption solution.)

← Previous 1

Feedback and Knowledge Base