Jump to content

Keith Stevenson

Root Admin
  • Posts

    2,614
  • Joined

  • Last visited

  • Days Won

    40

Posts posted by Keith Stevenson

  1. @Nikolaj
    From the logs it appears that the one this monring (Subject like MailSweeper block Info) failed as 1 or more accounts have the same email address and therefore it cant find which customer to use..  (This was sent from your email address) . The previous email recieved (at 03:54 subject 31053 srv-dagt-o1 Down) was processed as expected 

    The fix for the first one is to ensure only 1 customer has the email address, 

    Kind Regards

    • Like 1
  2. All,
    The current permissions required for Microsoft OAuth are:

    • Mail.Read - Read User Mail
    • Mail.Read.All - Read User and Shared Mail
    • Mail.Read.Shared - Read User and Shared Mail
    • Mail.Send - Send Mail as a User
    • Mail.Send.All - Send Mail on behalf of others
    • Mail.Send.Shared - Send Mail on behalf of others
    • USer.Read - Read Users Profiles

    We are creating a new OAuth type which will remove the SEND requirement from the above for those customers who have stricter polices. 

    KInd Regards

    Hornbill Cloud Team 


     

  3. All,

    In their wisdom, Microsoft have decided to end "Legacy" support for User\Password authentication for POP3\IMAP on the 1st October 2022, forcing everyone to use OAuth.  If you are using Office365 you will need to change to this new Authentication Method or email will not be imported after this date. 


    The following details how

    https://wiki.hornbill.com/index.php?title=How_to_configure_OAuth2_Authentication_for_Microsoft_Office_365_Mailbox_integration

    Please change this before the 1st October 2022 to avoid disappointment

    Microsoft announcement - https://www.microsoft.com/en-us/microsoft-365/blog/2022/09/01/microsoft-retires-basic-authentication-in-exchange-online/

    Kind Regards

    Hornbill Cloud Team

    • Thanks 2
  4. Berto

    The below is a snippet of code that will reset all Out of Office every time its run (so next email will get reply) for all users.. This if scheduled sort of resolves yours issue periodically. However if you use Hornbill ITOM and on receiving an Out of Office message log a call, this can then fire an ITOM job\script which is a variation of the bellow to reset that users (as you have their email) out of office status in realtime so next time you email from this or another call it will get the OOO reply, the call then done can auto close itself

    [code]
    $enabled = Get-Mailbox -ResultSize Unlimited | Get-MailboxAutoReplyConfiguration | Where-Object {$_.AutoReplyState -eq "Enabled"} | Select-Object Identity, AutoReplyState
    $enabled | ForEach-Object {

    Set-MailboxAutoReplyConfiguration $_.Identity -AutoReplyState "Disabled"
    set-MailboxAutoReplyConfiguration $_.identity -AutoReplyState $_.AutoReplyState
    }

    [/code]

    ITOM solves all the problems and there would be other options available (including grabbing the Out of Office status and updating the Hornbill record either via script or future package) should you choose that route

    Kind Regards

    Hornbill Cloud Team 

  5. All,

    It appears that around 20% of all instances still have the system default of system.administrator@hornbill.com set against the Admin account. This address can be used to email notifications and if a Forgotten password request is made against the account. 

    We often see that this functionality being needed at times of SSO login failure when you need to revert to the Admin account and when used an email sent to the above address (which does not exist). 

    To prevent disappointment or delay in using this functionality you should change this to one of your own addresses. 

    Kind Regards

    Hornbill

    • Thanks 1
  6. Joshua, 
    Thanks for the post. 

    The Hornbill mail client will do the same every single time we send an email via direct outbound.  The rejection message stated is direct from MS (in this case). We have no control over this.  The fact that the email address isnt valid and then is would need to be investigated by the owner of that domain in collaboration with MS. 

    That said.. We have watched your traffic for a while and some DNS Probes for NX Lookup do return 0 (This is different to the specifc 550  error above which is still an MS Issue. ) - This appears to be due to a Cloudflare issue and intermittent. Which may explain why you see some emails fail to resolve domains and then work next pass. 

    This can be seen by doing 

    nslookup 
    server 1.1.1.1 

    set querytype=mx

    siwfinc.com

    if you run that several times you will get a timeout on 1 or more and the next time this is fine 

    if you change the domain to hornbill.com it seems to be fine and if you change server to 8.8.8.8 (googles) its also fine. 

    So it appears that you are seeing 2 different issues (1 hard failure - 550 which is the MS issue) and 1 intermittent and merging the two. These are 2 distinct and seperate errors. 


    Kind Regards

    Keith Stevenson

  7. Josuha
    Thanks for the post. Ive removed the attachments as they contain personal email addresses and this is an open forum.  The emails in the Failed Txt file failed dur to the recipient not existing on the given domain (hosted by MS) and when we try and deliver the email it returns the error  550 5.4.1 Recipient address rejected: Access denied.

    This is a MS\Recipient problem and not a Hornbill problem  (We perform the lookup get the MS server as MX record, connect and try to delivery this as expected) 

    We would suggest that you escalate this to the Domain Admin. 

    Kind Regards

    Keith Stevenson
     

  8. @Nikolaj
    From looking at the DB it appears that when this file was uploaded the comma was not encoded in the DB this will then break the download file name at that point. We can replicate this when the file attachment comes in via email (and is then attached to call.). Will get this resolved and post once fixed

    Kind Regards

    Keith Stevenson

    • Like 1
  9. @Nikolaj
    Are you referring to the signing of the email with DKIM?  This is the only reason I can see that would prevent your team from inserting the email footer in route (As we sign the email before). If so you can disable DKIM by going into the mailbox domain properties (Under Platform Configuration->Domains ).

    Kind Regards

    Keith Stevenson
     

    • Like 1
  10. Euan,
    Thanks for the post. We can see that from 1033-1101 emails failed to be sent as there was no SPF record for your domain when we did a TXT record lookup (In the code). By the time we looked at 1111 this was again working so unsure as to why it failed during that time. The check is very simple and very robust so unlikely to be a code issue. Did anyone make any changes to your SPF\TXT records today?

    Kind Regards
    Keith Stevenson

  11. Adrian,
    Thanks for the post. We can confirm that we can replicate the issue and are investigating. In the meantime you can load the report (dont go to the Data Preview tab), goto Output Formats , Check CSV , then go to Data Preview ... 

    Sadly we also note that the change in Output Format is not correctly saved so it will have to be re-done each time you wish to view the Data Preview.. We are also looking at this. 

    KInd Regards

    Keith Stevenson

    • Like 1
  12. All

    Please find below the RCA from Cloudflare 

    https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

    We have also reviewed our processes and given the nature of the error we do not believe we would act differently given same error. We have investigated having a domain that's not proxied via Cloudflare but the benefits this provides far outweigh the risk. (Workarounds existed if you wanted to add the IP of live or the forums to your hosts file and bypass cloudflare but this was a temporary solution and IPs are subject to change and we also considered having a second URL for the forums which didnt go through Cloudflare but how this would be remembered by Userbase and added confusion over URLs was considered, so having status.hornbill.com for ongoing critical issue updates is still preferred) 

    We would also strongly recommend that everyone follows status.hornbill.com and our Twitter feeds which do not go via Cloudflare and are completely separate to our infrastructure.  

    Kind Regards

    Keith Stevenson

    • Thanks 1
  13. All,
    Whilst we aim for 99.99% uptime, there are sometimes when the internet may not work as we hope. When this happens, normal support channels and sites may not be available. 

    You should therefore follow and subscribe to:

    https://status.hornbill.com/

    and follow us on Twitter 

    @Hornbill

    We will always post to the above even when the Forum or other support channels are unavailable. 

    Kind Regards
    Hornbill Cloud Team 

     

    • Like 1
  14. Dear All,
    This is indeed comming back. We use Cloudflare to cache all from end (none data ) in data centers closer to the end users to increase performance. Sadly it appears that Cloudflare this morning had a configuration issue that prevented routing from a number of their data centers and prevented us from logging in to their portal to Stop the proxying. 

    We are awaiting cloudflares update on the root cause but it does appear to be back for now. 


    Kind Regards

    Keith Stevenson

  15. All,
    The above patch has been deployed to all instances. This should resolve this issue (ERROR on fAQ1,h_type) and hopefully the other 2 issues people have reported this morning.. 

    Can I ask that if you are still suffering the other issues (NOT the FAQ1) that you post in the other existing threads so we dont confuse issues .

    Kind Regards

     

    • Like 2
×
×
  • Create New...