SES 生成的 AWS S3 MimeMessage 文件在被 java SDK 访问时导致 403答案

【问题标题】：AWS S3 MimeMessage files generated by SES cause 403 when accessed by java SDKSES 生成的 AWS S3 MimeMessage 文件在被 java SDK 访问时导致 403
【发布时间】：2018-06-05 20:15:03
【问题描述】：

所以我整天都在处理这个问题，但我似乎找不到这个问题的原因。

我在 SES 中有一个操作，它将特定子域中的所有电子邮件转发到特定存储桶。这些消息可以很好地下载，并且在控制台中交互时包含所有必要的信息，但无法通过使用 Java SDK 中的 getObject() 检索。

我可以确认 SDK 凭据正常工作，因为我可以从同一个存储桶下载其他文件，即使通过我的代码使用相同的密钥前缀。

这证明我的存储桶策略设置正确。处理 getObject 权限的条目如下所示：

{
    "Sid": "EmailsAccess",
    "Effect": "Allow",
    "Principal": "*",
    "Action": [
        "s3:DeleteObject",
        "s3:GetObject"
    ],
    "Resource": "arn:aws:s3:::foo-bucket-foo/foo-prefix-foo/*"
}

我确信问题的根本原因与所有者有关，因为在 SES 生成的每个文件中都将其定义为“aws-ses+publishing.us-east-1.prod”。为什么这会导致我的代码显示 403？有什么方法可以更改文件的所有者，还是有更优雅的解决方案？

【问题讨论】：

备用所有者正常，对象应该有ACL bucket-owner-full-control。您可能需要更多权限才能访问这些对象——可能是存储桶级别的s3:ListBucket，或者对象级别的s3:GetObjectAcl。推测，关于哪个权限，但我敢打赌，这个问题与权限有关——你的权限。
我可以确认他们缺少bucket-owner-full-control ACL。有什么方法可以配置 SES 来更改它，或者在上传文件时自动更改 ACL？

标签： amazon-web-services amazon-s3 sdk amazon-ses

【解决方案1】：

我发现问题在于 SDK 中使用的帐户与存储桶所有者是一组不同的帐户，并且没有查看这些特定消息的权限。

关注this guide 本来可以解决问题，但我们决定采用另一条路线并尝试使用存储桶所有者帐户登录。

【讨论】：