Re: Rejecting emails based on address extension?
On 08 Apr 2020, at 17: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? 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 u...@example.com (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
Re: Rejecting emails based on address extension?
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
Re: Rejecting emails based on address extension?
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
Re: Rejecting emails based on address extension?
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
Re: Rejecting emails based on address extension?
On 08 Apr 2020, at 22:43, Bill Cole wrote: > As a result, I reject all mail with a sender that matches 'bounce@' aimed at > 'b...@scconsult.com' 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 'user+ama...@example.com' 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.”
Re: Rejecting emails based on address extension?
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
Re: Rejecting emails based on address extension?
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
Re: Rejecting emails based on address extension?
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
Re: Rejecting emails based on address extension?
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? 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
