Budowanie systemu archiwizacji e-maili: Przechowywanie treści e-maila

Przykro mi Cię rozczarować, ale nie zamierzam dawać szczegółowego samouczka na temat tworzenia wiadra S3 do przechowywania e-maili, ani nie zamierzam opisywać, jak stworzyć niezbędny klucz dostępu, który będziesz potrzebować w swojej aplikacji do przesyłania treści do swojego wiadra; są lepsze samouczki na ten temat, niż 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 zwrócenie uwagi na niektóre z ustawień, które wybrałem, dotyczących takiego projektu.

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

2. Archiwizowanie archiwum. W S3 jest coś, co nazywa się zarządzaniem cyklem życia.  Dzięki temu możesz przenieść dane z jednej klasy przechowywania S3 do innej.  Różne klasy przechowywania reprezentują stopień dostępu, jaki potrzebujesz do przechowywanych danych, przy niższych kosztach związanych z przechowaniem, do którego masz najmniejszy dostęp. Dobry opis różnych klas i przechodzenia przez nie można znaleźć w przewodniku AWS zatytułowanym Transitioning Objects. W moim przypadku zdecydowałem się stworzyć cykl życia, który przenosi każdy obiekt z Standard do Glacier po roku. Dostęp do Glacier jest znacznie tańszy niż standardowe archiwum S3 i pozwoli mi zaoszczędzić na kosztach przechowywania.

Gdy już stworzyłem wiadro S3 i ustawiłem moje parametry, S3 jest gotowe, abym mógł przesłać e-mail zgodny z rfc822, który uzyskałem z strumienia danych webhooka SparkPost Relay. Ale przed przesłaniem ładunku e-maila rfc822 do S3 muszę stworzyć unikalną nazwę pliku, którą użyję do przechowywania tego e-maila.

Dla unikalnej nazwy pliku zamierzam przeszukać treść e-maila w poszukiwaniu 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 pobranie 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 następnie utworzyć nazwę pliku, która będzie używana w S3:

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

Teraz mogę otworzyć moje 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 zarejestrowanie tego wpisu w tabeli MYSQL.