Re: Being blocked with error 554 5.7.1
Interesting. Your off-list reply to mine was bounced by Google (when our server relayed it). You wrote: > The from header is: > edulinkbordengrammar.kent.sch.uk > however they've set a non-existent account as the reply to... Those look fine to me. But why was your message to me bounced by Google? Their bounce response reads: 'Our system has detected that this message is suspicious due to the nature of the content and/or the links within. To best protect our users from spam, the message has been blocked. Please visit https://support.google.com/mail/answer/188131 for more information.' You can read what Google say at that link. There is nothing in your email that looks at all like spam to me. Are you able to fix the DMARC entry in your DNS? It has spurious escaped quotes. On Sat, 12 Sep 2020 at 12:15, Dominic Raferd wrote: > > On Fri, 11 Sep 2020 at 22:49, Julian Pilfold-Bagwell > wrote: > > > > I have a problem that's sprung to light after we bought in a 3rd party > > cloud provider. I have postfix 2.10 running on Centos 7 (main.cf below) > > and our 3rd party provider is relaying mail out via our server, using > > authentication on a legit account. However, the recipient ISPs reject > > mail with the error 554 5.7.1 recipient access denied, although this > > doesn't seem to happen on all the messages that are being sent. If > > we're sending say 60 messages, the first block of 20 will go through, > > the next 20 will be blocked and the final 20 will go through. I'm > > guessing that the receiving end is objecting to something in the headers > > from the relayed mail, but can't quite get to grips as to why it occurs > > in batches. > > > > The 3rd party provider is sending reports to all of our end users which > > is over a thousand emails+ so I've limited the delivery rate to 1 > > message per domain every twenty seconds to try to appear less spammy > > but it still happens as described. The error message is as below: > > > > NOQUEUE: reject: RCPT from smtp.overnetdata.com[5.153.65.228]: 554 5.7.1 > > : Recipient address rejected: Access denied; > > from= to= > > proto=ESMTP helo= > > > > and we're receiving this from talktalk.co.uk, sky.com, yahoo.co.uk, > > hotmail.com, outlook.com and gmail.com sometimes talks to us, and > > sometimes doesn't. > > > > and main.cf is shown here:... > > The setup seems imperfect, and the version of postfix rather old, but > which if any of the imperfections is causing this new problem is hard > to say without fuller examples of what is being blocked, which I can > well understand you might not want to post on an open forum. My > observations are: > > Instead of 'smtp_use_tls = yes' it is advisable to use > 'smtp_tls_security_level = may' (Postfix 2.3+) > > Your SPF entry in DNS looks ok, provided as you say that the 3rd party > is sending your emails via your mail server and not independently. > Also your mail server's ip is not blacklisted at any of the 129 rbls I > regularly check, nor at https://ipremoval.sms.symantec.com/. You can > check its status with Microsoft by registering it at their Smart > Network Data Service. > > Your DMARC entry in DNS is broken, also you do not appear to be > signing outgoing emails with DKIM. But I doubt either of these is the > explanation for your problem. > > Is the third party sender using your domain in the 'From:' header as > well as in the envelope?
Re: Being blocked with error 554 5.7.1
Dominic Raferd: > Are you able to fix the DMARC entry in your DNS? It has spurious escaped > quotes. The SPF record is invalid, too, ‘a:81.145.130.2’ is not valid syntax. Perhaps these add to some negative score for your messages.
Re: Postscreen Logfile Analyser
On 12-9-20 8:31, Admin Beckspaced wrote: I use pslogscan for postscreen Thanks, I think I can make this work. Best, Jos Chrispijn -- With both feet on the ground you can't make any step forward
Re: Postscreen Logfile Analyser
On 11-9-20 21:08, Michael Orlitzky wrote: I still use postfix-logwatch (http://logreporters.sourceforge.net/), but there are a few patches to apply since the maintainer went AWOL: Thanks for this; I am a nub on perl, but will certainly give it a try. Best, Jos Chrispijn -- With both feet on the ground you can't make any step forward
managing multiple virtual_alias_map *flat* files ?
I'm exploring an all flat-file virtual-address-only postfix setup. well, using lmdb -- NOT sql or ldap, to be accurate. When it comes to alias management, I'm not convinced my approach is (easily) doable in flat-files. For each virtual address defined in virtual_mailbox_maps= lmdb:/etc/postfix/virtual_mailbox_maps e.g., cat virtual_mailbox_maps us...@example.com example.com/user1 us...@example.com example.com/user2 rather than a single alias map file, I'd _like_ a separate virtual alias map per real address. i.e., /etc/postfix/virtual_alias_maps/us...@example.com /etc/postfix/virtual_alias_maps/us...@example.com where, e.g., /etc/postfix/virtual_alias_maps/us...@example.com ali...@example.comJUNKTEXT ali...@example2.com JUNKTEXT /etc/postfix/virtual_alias_maps/us...@example.com ali...@example3.com JUNKTEXT ali...@example4.com JUNKTEXT , with JUNKTEXT ignored, and the redirect_to replaced by the filename -- in this case, "us...@example.com" & "us...@example.com", respectively. can that be managed with postfix out of the box? if so, what would be the form of virtual_alias_maps = in postfix config? And, does postifx do any checking to avoid multiple-instances of a single alias? I.e., preventing collisioin of the same alias redirecting to same target virtual address? All of that^ is certainly doable with SQL/LDAP. For this setup, If I _can_ avoid DB/LDAP, I'd like to ... just not convinced if/how I manage this^ without too much 'kludge'. Thoughts/suggestions?
Re: managing multiple virtual_alias_map *flat* files ?
On Sat, Sep 12, 2020 at 11:52:51AM -0700, PGNet Dev wrote: > I'm exploring an all flat-file virtual-address-only postfix setup. > well, using lmdb -- NOT sql or ldap, to be accurate. This feels like an instance of an XY problem. Your approach to problem X leads you to approach Y, which runs into an issue, and so now you're asking about Y, but really you should start by asking about X. What is the actual goal here? What sort of virtual alias management problem are you trying to solve by partitioning virtual aliases across multiple source files. Why are you loathe to consider a database, ... Are you experiencing Qmail nostalgia? :-) In Qmail you get an alias file *per-domain*, with domains owned by some user, and then an alias for each domain managed by the owning user. Pushing the model to alias file per user, without first scoping the aliases to a domain owned by the user is likely ill-defined, who gets to claim which aliases? Questions about how to assemble virtual aliases are premature absent a clear data model. -- Viktor.
Re: managing multiple virtual_alias_map *flat* files ?
On 9/12/20 3:26 PM, Viktor Dukhovni wrote: > What is the actual goal here? having recently migrated a few boxes from my own, DIY'd app & prereq builds to distro pkg'ing reminded of the 'joys' of pulling in bloated dependencies, etc. i'm simply exploring an as-thin-as-possible/lightweight deployment. minimal external dependencies, etc. -- ideally _just_ requiring a postfix install, and flatfiles. > What sort of virtual alias management > problem are you trying to solve by partitioning virtual aliases across > multiple source files. an interest in matching the way I organize my own information. > Why are you loathe to consider a database, ... hardly loathe. see above re: exploring & thin/lightweight > Are you experiencing Qmail nostalgia? :-) don't we all, secretly? > Questions about how to assemble virtual aliases are premature absent a clear > data model.
Re: managing multiple virtual_alias_map *flat* files ?
On Sat, Sep 12, 2020 at 04:52:43PM -0700, PGNet Dev wrote: > On 9/12/20 3:26 PM, Viktor Dukhovni wrote: > > What is the actual goal here? > > having recently migrated a few boxes from my own, DIY'd app & prereq builds > to distro pkg'ing reminded of the 'joys' of pulling in bloated dependencies, > etc. > > i'm simply exploring an as-thin-as-possible/lightweight deployment. minimal > external dependencies, etc. -- ideally _just_ requiring a postfix install, > and flatfiles. If this is just your own way to organise data managed by a single authority (you), then organise it any way you like, then run "make" to create a single virtual(5) aliases file that you "postmap" in the usual way. -- Viktor.
Re: managing multiple virtual_alias_map *flat* files ?
On 9/12/20 5:03 PM, Viktor Dukhovni wrote: > If this is just your own way to organise data managed by a single > authority (you) in _this_ case, it is. > then organise it any way you like, then run "make" > to create a single virtual(5) aliases file that you "postmap" in > the usual way. to date, on my rather more expansive installs, I've kept a list of disparate sources i had simply not thought to use make to consolidate whatever hodge-podge i cobble up into a single aliases file. perfect! thx o/
