Rejecting emails based on address extension?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Rejecting emails based on address extension?

@lbutlr
Given an email address of [hidden email] how can I reject all emails to that address that do not come from amazon.com?

I think I did something like this once but if I did, I didn’t keep notes. :/


--
Nihil est--in vita priore ego imperator Romanus fui.


Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

allenc


On 09/04/2020 00:01, @lbutlr wrote:
> Given an email address of [hidden email] how can I reject all emails to that address that do not come from amazon.com?
>
> I think I did something like this once but if I did, I didn’t keep notes. :/
>
>

Funny you should mention that - within the last half-hour I have come up with
(for header checks file):-

if /^From:.*amazon\.co\.uk/
!/\<.*\@.*amazon\.co\.uk\>/ WARN Fake Amazon address
endif

Completely untested - it would be interesting to know if I am getting my regexp
syntax right.  :-)

Not quite what you wanted - but hope it helps.

Regards

Allen C
Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

@lbutlr
On 08 Apr 2020, at 17:16, Allen Coates <[hidden email]> wrote:

> On 09/04/2020 00:01, @lbutlr wrote:
>> Given an email address of [hidden email] how can I reject all emails to that address that do not come from amazon.com?
>>
>> I think I did something like this once but if I did, I didn’t keep notes. :/
>>
>>
>
> Funny you should mention that - within the last half-hour I have come up with
> (for header checks file):-
>
> if /^From:.*amazon\.co\.uk/
> !/\<.*\@.*amazon\.co\.uk\>/ WARN Fake Amazon address
> endif
>
> Completely untested - it would be interesting to know if I am getting my regexp
> syntax right.  :-)
>
> Not quite what you wanted - but hope it helps.

Useful, but not helpful in this case because there is no way to have postfix check two headers

(If TO contains “amazon” and FROM_ does not contain “amazon”) isn’t something postfix can do, but perhaps there is a milter out there that can.

I can do it in Sieve, but I would prefer to reject them before they get delivered.


--
Nine-tenths of the universe is the knowledge of the position and
        direction of everything in the other tenth. Every atom has its
        biography, every star its file, every chemical exchange its
        equivalent of the inspector with a clipboard. It is unaccounted
        for because it is doing the accounting for the rest of it.
        Nine-tenths of the universe, in fact, is the paperwork. --The
        Thief of Time


Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

allenc


On 09/04/2020 00:29, @lbutlr wrote:

> On 08 Apr 2020, at 17:16, Allen Coates <[hidden email]> wrote:
>> On 09/04/2020 00:01, @lbutlr wrote:
>>> Given an email address of [hidden email] how can I reject all emails to that address that do not come from amazon.com?
>>>
>>> I think I did something like this once but if I did, I didn’t keep notes. :/
>>>
>>>
>>
>> Funny you should mention that - within the last half-hour I have come up with
>> (for header checks file):-
>>
>> if /^From:.*amazon\.co\.uk/
>> !/\<.*\@.*amazon\.co\.uk\>/ WARN Fake Amazon address
>> endif
>>
>> Completely untested - it would be interesting to know if I am getting my regexp
>> syntax right.  :-)
>>
>> Not quite what you wanted - but hope it helps.
>
> Useful, but not helpful in this case because there is no way to have postfix check two headers
>
> (If TO contains “amazon” and FROM_ does not contain “amazon”) isn’t something postfix can do, but perhaps there is a milter out there that can.
>
> I can do it in Sieve, but I would prefer to reject them before they get delivered.
>
>

Thinking on a tangent - I have a method of protecting my mailing-list
identities; I accept the list-server(s) by host identity and then reject the
destination address(es) :-

check_client_access cidr:/etc/postfix/listserver_access.cidr,
check_recipient_access hash:/etc/postfix/recipient_access

Allen C
Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Bill Cole-3
In reply to this post by @lbutlr
On 8 Apr 2020, at 19:01, @lbutlr wrote:

> Given an email address of [hidden email] how can I reject all
> emails to that address that do not come from amazon.com?
>
> I think I did something like this once but if I did, I didn’t keep
> notes. :/

Since the decision can be made based on envelope parameters, you should
be able to do this with a restriction class. Example:

/etc/postfix/main.cf:

    smtpd_restriction_classes = spooftargets
    smtpd_recipient_restrictions = [...] check_recipient_access
pcre:/etc/postfix/recipient_checks.pcre [...]
    spooftargets = check_sender_access
pcre:/etc/postfix/spooftarget-senders

/etc/postfix/recipient_checks.pcre:

     /^[hidden email]$/ spooftargets

/etc/postfix/spooftarget-senders:

     /bounce@/ 554 5.7.1 This address does not accept mail from
bounce-processors


As a result, I reject all mail with a sender that matches 'bounce@'
aimed at '[hidden email]' which is an address that has been exposed
for 25 years in Usenet but never used for any sort of subscription or
transaction. One could just as easily make '[hidden email]' a
member of a restriction class and only accept mail for it if the client
name and sender name match legitimate Amazon patterns.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Bill Cole-3
On 9 Apr 2020, at 0:43, Bill Cole wrote:

> On 8 Apr 2020, at 19:01, @lbutlr wrote:
>
>> Given an email address of [hidden email] how can I reject
>> all emails to that address that do not come from amazon.com?
>>
>> I think I did something like this once but if I did, I didn’t keep
>> notes. :/
>
> Since the decision can be made based on envelope parameters, you
> should be able to do this with a restriction class. Example:
>
> /etc/postfix/main.cf:
>
>    smtpd_restriction_classes = spooftargets
>    smtpd_recipient_restrictions = [...] check_recipient_access
> pcre:/etc/postfix/recipient_checks.pcre [...]
>    spooftargets = check_sender_access
> pcre:/etc/postfix/spooftarget-senders
>
> /etc/postfix/recipient_checks.pcre:
>
>     /^[hidden email]$/ spooftargets
>
> /etc/postfix/spooftarget-senders:
>
>     /bounce@/ 554 5.7.1 This address does not accept mail from
> bounce-processors
>
>
> As a result, I reject all mail with a sender that matches 'bounce@'
> aimed at '[hidden email]' which is an address that has been
> exposed for 25 years in Usenet but never used for any sort of
> subscription or transaction. One could just as easily make
> '[hidden email]' a member of a restriction class and only
> accept mail for it if the client name and sender name match legitimate
> Amazon patterns.

I should also note, in case it is not obvious: this does not scale well.


--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Wietse Venema
In reply to this post by @lbutlr
@lbutlr:
> Useful, but not helpful in this case because there is no way to have =
> postfix check two headers

Who says that one has to implement this with headers?

Do it with envelopes instead:

http://www.postfix.org/RESTRICTION_CLASS_README.html

Admittedly, this is somewhat difficult to set up, but it handles
combinations of arbitrary check_mumble_access restrictions.

UNTESTED example:

/etc/postfix/main.cf:
    smtpd_restriction_classes = from_amazon_only

    from_amazon_only =
        # Alternative: check_client_access, but that depends on DNS.
        check_sender_access inline:{ { amazon.com = ok } }
        check_sender_access static:{ 550 5.7.1 You are not amazon.com }

    smtpd_recipient_restrictions =
        ...
        check_recipient_access inline:{ { user+amazon@ = from_amazon_only } }
        ...

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Tom Hendrikx
In reply to this post by @lbutlr
On 09-04-2020 01:01, @lbutlr wrote:
> Given an email address of [hidden email] how can I reject all emails to that address that do not come from amazon.com?
>
> I think I did something like this once but if I did, I didn’t keep notes. :/
>
>

A slightly different take on this:

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.

I haven't seen any abuse (a company bought or repurposed an address)
except for 1 specific incident. Maybe I'm too picky about doing business
with shady companies... The number of addresses handed out should be in
the hundreds.

What  I took from this:

- Handing out addresses is easy, but it's hard to keep track of them. I
can create new addresses on the fly on any occasion (anything I make up
is accepted by my server), but to remember them and write a specific
line in my postfix config for them later that day, is hard. If you want
rules in your spam setup for this, they should be automated: f.i. a
regexp that matches the label in the recipient address to be (part of)
the sender address.

- Matching actual senders with the label you give them is a grey area.
Many senders use a less brand-specific email-sending platform than what
you expected when you made up the label: f.i. an online order at
bbq-stuff.org actually sends mail from the company-wide domain
garden-apparel.com. These matches need human interpretation (or a very
large database and sufficient input data) before you can decide whether
someone is actually doing something wrong.

- The few actual wrongdoers you will be catching are probably more
interesting to receive and keep for research purposes, than to simply
reject.

My 2 cents on this.

Kind regards,

        Tom
Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Fred Morris
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 [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Wietse Venema
Fred Morris:
> 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.

Why insist on addresses in headers. and not use envelope addresses?

I gave an example based on the latter that takes only a few lines.
This kind of use case is what rectriction_classes were built for.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Tom Hendrikx
In reply to this post by Fred Morris

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 [hidden email] 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$/   [hidden email]

I give out addresses like: "[hidden email]". Note that the
address "[hidden email]" 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

Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

@lbutlr
In reply to this post by Bill Cole-3
On 08 Apr 2020, at 22:43, Bill Cole <[hidden email]> wrote:
> As a result, I reject all mail with a sender that matches 'bounce@' aimed at '[hidden email]' which is an address that has been exposed for 25 years in Usenet but never used for any sort of subscription or transaction. One could just as easily make '[hidden email]' a member of a restriction class and only accept mail for it if the client name and sender name match legitimate Amazon patterns.

Ah, yes, of course. I was thinking of a single check.

I think I am going to do this for the few accounts that are actually using address extensions and see how it goes.

Thanks!


--
"If this is the best God can do, I'm not impressed.”


Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Fred Morris
In reply to this post by Wietse Venema
On Fri, 10 Apr 2020, Wietse Venema wrote:
> Fred Morris:
>> The "destination address" is extracted from which header? To: would be the
>> naive choice, but Delivered-To: is probably better.

If it isn't munged, the envelop address (RCPT) becomes the Delivered-To:
address does it not?

--

Fred

Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Fred Morris
In reply to this post by Tom Hendrikx
I like to be one step ahead...

On Fri, 10 Apr 2020, Tom Hendrikx wrote:

> [...]
> in 'virtual_alias_maps.pcre':
> /^hi\..*@example.com$/   [hidden email]
> [...]
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

Wietse Venema
In reply to this post by Fred Morris
Fred Morris:
> On Fri, 10 Apr 2020, Wietse Venema wrote:
> > Fred Morris:
> >> The "destination address" is extracted from which header? To: would be the
> >> naive choice, but Delivered-To: is probably better.
>
> If it isn't munged, the envelop address (RCPT) becomes the Delivered-To:
> address does it not?

I thought that you're trying to block mail BEFORE Postfix receives
it. Postfix creates the Delivered-To header DURING final delivery.
There is an obvious timing problem here.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Rejecting emails based on address extension?

@lbutlr
In reply to this post by @lbutlr
On 08 Apr 2020, at 17:01, @lbutlr <[hidden email]> wrote:
> Given an email address of [hidden email] how can I reject all emails to that address that do not come from amazon.com?

I realize after ready this whole thread that I phrased this poorly and incompletely.

Yes, I want to reject all email to user+amazon that is not from amazon, but I also want to reject all mail that claims to be from amazon from being delivered to [hidden email] (for a specific user, not a general rule for all accounts).

But I think that Wietse’s post on restriction_classes is still the way to do this. With the addition of another class for the bare address. Assuming the From: is available tp smtpd_restriction_classes

Will check docs and test.


--
'Why is it all Mr Dibbler's films are set against the background of a
        world gone mad?' said the dwarf. Soll's eyes narrowed. 'Because
        Mr Dibbler,' he growled, 'is a very observant man.' --Moving
        Pictures