Przykro mi to stwierdzić, ale nie zamierzam dawać szczegółowego samouczka dotyczącego tworzenia wiadra S3 do przechowywania e-maili ani opisywać, jak stworzyć niezbędny klucz dostępu, który będzie potrzebny w aplikacji do przesyłania zawartości do twojego wiadra; istnieją lepsze poradniki na ten temat niż te, które kiedykolwiek mógłbym napisać.  Oto kilka artykułów, które mogą pomóc:

https://docs.aws.amazon.com/quickstarts/latest/s3backup/step-1-create-bucket.html
https://aws.amazon.com/blogs/security/wheres-my-secret-access-key/

To, co zrobię, to wskażę niektóre z ustawień, które wybrałem, odnoszące się do takiego projektu.

1. Kontrola dostępu.  Musisz nie tylko ustawić zabezpieczenia dla wiadra, ale także ustawić uprawnienia dla samych elementów.  W moim projekcie stosuję bardzo otwartą politykę publicznego odczytu, ponieważ przykładowe dane nie są osobiste i chciałem mieć łatwy dostęp do danych.  Prawdopodobnie będziesz chciał znacznie bardziej rygorystyczny zestaw zasad ACL. Oto dobry artykuł na temat ustawień ACL: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html

2. Archiwizowanie archiwum. W S3 istnieje coś takiego jak Zarządzanie cyklem życia.  Pozwala to na przenoszenie danych z jednego typu klasy przechowywania S3 do innej.  Różne klasy przechowywania reprezentują ilość dostępu, jakiego potrzebujesz do przechowywanych danych, przy niższych kosztach związanych z przechowywaniem, do którego masz najmniejszy dostęp. Dobry opis różnych klas i przechodzenia przez nie można znaleźć w przewodniku AWS o nazwie, Transitioning Objects. W moim przypadku wybrałem stworzenie cyklu życia, który przenosił każdy obiekt ze Standardu do Glacier po jednym roku. Dostęp do Glacier jest znacznie tańszy niż standardowe archiwum S3 i zaoszczędzi mi pieniądze na kosztach przechowywania.

Gdy mam utworzone wiadro S3 i moje ustawienia są na miejscu, S3 jest gotowe na przesłanie zgodnego z rfc822 e-maila, który uzyskałem z przepływu danych SparkPost Relay Webhook. Ale przed przesłaniem ładunku e-maila rfc822 do S3 muszę stworzyć unikalną nazwę pliku, której użyję do przechowywania tego e-maila.

Dla unikalnej nazwy pliku zamierzam przeszukać treść e-maila pod kątem ukrytego id, które aplikacja wysyłająca umieściła w e-mailu i użyć tego id jako nazwy pliku. Istnieją bardziej eleganckie sposoby na wyciągnięcie connectorId z treści html, ale dla prostoty i jasności zamierzam użyć następującego kodu:

$start = strpos($htmlbody, $inputField);
if ($start !== false) {
    $start = strpos($htmlbody, 'value="', $start);
    if ($start !== false) {
        $start += 7; // Move past 'value="'
        $end = strpos($htmlbody, '"', $start);
        if ($end !== false) {
            $length = $end - $start;
            $UID = substr($htmlbody, $start, $length);
        }
    }
}

* zakładamy, że $inputField zawiera wartość “ArchiveCode” i została znaleziona w moim pliku config.php.

Z UID, możemy potem stworzyć nazwę pliku, która zostanie użyta w S3:

$fileName = $ArchiveDirectory . '/' . $UID . '.eml';

Teraz mogę otworzyć połączenie z S3 i przesłać plik. Jeśli spojrzysz na plik s3.php w repozytorium GitHub, zobaczysz, że potrzeba bardzo mało kodu, aby przesłać plik.

Moim ostatnim krokiem jest zanotowanie tego wpisu w tabeli MYSQL.