How to handle business email on gdpr compliance

# /etc/dovecot/dovecot.conf

protocol lda {
  mail_plugins = ... expire
}

protocol imap {
  mail_plugins = ... expire
}

Next, configure the `expire` plugin:

# /etc/dovecot/conf.d/90-plugin.conf

plugin {
  expire = Trash 30d
  expire2 = "Archive 365d" delete
}

Explanation:

• `expire = Trash 30d`: This setting automatically deletes emails from the “Trash” folder after 30 days.
• `expire2 = “Archive 365d” delete`: This setting moves emails older than 365 days to the “Archive” folder and then permanently deletes them. (The exact folder name might vary depending on your configuration.)

You may need to create the “Archive” folder if it doesn’t already exist. Restart Dovecot after making these changes:

sudo systemctl restart dovecot

This is a basic example. You can customize the `expire` plugin to handle different folders and retention periods based on your specific needs. Example: Using a scripting approach for email archiving You can also implement automated archiving and deletion using scripting. Here’s an example using `offlineimap` and a Python script. First, configure `offlineimap` to synchronize your email account. Then, create a Python script to identify and move emails based on their age.

# Python script (archive_emails.py)
import imaplib
import email
import datetime
import os

EMAIL_ACCOUNT = "your_email@example.com"
PASSWORD = "your_password"
ARCHIVE_FOLDER = "Archive"
RETENTION_PERIOD_DAYS = 365

def archive_old_emails(email_account, password, archive_folder, retention_period_days):
    mail = imaplib.IMAP4_SSL("imap.example.com")  # Replace with your IMAP server
    mail.login(email_account, password)
    mail.select("INBOX")

    cutoff_date = datetime.datetime.now() - datetime.timedelta(days=retention_period_days)
    cutoff_date_str = cutoff_date.strftime("%d-%b-%Y")  # e.g., 01-Jan-2023

    search_criteria = f'BEFORE {cutoff_date_str}'
    result, data = mail.search(None, search_criteria)

    for email_id in data[0].split():
        result, email_data = mail.fetch(email_id, "(RFC822)")
        raw_email = email_data[0][1]
        email_message = email.message_from_bytes(raw_email)

        # Move the email to the Archive folder
        mail.copy(email_id, archive_folder)
        mail.store(email_id, "+FLAGS", "\\Deleted")  # Mark for deletion

    mail.expunge()  # Permanently delete marked emails
    mail.close()
    mail.logout()

if __name__ == "__main__":
    archive_old_emails(EMAIL_ACCOUNT, PASSWORD, ARCHIVE_FOLDER, RETENTION_PERIOD_DAYS)

This script connects to your IMAP server, searches for emails older than the retention period, copies them to the “Archive” folder, marks them for deletion in the inbox, and then expunges them (permanently deletes them). Schedule this script to run regularly using `cron`. Caution: Backups should also adhere to these retention policies. If backups contain email data, ensure that old backups are regularly purged to comply with GDPR. Simply deleting the email from the live system isn’t enough if it remains in a backup.

Data Minimization

In addition to setting retention periods, GDPR emphasizes data minimization. This means only collecting and retaining the minimum amount of personal data necessary for your legitimate purposes. Regularly review your email practices to identify and eliminate unnecessary data collection. For example:

• Avoid collecting excessive information in email signup forms. Only ask for the information you truly need (e.g., email address, name).
• Don’t store email attachments unnecessarily. If you only need the information contained in the attachment, extract the information and store it separately, then delete the attachment.
• Anonymize or pseudonymize email data where possible. If you don’t need to identify individuals, consider anonymizing their email addresses.

By minimizing the amount of personal data you collect and retain, you reduce the risk of data breaches and simplify your GDPR compliance efforts.

Handling Subject Access Requests (SARs) for Email Data

Under GDPR, individuals have the right to access their personal data that you hold. This includes email data. Responding to Subject Access Requests (SARs) efficiently and accurately is a crucial aspect of GDPR compliance. This section outlines the technical steps involved in fulfilling SARs related to email data.

Identifying and Locating Email Data

The first step in responding to a SAR is to identify and locate all email data related to the individual making the request. This can be a complex task, especially if you have a large email archive. Consider these steps:

• Search your live email system. Search all mailboxes for emails sent to or from the individual’s email address.
• Search your email archive. Search your email archive for emails related to the individual. This may require using specialized search tools provided by your archiving system.
• Search your email backups. If you have email backups, you may need to restore them to a temporary environment to search for relevant data.
• Consider other systems that may contain email data. For example, your CRM system may store copies of emails exchanged with customers.

Example: Searching a Maildir-based email archive using `grep` If your email archive is stored in Maildir format, you can use `grep` to search for emails containing a specific email address.

grep -r "user@example.com" /path/to/email/archive

This command will recursively search all files in the `/path/to/email/archive` directory for the string “user@example.com”. The output will show the filenames and the lines containing the email address. However, this approach is limited. It only searches for exact matches of the email address. You may need to use more sophisticated search tools to find emails that mention the individual in other ways (e.g., by name).

Reviewing and Redacting Email Data

Once you’ve located the relevant email data, you need to review it to ensure that it doesn’t contain any information that you’re not allowed to disclose. This includes:

• Personal data of other individuals. You need to redact any personal data of other individuals mentioned in the emails (e.g., names, email addresses, phone numbers).
• Confidential business information. You may need to redact confidential business information that is not relevant to the individual’s request.
• Information subject to legal privilege. You may need to redact information that is subject to legal privilege (e.g., communications with your lawyers).

Example: Redacting email content using a text editor You can use a text editor like `sed` to redact sensitive information from email content.

sed 's/sensitive information/[REDACTED]/g' email.txt > redacted_email.txt

This command will replace all occurrences of “sensitive information” with “[REDACTED]” in the `email.txt` file and save the redacted content to `redacted_email.txt`. For more complex redaction tasks, you may need to use specialized redaction software. Important: Document all redactions and the reasons for them. This will help you justify your decisions if challenged.

Providing the Data to the Requestor

After reviewing and redacting the email data, you need to provide it to the individual making the request. GDPR requires that you provide the data in a commonly used electronic format. Consider these options:

• Provide the emails as individual `.eml` files. This is a common format for storing email messages.
• Provide the emails as a `.mbox` file. This is another common format for storing multiple email messages in a single file.
• Provide the emails in a PDF format. This can be useful if you need to ensure that the formatting of the emails is preserved.

Ensure that the data is securely transmitted to the individual, for example, by using encryption or a secure file transfer service. Example: Creating a `.zip` archive containing `.eml` files

zip -r email_data.zip /path/to/eml/files

This command will create a `.zip` archive named `email_data.zip` containing all the `.eml` files in the `/path/to/eml/files` directory. Always password-protect the `.zip` archive and provide the password to the individual separately. Remember to respond to SARs within the timeframe specified by GDPR (usually one month).

Business Email and GDPR Compliance: A Technical Guide

Navigating the intricacies of the General Data Protection Regulation (GDPR) can be challenging for businesses, especially when it comes to email communication. This article provides a focused technical guide to help you understand and implement GDPR-compliant practices for your business email systems. We will explore specific aspects such as consent management, data encryption, data retention policies, and Subject Access Requests, providing actionable examples and configurations.

Consent Management for Email Marketing and Communications

One of the cornerstones of GDPR is obtaining explicit consent from individuals before processing their personal data, including their email address. This section focuses on the technical aspects of implementing consent management within your email marketing and communication systems. It’s not enough to simply have a pre-checked box on a signup form; you need to demonstrate a clear affirmative action from the user.

Implementing Double Opt-In

Double opt-in is a crucial best practice for GDPR compliance. It requires users to confirm their email address after initially subscribing. This ensures that the email address is valid and that the user genuinely intends to receive communications. Example: Using a transactional email service for double opt-in Let’s say you’re using a transactional email service like SendGrid or Mailgun to handle your double opt-in process. Here’s a simplified example of how you might implement this.

# Python example using the SendGrid API

import sendgrid
import os
from sendgrid.helpers.mail import Mail, Email, To, Content

sg = sendgrid.SendGridAPIClient(api_key=os.environ.get('SENDGRID_API_KEY'))
from_email = Email("your_email@example.com")
to_email = To("user_email@example.com") # Replace with user's email
subject = "Confirm Your Subscription"
content = Content("text/plain", "Please click the following link to confirm your subscription: https://example.com/confirm?token=UNIQUE_TOKEN") # Replace with your confirmation link
mail = Mail(from_email, to_email, subject, content)

response = sg.client.mail.send.post(request_body=mail.get())
print(response.status_code)
print(response.body)
print(response.headers)

In this example:

• We use the SendGrid API to send a confirmation email.
• The email contains a unique token embedded in a confirmation link.
• When the user clicks the link, your application verifies the token and confirms their subscription.
• You should generate and store the token securely associated with the user’s email in your database.

Storing and Managing Consent Data

You need to maintain a record of the consent you’ve obtained from each individual, including when they gave consent and what they consented to. This data must be stored securely and be easily accessible. Example: Database schema for consent tracking Consider the following database schema (using PostgreSQL as an example) to store consent information:

CREATE TABLE consent_records (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL,
    consent_type VARCHAR(255) NOT NULL, -- e.g., 'newsletter', 'marketing'
    consent_given BOOLEAN NOT NULL,
    consent_date TIMESTAMP WITHOUT TIME ZONE NOT NULL,
    ip_address VARCHAR(39), -- Store IP address for audit trail
    user_agent TEXT,         -- Store User-Agent string for audit trail
    withdrawal_date TIMESTAMP WITHOUT TIME ZONE NULL -- When consent was withdrawn
);

This schema allows you to:

• Track different types of consent (e.g., consent for newsletters vs. targeted advertising).
• Record the exact date and time consent was given.
• Store the IP address and User-Agent string associated with the consent action for auditing purposes.
• Track when consent was withdrawn.

Example: Recording consent when a user subscribes

# Python example using SQLAlchemy to interact with the database

from sqlalchemy import create_engine, Column, Integer, String, DateTime, Boolean
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
from datetime import datetime
import os

# Database connection details (replace with your actual credentials)
DATABASE_URL = os.environ.get("DATABASE_URL", "postgresql://user:password@host:port/database")

engine = create_engine(DATABASE_URL)
Base = declarative_base()

class ConsentRecord(Base):
    __tablename__ = "consent_records"

    id = Column(Integer, primary_key=True)
    email = Column(String(255), nullable=False)
    consent_type = Column(String(255), nullable=False)
    consent_given = Column(Boolean, nullable=False)
    consent_date = Column(DateTime, nullable=False)
    ip_address = Column(String(39))
    user_agent = Column(String)
    withdrawal_date = Column(DateTime, nullable=True)

Base.metadata.create_all(engine)

Session = sessionmaker(bind=engine)
session = Session()

def record_consent(email, consent_type, ip_address, user_agent):
    new_consent = ConsentRecord(
        email=email,
        consent_type=consent_type,
        consent_given=True,
        consent_date=datetime.utcnow(),
        ip_address=ip_address,
        user_agent=user_agent
    )
    session.add(new_consent)
    session.commit()

# Example usage (assuming you have the user's email, IP address, and User-Agent)
record_consent(email="user_email@example.com", consent_type="newsletter", ip_address="192.168.1.1", user_agent="Mozilla/5.0...")

This code snippet demonstrates how to insert a new consent record into the database when a user subscribes. It captures the email address, consent type, date, IP address, and User-Agent string.

Providing Easy Withdrawal of Consent

GDPR mandates that users should be able to withdraw their consent as easily as they gave it. This means providing a clear and straightforward mechanism for unsubscribing from email lists or opting out of specific types of communication. Example: Implementing one-click unsubscribe A simple and effective approach is to include a one-click unsubscribe link in every email. This link should lead to a page where the user’s email address is automatically recognized and they can confirm their unsubscription with a single click. Avoid requiring users to log in or navigate through multiple pages to unsubscribe.

<a href="https://example.com/unsubscribe?email=user_email@example.com&token=UNIQUE_UNSUBSCRIBE_TOKEN">Unsubscribe</a>

The unsubscribe link should include:

• The user’s email address (properly URL-encoded).
• A unique unsubscribe token to prevent unauthorized unsubscriptions. This token should be stored securely in your database and associated with the user’s email address.

When the user clicks the link, your application should:

• Verify the unsubscribe token.
• Update the consent record in your database to reflect the withdrawal of consent (e.g., set `consent_given` to `false` and update `withdrawal_date`).
• Immediately stop sending emails to the user.

Expert Tip: “Always test your unsubscribe process thoroughly. A broken unsubscribe link is a major GDPR violation and can damage your reputation.”

Data Encryption and Security for Email Communications

GDPR mandates that personal data must be processed in a manner that ensures appropriate security, including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage. Encryption is a fundamental technique for achieving this level of security for email communications. This section covers various encryption methods and security best practices.

Transport Layer Security (TLS)

TLS is the most basic form of encryption for email in transit. It encrypts the connection between email servers, preventing eavesdropping while the email is being transmitted. Most modern email servers support TLS, but it’s crucial to configure your server to *require* TLS for all outbound connections whenever possible. Example: Configuring Postfix to enforce TLS To enforce TLS in Postfix, you can modify the `main.cf` configuration file:

# /etc/postfix/main.cf

smtp_tls_security_level = encrypt
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_ciphers = high

Explanation:

• `smtp_tls_security_level = encrypt`: This setting tells Postfix to attempt to negotiate a TLS connection with the receiving server. If TLS is not available, the email will still be sent unencrypted. For stricter enforcement, use `smtp_tls_security_level = mandatory`. However, be aware that this may prevent delivery to servers that don’t support TLS.
• `smtp_tls_mandatory_protocols = !SSLv2, !SSLv3`: This disables the outdated and insecure SSLv2 and SSLv3 protocols.
• `smtp_tls_mandatory_ciphers = high`: This setting forces Postfix to use only strong encryption ciphers.

After making these changes, restart Postfix:

sudo systemctl restart postfix

To verify that TLS is working correctly, you can check the Postfix logs:

grep "TLS connection established" /var/log/mail.log

You should see entries indicating that TLS connections were successfully established with other servers.

End-to-End Encryption with S/MIME or PGP

While TLS encrypts the email in transit, it doesn’t protect the email once it reaches the recipient’s server. For true end-to-end encryption, you need to use S/MIME or PGP. These methods encrypt the email content itself, so only the intended recipient with the correct private key can decrypt it. Example: Using GPG (GNU Privacy Guard) for PGP encryption First, generate a PGP key pair:

gpg --gen-key

Follow the prompts to create your key. Make sure to choose a strong passphrase. To encrypt an email using GPG:

gpg --encrypt --recipient recipient@example.com email.txt

This will create an encrypted file named `email.txt.gpg`. You can then send this file as an attachment. The recipient will need your public key and their own private key to decrypt it. To export your public key:

gpg --armor --export recipient@example.com > public.key

The recipient will need to import your public key into their GPG keyring:

gpg --import public.key

Finally, to decrypt the email:

gpg --decrypt email.txt.gpg

They will be prompted for their passphrase. Note: Implementing S/MIME or PGP requires both the sender and recipient to have the necessary software and keys. It’s not a transparent solution like TLS.

Data Loss Prevention (DLP)

DLP systems can help prevent sensitive data from being accidentally or intentionally leaked via email. They work by scanning email content and attachments for specific keywords, patterns, or file types, and then taking action based on predefined rules (e.g., blocking the email, encrypting the email, or notifying an administrator). Example: Configuring a basic DLP rule with a mail filter (e.g., using `procmail`) While a full DLP system is more complex, you can implement basic DLP rules using mail filters like `procmail`. Create a `.procmailrc` file in your user’s home directory:

# ~/.procmailrc

:0:

B ??(SSN|Social Security Number)

{
  :0 w
  ! admin@example.com  # Notify admin

  :0:
  /dev/null             # Discard the email (or move to a quarantine folder)
}

Explanation:

• `:0:`: Start of a procmail recipe.
• `* B ??(SSN|Social Security Number)`: This is the condition. It searches the email body (`B`) for the strings “SSN” or “Social Security Number”. The `??` makes the search case-insensitive.
• `{ … }`: The action to take if the condition is met.
• `:0 w ! admin@example.com`: Forward a copy of the email to `admin@example.com` (with the `w` flag, which means “write” – keep processing the email).
• `:0: /dev/null`: Discard the email (or you could move it to a quarantine folder).

This is a very basic example. Real-world DLP rules are much more sophisticated and use regular expressions to accurately identify sensitive data. Quote: “Encryption is not just a technical requirement of GDPR; it’s a fundamental principle of data protection. Protecting data at rest and in transit is crucial for maintaining the confidentiality and integrity of personal information.” – Dr. Ann Cavoukian, Privacy by Design Centre of Excellence.

Data Retention Policies for Email Archives and Backups

GDPR requires that personal data be kept for no longer than is necessary for the purposes for which it was collected. This necessitates the implementation of clear and enforceable data retention policies for your email archives and backups. This section explores how to design and implement such policies.

Defining Retention Periods

The first step is to determine how long you need to retain different types of email data. This will depend on various factors, including legal requirements, regulatory obligations, and business needs. Consider these factors:

• Legal requirements: Certain laws may require you to retain specific types of email for a certain period (e.g., financial records, contracts).
• Regulatory obligations: Industry-specific regulations (e.g., HIPAA for healthcare) may impose data retention requirements.
• Business needs: Consider how long you need to retain email for operational purposes, such as customer service, project management, or dispute resolution.

Create a data retention schedule that specifies the retention period for each type of email data. For example:

Email Type	Retention Period	Justification
Customer invoices	7 years	Legal requirement (tax law)
Customer support emails	2 years	Business need (customer service)
Marketing newsletters	Until user unsubscribes	Consent-based
Employee performance reviews	3 years	Legal and HR requirements

Automated Archiving and Deletion

Once you’ve defined your retention periods, you need to implement automated mechanisms to archive and delete email data according to your schedule. This requires configuring your email archiving system to automatically move older emails to a separate archive and then permanently delete them after the retention period expires. Example: Configuring Dovecot for automated archiving Dovecot is a popular IMAP/POP3 server. You can use the `dovecot-expire` plugin to automate email archiving and deletion. First, enable the `expire` plugin in your Dovecot configuration:

# /etc/dovecot/dovecot.conf

protocol lda {
  mail_plugins = ... expire
}

protocol imap {
  mail_plugins = ... expire
}

Next, configure the `expire` plugin:

# /etc/dovecot/conf.d/90-plugin.conf

plugin {
  expire = Trash 30d
  expire2 = "Archive 365d" delete
}

Explanation:

• `expire = Trash 30d`: This setting automatically deletes emails from the “Trash” folder after 30 days.
• `expire2 = “Archive 365d” delete`: This setting moves emails older than 365 days to the “Archive” folder and then permanently deletes them. (The exact folder name might vary depending on your configuration.)

You may need to create the “Archive” folder if it doesn’t already exist. Restart Dovecot after making these changes:

sudo systemctl restart dovecot

This is a basic example. You can customize the `expire` plugin to handle different folders and retention periods based on your specific needs. Example: Using a scripting approach for email archiving You can also implement automated archiving and deletion using scripting. Here’s an example using `offlineimap` and a Python script. First, configure `offlineimap` to synchronize your email account. Then, create a Python script to identify and move emails based on their age.

# Python script (archive_emails.py)
import imaplib
import email
import datetime
import os

EMAIL_ACCOUNT = "your_email@example.com"
PASSWORD = "your_password"
ARCHIVE_FOLDER = "Archive"
RETENTION_PERIOD_DAYS = 365

def archive_old_emails(email_account, password, archive_folder, retention_period_days):
    mail = imaplib.IMAP4_SSL("imap.example.com")  # Replace with your IMAP server
    mail.login(email_account, password)
    mail.select("INBOX")

    cutoff_date = datetime.datetime.now() - datetime.timedelta(days=retention_period_days)
    cutoff_date_str = cutoff_date.strftime("%d-%b-%Y")  # e.g., 01-Jan-2023

    search_criteria = f'BEFORE {cutoff_date_str}'
    result, data = mail.search(None, search_criteria)

    for email_id in data[0].split():
        result, email_data = mail.fetch(email_id, "(RFC822)")
        raw_email = email_data[0][1]
        email_message = email.message_from_bytes(raw_email)

        # Move the email to the Archive folder
        mail.copy(email_id, archive_folder)
        mail.store(email_id, "+FLAGS", "\\Deleted")  # Mark for deletion

    mail.expunge()  # Permanently delete marked emails
    mail.close()
    mail.logout()

if __name__ == "__main__":
    archive_old_emails(EMAIL_ACCOUNT, PASSWORD, ARCHIVE_FOLDER, RETENTION_PERIOD_DAYS)

This script connects to your IMAP server, searches for emails older than the retention period, copies them to the “Archive” folder, marks them for deletion in the inbox, and then expunges them (permanently deletes them). Schedule this script to run regularly using `cron`. Caution: Backups should also adhere to these retention policies. If backups contain email data, ensure that old backups are regularly purged to comply with GDPR. Simply deleting the email from the live system isn’t enough if it remains in a backup.

Data Minimization

In addition to setting retention periods, GDPR emphasizes data minimization. This means only collecting and retaining the minimum amount of personal data necessary for your legitimate purposes. Regularly review your email practices to identify and eliminate unnecessary data collection. For example:

• Avoid collecting excessive information in email signup forms. Only ask for the information you truly need (e.g., email address, name).
• Don’t store email attachments unnecessarily. If you only need the information contained in the attachment, extract the information and store it separately, then delete the attachment.
• Anonymize or pseudonymize email data where possible. If you don’t need to identify individuals, consider anonymizing their email addresses.

By minimizing the amount of personal data you collect and retain, you reduce the risk of data breaches and simplify your GDPR compliance efforts.

Handling Subject Access Requests (SARs) for Email Data

Under GDPR, individuals have the right to access their personal data that you hold. This includes email data. Responding to Subject Access Requests (SARs) efficiently and accurately is a crucial aspect of GDPR compliance. This section outlines the technical steps involved in fulfilling SARs related to email data.

Identifying and Locating Email Data

The first step in responding to a SAR is to identify and locate all email data related to the individual making the request. This can be a complex task, especially if you have a large email archive. Consider these steps:

• Search your live email system. Search all mailboxes for emails sent to or from the individual’s email address.
• Search your email archive. Search your email archive for emails related to the individual. This may require using specialized search tools provided by your archiving system.
• Search your email backups. If you have email backups, you may need to restore them to a temporary environment to search for relevant data.
• Consider other systems that may contain email data. For example, your CRM system may store copies of emails exchanged with customers.

Example: Searching a Maildir-based email archive using `grep` If your email archive is stored in Maildir format, you can use `grep` to search for emails containing a specific email address.

grep -r "user@example.com" /path/to/email/archive

This command will recursively search all files in the `/path/to/email/archive` directory for the string “user@example.com”. The output will show the filenames and the lines containing the email address. However, this approach is limited. It only searches for exact matches of the email address. You may need to use more sophisticated search tools to find emails that mention the individual in other ways (e.g., by name).

Reviewing and Redacting Email Data

Once you’ve located the relevant email data, you need to review it to ensure that it doesn’t contain any information that you’re not allowed to disclose. This includes:

• Personal data of other individuals. You need to redact any personal data of other individuals mentioned in the emails (e.g., names, email addresses, phone numbers).
• Confidential business information. You may need to redact confidential business information that is not relevant to the individual’s request.
• Information subject to legal privilege. You may need to redact information that is subject to legal privilege (e.g., communications with your lawyers).

Example: Redacting email content using a text editor You can use a text editor like `sed` to redact sensitive information from email content.

sed 's/sensitive information/[REDACTED]/g' email.txt > redacted_email.txt

This command will replace all occurrences of “sensitive information” with “[REDACTED]” in the `email.txt` file and save the redacted content to `redacted_email.txt`. For more complex redaction tasks, you may need to use specialized redaction software. Important: Document all redactions and the reasons for them. This will help you justify your decisions if challenged.

Providing the Data to the Requestor

After reviewing and redacting the email data, you need to provide it to the individual making the request. GDPR requires that you provide the data in a commonly used electronic format. Consider these options:

• Provide the emails as individual `.eml` files. This is a common format for storing email messages.
• Provide the emails as a `.mbox` file. This is another common format for storing multiple email messages in a single file.
• Provide the emails in a PDF format. This can be useful if you need to ensure that the formatting of the emails is preserved.

Ensure that the data is securely transmitted to the individual, for example, by using encryption or a secure file transfer service. Example: Creating a `.zip` archive containing `.eml` files

zip -r email_data.zip /path/to/eml/files

This command will create a `.zip` archive named `email_data.zip` containing all the `.eml` files in the `/path/to/eml/files` directory. Always password-protect the `.zip` archive and provide the password to the individual separately. Remember to respond to SARs within the timeframe specified by GDPR (usually one month).