Some of our Destination partners have noticed .verifyACL files being uploaded to their S3 buckets along with Audience Manager data.
Our publishing process creates .verifyACL control files whenever it tries to put files in a S3 bucket.
There are two reasons for this:
- for buckets owned by partners/customers, we are setting "--acl bucket-owner-full-control" permission through the .verifyACL file into the destination path, to allow customers to give permission to the Adobe account
- we identify whenever the access to the destination path is not allowed due to invalid/expired credentials, so to be able to log a specific non-transient error. Based on that error, the process is optimized in two ways:
- It send data only to valid destinations, by thus avoiding copying TB of data to the publishers servers and performing multiple retries, with no chance of success.
- Periodically, we are setting destinations having no successful run in the last 6 months to run with periodicity to "Never".
We recommend that partners adapt their ingestion code to ignore the .verifyACL files. We cannot delete that file after creation, as it is used by multiple customers with owned S3 buckets in order to properly manage the lifecycle of files sent by Adobe, in their own buckets.