5.1.1

Instead of certifying a domain - can we certify specific email addressed ? The setting does not seem to work for that.We are using a DNS setting to send emails from Mailgun that appear as mg.pettingclub.com . However we cannot load the txt signature file to that domain because obviously the mail server is at Mailgun.So we tried instead to set the Individual Email Addresses settings, but any address we added to it - does not seem to work. Not info@pettingclub.com , nor any gmail address we tried. For example:550 5.1.1 Relay not allowed for <xxxxxxxxxx@privaterelay.appleid.com> from domain: <gmail.com>Is there a problem with setting up individual email addresses?

We are using Mailgun and are also not able to send to Apple Id users who use the email relay. We receive an error message as follows:Failed: postmaster@mg.pettingclub.com → xxxxxxx@privaterelay.appleid.com ...... Server response: 550 5.1.1 Relay not allowed for <xxxxxxxx@privaterelay.appleid.com> from domain: <mg.pettingclub.com>Can someone from Apple please respond whether Mailgun is supposed to work with apple relay?

I have enabled Build Libraries for Distribution and cleaned the build folder but i am still getting the Module compiled with Swift 5.1 cannot be imported by the Swift 5.1.1 compiler: /Users/oliviervincent/Documents/Spliqs/SpliqsAR/HelloWorld/AudioKit-iOS/AudioKit.framework/Modules/AudioKit.swiftmodule/arm64-apple-ios.swiftmodule error.What am I missing please?(using Xcode 11.2 beta 2)

We are experiencing a similar issue.Sending to a relay email address from an email address whitelisted under the Individual Email Addresses section of https://developer.apple.com/account/resources/services/configure, and with a 3rd party email sending service, bounces with a 500 / 5.1.1 bad mailbox name error.

Are you able to specify what aspect of third-party mail services prevents their use? We have DKIM and SPF set up for our whitelisted SIWA domain, but don't have a reverse DNS record set up for the IP we're using (a dedicated IP used primarily with a different domain), and are getting 550 5.1.1 bad mailbox name responses. It seems like a third-party mail service with a dedicated IP and rDNS would be indistinguishable - from privaterelay.appleid.com's point of view - from running our own MTA.We can certainly set up rDNS if that's a requirement, but otherwise this is a pretty big blocking restriction for SIWA.

what about Office365? My company's using office365 as email service provider, I've added several full emails in 'Individual Email Addresses' with green marks shown, but still failed with 5.1.0 - Unknown address error 550-'5.1.1 bad mailbox name'.The email address is memm9f2qh4@privaterelay.appleid.com

>all they need to do is install the app and log in.......What is the point of restoring anything?I believe all you need do is indicate in a note to App Review that you handle 'restore' through log in to your server. There is no need to do anything else.But......this means that the user is required to log into your server to 'use' the IAP. Therefore you will need to explain why you are also satisfying: 5.1.1 (v) Account Sign-In: If your app doesn’t include significant account-based features, let people use it without a log-in. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app.....

You may have another problem with:>Its a professionnal app, so accounts are pre-created on our side, there is no account creation.The problem is that Apple requires IAP to unlock code in an app. So they may want some assurance that those accounts do not require a payment of $100 and circumvent the 70/30 revenue split. Another relevant guideline is: 5.1.1 (v) Account Sign-In: If your app doesn’t include significant account-based features, let people use it without a log-in.....

The issue is not 'legally' it is 'app reveiw'. Your app is collecting (aka 'compiling') personal information of people who drive by the user of the app. Herein lies your rub - 5.1.1 (viii) Apps that compile personal information from any source that is not directly from the user or without the user’s explicit consent, even public databases, are not permittedYou could try this approach with app review:1) App review - the data saved by this app is based on publicly displayed license plate data. It is viewed and recorded by the user of the app. Therefore, upon recording, this data is the property of the user of the app not the owner of the license plate. The user of the app further clarifies their data by accessing a public database. The user of this app has given permission to compile this data. This app is not in violation of 5.1.1 (viii) because the data is obtained directly from the user with the user's explicit consent.(IMHO - App Review should reject the app because of 5.1.1 (viii

Please forgive the late reply, I've done some additional research during Spring Break here, and it's been instructive.Since we started this process, DisplayLink has released 5.1.1 of its kext, and the installer that they have posted is supposed to be notarized. Looking at the package:Persephone:Extensions tom$ spctl -a -t install -vvvv /Volumes/DisplayLink Installer/DisplayLink Software Installer.pkg /Volumes/DisplayLink Installer/DisplayLink Software Installer.pkg: accepted source=Notarized Developer ID origin=Developer ID Installer: DisplayLink Corp (73YQY62QM3)However, the package itself doesn't have a ticket stapled to it, which means that you must have access to the internet if you want it to install correctly. The spctl action itself isn't enough for you to know you have a viable package that will install offline. However, it appears that stapler can tell you:Persephone:Extensions tom$ stapler validate -v /Volumes/DisplayLink Installer/DisplayLink Software Installer.pkg Processing: /Volumes/Dis

>I didn't found any info in the guidelines about thisAre you sure? There are two parts to your proposal: ✖ login to access the App and ✖✖ use of OAuth2/restful (web session/simplified) token v. sign in/pwd.See the ASRG's section 5.1.1:(v) Account Sign-In: ✖ If your app doesn’t include significant account-based features, let people use it without a log-in. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law. If your core app functionality is not related to a specific social network (e.g. Facebook, WeChat, Weibo, Twitter, etc.), you must provide access without a login or via another mechanism. Pulling basic profile information, sharing to the social network, or inviting friends to use the app are not considered core app functionality. The app must also include a mechanism to revoke social network credentials and disable data access between the app and social network from within the app. ✖✖ An app