I like to be one step ahead...
On Fri, 10 Apr 2020, Tom Hendrikx wrote:
[...]
in 'virtual_alias_maps.pcre':
/^hi\..*@example.com$/ personal.in...@example.org
[...]
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 :)
The regex example you provide will work for the vast majority of what
comes over the transom here in practice. But then there was a time when
spam was of theoretical interest only and nobody had really thought about
the problem(s) SPF is designed to solve. It's hard to imagine that time
now without being revisionist. We'll see.
The trualias definition grammar is likely more expressive than you
imagine.
I'm finding that I can boost the "ham" score of stuff that comes in with a
trualias, over e.g. the address to which I'm subscribed to this mailing
list, and that might be counterintuitive.
Addresses which are abused tend to be abused widely, and can be
individually blocked. There is another category of usage however, which is
more along the lines of a cookie: that falls into either I know that this
incoming transmission is in regards to a particular conversation, or that
I know you leaked and you don't know I know.
Sure, regexes like you describe are fine for now for the vast majority of
cases. I think I've carved out a large enough exception for public use by
publishing this project, and I provided tests with the notion that someone
might want to reimplement in mind.
--
Fred Morris
