On 10-04-2020 18:09, Fred Morris wrote:
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.
The blog link is broken, the actual article is here:
https://blog.lewman.com/why-i-have-over-one-thousand-personal-email-addresses.html
Please note that I don't wildcard a domain: I'm using a single regex in
postfix that aliases addresses with a specific prefix to my inbox:
in 'virtual_alias_maps.pcre':
/^hi\..*@example.com$/ personal.in...@example.org
I give out addresses like: "hi.company....@example.com". Note that the
address "h...@example.com" is NOT deliverable, so simply stripping the
label from the address will result in a delivery error. The prefix
protects against fully random (f.i. message-id@servername) or
'common-named' localparts (sales@). No tcp tables, milters or external
tools needed here.
While I've looked at your project, I don't understand which problem you
are solving with the verification code: when some evil party has
bought/sold a labeled address, they could in theory unlabel or relabel
it, rendering the address (possibly) invalid. But they want to send
email to tens of thousands of addresses, of which only a few are labeled
anyway: if they are even aware of the issue, why would they even bother
for these few recipients? If they are aware of the issue, a more
plausible solution (to me at least) would be to simply delete the
labeled addresses, which is much easier than altering them into
something that is no longer pointing to the original company.
The only solution that the verification code provides (IMHO), is that I
know (to some degree) that I actually gave out that alias. But then: how
often does it happen that you receive email that actually has a label,
but has no or an invalid verification code?
In short: I'm very curious about your experience :)
Regards,
Tom
