Consent is often the first thing people think of for GDPR, but it’s not the only way to legally process personal data via SMTP.
Let’s see how this plays out in a real-world scenario. Imagine you have a marketing list managed by an external service, and you’re sending out a weekly newsletter.
Here’s a simplified sendmail.cf configuration that handles some basic sender authentication, which is a prerequisite for many compliance efforts:
Cw/etc/mail/sendmail.cw
Kuserdb hash -o /etc/mail/userdb
Mlocal, P/usr/lib/sendmail-client, Fup, S-1, R$*,$@$:$(userdb $1:)$
Now, consider the lifecycle of an email recipient. When someone subscribes, you need their explicit consent to send them emails. This consent isn’t just a checkbox; it’s a record of what they consented to and when.
For GDPR, "consent" means freely given, specific, informed, and unambiguous indication of the data subject’s wishes by which he or she signifies agreement to the processing of personal data relating to him or her. This implies an affirmative action, not pre-checked boxes.
When sending emails, your SMTP server logs are crucial. They record sender, recipient, timestamps, and delivery status. These logs are your audit trail for demonstrating compliance.
Sep 10 10:00:01 mailserver sendmail[12345]: v876543210: to=<recipient@example.com>, delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=12345, relay=smtp.example.com [192.168.1.10], dsn=2.0.0, stat=Sent (v12345 Message accepted for delivery)
Retention policies dictate how long you keep this data. GDPR doesn’t specify exact times for email logs, but it emphasizes that data should be kept no longer than necessary for the purposes for which it is processed. For marketing lists, this might mean deleting inactive subscribers after a certain period, say, 18 months of no engagement.
Deletion requests are a core right under GDPR. If a user asks to be removed from your mailing list, you must not only stop sending them emails but also delete their personal data from your systems and any third-party processors. This includes their email address and any associated consent records.
To implement deletion, you’d typically have a process that:
- Receives the deletion request (e.g., via an unsubscribe link or direct email).
- Updates your subscriber database to mark the user as unsubscribed and scheduled for deletion.
- Triggers a script to remove the user’s record from the database after a defined grace period (e.g., 24 hours to allow for any final legitimate processing).
- If using a third-party email service provider, ensures they also have a mechanism to honor these deletion requests promptly.
The surprising thing is that even if you’re not directly collecting personal data through your SMTP server itself, the act of sending emails to individuals constitutes processing their personal data (their email address, at a minimum) and therefore falls under GDPR.
Consider the implications for email marketing campaigns. If you segment your list based on past purchase history or engagement metrics, you are processing personal data. You need a lawful basis for this processing, which could be consent or legitimate interests, but the latter requires a robust balancing test against the individual’s rights.
The ability to track and prove consent for each individual recipient, especially for marketing communications, is paramount. This often involves integrating your CRM or subscriber management system with your email sending platform to ensure that consent status is accurately reflected and respected during email dispatch.
Ultimately, compliance isn’t just about ticking boxes; it’s about building a system that respects individual privacy rights throughout the entire data lifecycle, from initial consent to final deletion.
The next hurdle you’ll likely face is handling data subject access requests (DSARs) for email content.