Re: Can case-folding for lookup tables be disabled?
On Fri, Nov 19, 2021 at 05:07:21PM -0800, Mel Pilgrim wrote: > I read in transport(5), virtual(5), et al that Postfix will case-fold > query strings, but for one specific project I need it to not do that. > Are there any tunables for this? I didn't see anything in postconf -d > output that looked related. > > The short explanation is that I need to be able to do lookups against a > strict-match-only case-sensitive database and the records are mixed case > (e.g. al...@example.com). I'm fully aware of how stupid that is but > this is not my data, not my system, not my money. Is this for just one table, one database type, or *all* Postfix lookups including btree, cdb, ... > If this isn't possible, can someone point me toward the code I would > need to change so I can create a local, unsupported version if that ends > up being my only recourse? You'll need a custom build, there's no built-in support for configurable case folding outside the regexp tables (via /pattern/i). -- Viktor.
Can case-folding for lookup tables be disabled?
I read in transport(5), virtual(5), et al that Postfix will case-fold query strings, but for one specific project I need it to not do that. Are there any tunables for this? I didn't see anything in postconf -d output that looked related. The short explanation is that I need to be able to do lookups against a strict-match-only case-sensitive database and the records are mixed case (e.g. al...@example.com). I'm fully aware of how stupid that is but this is not my data, not my system, not my money. If this isn't possible, can someone point me toward the code I would need to change so I can create a local, unsupported version if that ends up being my only recourse?
Re: Spawn milter access to Verified Sender database
Hi Wietse, On 19/11/2021 16:53, Wietse Venema wrote: With hash and btree there is no guaranteed way to read a table after it is updated, even when using locks. LMDB tables are better in this respect, as long as you use the right locking procedure (man 5 lmdb_table) but you'd need to make the table group readable so that your tool can lock and read it. I didn't realise that btree wasn't good for sharing so I've switched to LMDB format. Hopefully I can find a suitable Debian PERL module (not CPAN) or get PHP to read the format. I have some reading and experimenting to do. Thanks for the tips. That leaves two problems. The table format is an internal interface. I do make incompatible changes internally, and that is OK because no-one is supported when they rely on an internal interface. The format is described with a comment in the verify.c source code. Changes to the internal data format would only be a problem (for me) once every 4 years as I only upgrade Postfix with Debian every other Deb release (excluding security fixes). I build a new VPS each time as 'dist-upgrade' adds too many unwanted packages for my small VPS. I'm about due a rebuild, meaning Debian 8 to 10 (Postfix v3.1.15 to v3.4). While that's still 2 versions behind (soon to be 3) I'm looking forward to trying out SNI. Ah the format is in the comments! I've just had a look. So the first colon separated value of data is status. Thanks. Instead of hacking file permissions you could try to set up a proxymap service over TCP on 127.0.0.1. But again the protocol is an internal interface and breaking changes happen. I just noticed that this protocol still needs to be changed into "server speaks first" like the rest of Postfix. I have added that on the TODO list for Postfix 3.7. Yes I think you are right that the best way to query the database would be by a local TCP service. As me for using stable protocol, well sorry I wouldn't know where to start. I was more thinking about keeping it simple. Having it reply with the status byte or -1 for no match? I think that is about my limit sadly. Thanks for your encouraging reply. Best wishes, Mick. Reading the verify map (and other tables) would need a proxymap like service with a stable protool. It should probably output JSON format, like postqueue -j does. Wietse
Re: Sender Rewriting Scheme and backup MX
"Matus" == Matus UHLAR <- fantomas > writes: Matus> is it not. To be precise: Matus> SRS is to be used when you accept mail for one address and re-send to Matus> another address (in different domain/on different server). Matus> this is not the case for backup MX. On 18.11.21 18:28, Togan Muftuoglu wrote: Thanks for the clarification. One more thing having the backup MX listed in the SPF records of the domain and opendkim signing the relayed mails does not break the validations in the primary MX when it receives mail from the backup, correct ? there's no reason why backup MX should be listed in SPF record. Backup MX received mail for your domain, you'd need to list it in all other domains. ...unless it rewrites mail sender, but that's not a good idea - in that case it's not backup MX but mail forwarder :-) The backup MX should be listed in local exemptions for SPF checking. DKIM has nothing to do with it, unless backup MX modifies headers or body of the mail, in which case the backup should be exempted from DKIM checks as long. In standard case, backup MX should do the SPF/DKIM/DMARC checks itself, and output from backup MX should be trusted by your mailserer. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm
Re: Various questions about Postfix
Missed this one: > message_size_limit = 52428800 > virtual_mailbox_limit = 524288 > > message_size_limit needs to be less than or equal to > virtual_mailbox_limit. Your virtual_mailbox_limit is > 100 times message_size_limit. Not intentional, definitely a typo. I think early on I saw mailbox_size_limit and thought that's what I wanted.
Re: Sender Rewriting Scheme and backup MX
> "Viktor" == Viktor Dukhovni writes: >> On 18 Nov 2021, at 12:28 pm, Togan Muftuoglu wrote: >> >> Thanks for the clarification. One more thing having the backup MX listed in >> the SPF records of the domain and opendkim signing the relayed mails does >> not break the validations in the primary MX when it receives mail from the >> backup, correct ? Viktor> Any receiving system that elects to use a backup MX must whitelist Viktor> mail from the backup MX: Viktor> * Not apply any SPF checks Both Backup and Primary MX runs openDMARC with the following settings RejectFailures true SPFIgnoreResults false They also run opendkim in signing/verifying mode ## ## Causes the filter to perform a fallback SPF check itself when ## it can find no SPF results in the message header. If SPFIgnoreResults ## is also set, it never looks for SPF results in headers and ## always performs the SPF check itself when this is set. # SPFSelfValidate true ## TrustedAuthservIDs string ## default HOSTNAME ## ## Specifies one or more "authserv-id" values to trust as relaying true ## upstream DKIM and SPF results. The default is to use the name of ## the MTA processing the message. To specify a list, separate each entry ## with a comma. The key word "HOSTNAME" will be replaced by the name of ## the host running the filter as reported by the gethostname(3) function. # Both backup and primary have their fqdn listed as TrustedAuthservIDs Viktor> * Not greylist Both primary and backup are running postscreen with identical allowlisted cidr Viktor> * Not reject messages other than to invalid recipients Both of them reject all mail for non-existent recipients. Backup MX has relay_recipients that is synced with Primary MX recipients list They both have spamass-milter running and they both reject with a spam score of 8 In addition I have applied the examples mentioned in the http://www.postfix.org/BACKSCATTER_README.html#real So under the above mentioned conditions anything I should not be doing or should be doing instead ? Thanks
Re: Spawn milter access to Verified Sender database
With hash and btree there is no guaranteed way to read a table after it is updated, even when using locks. LMDB tables are better in this respect, as long as you use the right locking procedure (man 5 lmdb_table) but you'd need to make the table group readable so that your tool can lock and read it. That leaves two problems. The table format is an internal interface. I do make incompatible changes internally, and that is OK because no-one is supported when they rely on an internal interface. The format is described with a comment in the verify.c source code. Instead of hacking file permissions you could try to set up a proxymap service over TCP on 127.0.0.1. But again the protocol is an internal interface and breaking changes happen. I just noticed that this protocol still needs to be changed into "server speaks first" like the rest of Postfix. I have added that on the TODO list for Postfix 3.7. Reading the verify map (and other tables) would need a proxymap like service with a stable protool. It should probably output JSON format, like postqueue -j does. Wietse
Spawn milter access to Verified Sender database
Dear Postfix users, I have a fairly quiet Postfix server and so can just about get away with having 'reject_unverified_sender set' as default. This does lose genuine email from time to time so to mitigate, I have a SPAWN policy service 'policy-nv' which checks a global file for exceptions. In addition each mailbox can have a local file with its own exceptions that will override a global file reject or ok match. I'm currently testing a process to disable reject_unverified_sender checks on a per mailbox basis but would like to compliment this feature with an in-milter log report when a sender would have failed sender verification. In an attempt accomplish failure logging, I decided to add 'warn_if_reject reject_unverified_sender' to cache the result prior to calling the policy. The intention was to then search the Postfix 'address_verify_map' btree database for a match from within the policy. There's a major problem though as the policy runs as nobody, and the BTree database is owned by Postfix. It is also illegal to call a policy using postfix permissions, and I wouldn't want to do that anyway. I am wondering if there's workaround or perhaps another way to tell the spawned policy that the sender has failed the test? Perhaps reading the database isn't such a good idea anyway. For a start I don't know if 'warn_if_reject reject_unverified_sender' completes before passing spawning. If reading the address verify map database outside of Postfix bad idea, I will accept that. I only want it to log to a dedicated file for my convenience so not the end of the world if I can't do it. 'warn_if' will log failures to the mail.log in any case. Out of interest (even if I drop this idea) what do the first two colon separated digits of the matched reply refer to? The third is obviously UNIX time fourth the reply. 0:0:1636478315:250 Accepted smtpd_sender_restrictions = warn_if_reject reject_unverified_sender # policy replies with action=OK/REJECT/DUNNO check_policy_service unix:private/policy-nv reject_unverified_sender Thanks for your help. Best wishes, Mick.
