I didn't follow this to begin with, apologies.
On Fri, 10 Apr 2020, Tom Hendrikx wrote:
On 09-04-2020 01:01, @lbutlr wrote:
Given an email address of user+ama...@example.com how can I reject all
emails to that address that do not come from amazon.com?
The mechanics of extracting the relevant (definitionally speaking) "test
string", in this case "amazon", from the (definitionally speaking)
"destination address" are left as an exercise for the reader.
;-)
There are some larger mechanics to be discussed.
The "destination address" is extracted from which header? To: would be the
naive choice, but Delivered-To: is probably better. However, using this
header requires that the filtering take place very close to final
delivery, as that's when the header is inserted.
What is "come[ing] from", definitionally speaking? As Tom observes, there
are choices. I offer the following definition of "effective domain" for
this purpose: "The 'effective domain' is the domain extracted from the
Return-Path: if present, otherwise the From: header." Using Return-Path:
likewise requires being closer to the delivery event than not. As seen in
discussions of the functional impacts of techniques such as SPF and DKIM
on the operation of for example mailing lists, the domain in Return-Path:
will violate the principle of least surprise often enough to require
thought and deliberation; unfortunately that's unavoidable. (Personally I
use Return-Path:, as I use effective domain for processing myself.)
Being inserted close to delivery both the Return-Path: and Delivered-To:
headers will typically be very close to the top of the header stack; other
choices, such as From: or To: may not be. This is by way of observing that
for reliable processing it's often necessary to load all of the headers
into a map where they can be looked up by header name. This means that
strict stream processing, line by line, or as milters are wont to do, is
not possible (of course you can do it with a milter, but you will need to
maintain state and think about it). Also for certain multiple occurrence
fields, particularly Received:, the ordering does matter; for Received:
the instance at the top of the stack is typically the only one which can
be "trusted" (not attempting to define that one!).
I'm using address extensions like this for more than 10 years, for almost
every commercial interaction through the web. I'm using the domain name of
the website of the party that I'm giving my address to, or a reference to the
mobile app that wants me to sign up.
https://github.com/m3047/trualias
I haven't seen any abuse (a company bought or repurposed an address) except
for 1 specific incident.
Tom's experience is very different from mine or that of Andrew Lewman,
whose blog is referenced in the README.md for that project.
--
Fred Morris
