Ok, thanks, yes, debian.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
Ah, thanks. Yes, of course. 🙁
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
I am recently seeing an almost exact similarity between mail.log and
mail.info, to the extent I am now querying the usefulness of looking at
mail.info at all. Am I missing something?
In main.cf I have
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1
and no other obvious log control.
Thank you for your reply, Viktor.
So I've been wrong for the past few years in thinking it was working.
Surprising (to me!) but yet another warning to not pick up "working
configurations" from web sites (and possibly mis-read them). :(
I understand what you're saying. I may have mistaken chec
Victor, thank you for your help. It prompted me first to look again at
opendkim.conf and the various files of hosts, which were not entirely
correct. Still one problem left after the corrections which, with your
prompt re: macros, I tracked down to milter_mail_macros = i b in
main.cf, which I r
Thanks, Bill. That did it. :)
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
I assumed it should be in main.cf. I meant which section. I tried to
redefine it in smtpd_helo_restrictions since that seemed reasonable.
Running postconf shows it, as you say set to no but I cannot set it to yes.
--
Dave Stiles
Linkcheck Bristol Web Design
Tel: 0117 9248413
https
On 20/12/2023 3:51 pm, Wietse Venema via Postfix-users wrote:
"smtpd_forbid_unauth_pipelining = yes
I tried that (3.7.6) and got...
warning: unknown smtpd restriction: "smtpd_forbid_unauth_pipelining"
Where should I have placed it?
___
Postfix-user
Thanks, I've now enabled that.
I'm ptrty sure the reason, though, is the single Received line, which
does (can) not give the domain's signing key from DNS.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to po
Thank you for your response, Viktor.
> How does your milter decide which messages to sign? Does it perhaps
look for:
> milter_macro_daemon_name=ORIGINATING
I originally had this in place but could find no reason for it online
nor any sufficient reason to use it, so I removed it, with no a
Saturday morning I put my new postfix mail server into operation,
replacing a years-old previous incarnation (about 15 user domains). The
new one, which has been under test for a long time, seemed to work with
no problems.
Monday morning I had two user complaints - could not send mail from
Th
Thanks for all your help, guys. Appreciated!
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
> GMAIL From: address
From and replyto adresses are all based on the sender domain, so not
appropriate.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
> ... soft_bounce turned on.
Thanks, Wietse, I'll look into it.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
On 28/11/2023 3:07 pm, Bill Cole via Postfix-users wrote:
That's not a result, that's part of the DMARC policy
Oh. Thank you for the correction, Bill. :)
> That should not be enough...
Something is wrong. I wonder if there is a DNS-resolving delay but I
guess Im not going to easily discover
> ipv6
I have...
inet_protocols = ipv4
... with no AAA record
But thanks anyway, Peter.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
If it's only "largely redundant" I would expect G to possibly ignore it
but not fail on it.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
The dmarc results are ambiguous:
r
pass
although dkim fails both tests.
=
google.com
noreply-dmarc-supp...@google.com
https://support.google.com/a/answer/2466580
10845692433607357330
1701043200
1701129599
bristolweb
Thanks for that, Matthew. So not all gmail ones fail. Hmm.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
Thanks, Shawn, appreciated.
Hadn't thought of the dmarc report; I'll check it out.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
27 Nov 2023 13:20:13 +
To: Dave Stiles
From: EnquiryForm
Reply-To: EnquiryForm
Subject: Linkcheck Enquiry: Ref LK_XK27131943E
Message-Id:
X-Mailer: BW-4
X-Originating-Ip: 46.33.129.43
X-Form-Host: www.linkcheck.co.uk
X-Complaints-To: abuse (at) bristolweb.net
Mime-Version: 1.0
Content-T
Thank you, Ralf; I got the form ok.
> Looking good if you ask me
Thanks. I couldn't fault it, either.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
(Sorry, Wietse, I always forget to change the To field)
> gmail rejects all messsages
Seemingly only from web forms. We are in daily contact with at least one
gmail user, with no problem, using the example domain I posted and with
which I'm posting this.
We do get a small number of genuine b
I maintain several web sites containing at least one web form. Forms are
sent to my established postfix server to be turned into properly
constructed email and sent on. The server is used for many conventional
emails per day and set up to provide suitable dkim etc. All domains have
correct SPF,
Thanks, Viktor. That's interesting. You'd think someone like MS could
get it right. :(
Thanks, Bill. That looks rather variable, though. This morning I'm
getting 19 ms on the mail server and 163 ms on my desktop. Mail server
may have the uri in cache, I suppose. But it does look as if the rejects
I get are not my fault.
On 01/11/2022 4:23 pm, Viktor Dukhovni wrote:
> Note that DNS for the recipient domain is provided by "dyn.com"
Noted. I suppose that would explain the 1 second plus delay.
Unless you have a good reason to include "native", you probably should
not.
Thank you, Viktor. Now removed.
Log and postconf as requested.
I could only find 3 lines of log for the transaction - it was part of a
bulk send. It appears the email was actually sent for this one; was it
really?
log entry
Oct 31 12:54:37 BRISTOLWEB postfix/smtp[35040]: A123A320136:
to=, relay=n
As I said, I use unbound. resolv.conf only has 127.0.0.1.
Windows - where does that come in? Haven't used that in years! :)
My apologies, Paul! You are correct re: dashes not dots. I cut/pasted
without paying attention, I'm afraid. 🙁
I originally ran dig on my desktop through my local ISP's DNS as a
cross-check on the domain and did get
bcs-hants-sch-uk.mail.protection.outlook.com. Also on the mail server
(in term
I'm trying to convince myself this is not my fault but I've been getting
several rejections over the past few months. My mail server has been
unmodified for a few years so I THINK it's not that, but sending mail to
(for example) bcs.hants.sch.uk results in:
(Host or domain name not found. Name
Thank you, but there never was an error in my resolver, which I have not
altered in any way. It was my own mistake in applying an incorrect dig. :(
I didn't say SA / spamhaus was causing rejections, merely that I was
following up a discussion on the subject.
And I gave the relevant configs in the OP.
Yes. The sysytem has been working well for years and only now is failing
spamhaus tests. Until the last week or so I have never had a false
spamhaus reject of a valid email.
I have just discovered a spamassassin forum that details a similar
rejection. I am delving into that now.
My apologies. I tried dig on another OS first and that failed.
; <<>> DiG 9.16.27-Debian <<>> 2.0.0.127.zen.spamhaus.org. any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24423
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITI
On 07/08/2022 1:12 pm, Rob McGee wrote:
dig 2.0.0.127.zen.spamhaus.org. any
ANY has to be after DIG, not at the end, but...
; <<>> DiG 9.10.3-P4-Ubuntu <<>> any 2.0.0.127.zen.spamhaus.org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, i
And now, during the past few days, zen has blocked a couple of valid
emails, the IPs of which zen claims to know nothing about.
Last week zen.spamhaus blocked over 280 emails; I've going to miss it.
I have now removed spamhaus from postfix entirely and hope that
spamassassin will catch any nas
On 03/08/2022 3:35 pm, Viktor Dukhovni wrote:
Looks sensible. I'd keep these.
Despite previously blocking valid emails with dbl?
I notice that the spamhaus solution places all the tests into the
smtpd_recipient_restrictions section, whereas I had them in different
sections plus an extra one
Thank you, Matus. I have considered pstscreen in the past but decided it
was an extra layer of complexity I could manage without.
I also find zen.spamhaus reliable but is the spamhaus suggestion for
postfix a) good and b) all that is needed? For example, is dbl.spamhaus,
as they suggest, a goo
I have recently begun getting blocks from dbl.spamhaus.org for "valid"
email. I thought a single instance was an aberration but in all I've
seen half a dozen emails blocked - a large number for my small system.
The original setup was...
smtpd_helo_restrictions =
...
reject_rhsb
Many thanks for all the replies. Appreciated!
> make sure to configure your milter to ignore connections from
127.0.0.0/8
This was the reply that did it. It spurred me to investigate the
/etc/default/spamass-milter config, wherein I had...
OPTIONS="-u spamass-milter -- -d 127.0.0.1"
On looki
I have a relatively new installation of postfix with clamav and
spamassassin milters. In general it seems to work fine.
The debian server sends a variety of notifications from localhost
through postfix to a domain mailbox ad...@example.co.uk. On the way it's
filtered by spamassassin, which is
I run a small postfix/dovecot mail service for my website customers. For
the past several months one of my customers has had mail to gmail
addresses delayed by approx 12 hours. The delaying/rejecting messages
returned by google are on the lines of:
(host alt1.gmail-smtp-in.l.google.com[142.250
Thank you for the notification, Bernardo, but that mail server has been
offline for some time now. It used to be a backup server which is no
longer required. I left it live for the "benefit" of spammers. :)
--
Dave Stiles
Wietse, thank you for your assistance. I tried removing (separately)
unix_listener and unix_listener auth-userdb but neither cured the
problem so they are now both reinstated.
Apart from two connection messages in the log, the three lines I quoted
are the only ones following a restart and are
I am setting up a new postfix/dovecot/etc mail server. Apart from a few
new features, due to new versions, I have copied a similar setup which
has been running well for several years. A few days ago the new server
was working, with just a few tweaks required for dkim/dmarc/etc. At that
stage I
I'm normally careful about this matter but it has happened twice in a
couple of months now due, I admit, to my own carelessness but dumping a
lot of mail before the error was noticed.
The specific problem is with extra or multiple OR bars in pcre checks.
For example:
/trap this|/
/|trap this
Thank you for your response, Christian. Sorry not to have replied
earlier, several things on at the moment. :(
I can't say what the boot screen indicates this time as I have no
monitor set up for the m/c at the moment.
The tmpfiles.d folder was empty. I added in two files (info obtained
from
I have a private postfix server on my local network. It runs under
Manjaro. On booting Manjaro I get half a dozen ERROR lines as:
FAILED: Failed to start (eg) Postfix
All are to do with postfix, dmarc, dkim etc.
I've wondered for some time now why I have to start postfix manually
after reboot
Thank you for that, Wietse.
I'm inclined to agree that talktalk is at fault here, allowing a second
try to succeed.
Has anyone here found this problem with talktalk?
--
Dave Stiles
I have had a few complaints about emails bouncing over the past
week-ish, specifically from a single dynamic IP. Have now found a few
lines in the logs that seem to indicate the problem. Nothing has been
changed (that I know of) apart from a point or two of the Ubuntu
version, so why is there a
> Drop the quotes!
I just have whilst following advice from David Burgin - in fact I
commented out the macro entirely but still the same - dkim ok but
UNPARSEABLE_RELAY still present.
> Where does Postfix documentation say that you need to use quoted strings?
It doesn't, I agree. And forgot
Thanks for your help. I checked as you suggested and got
milter_connect_macros=j {daemon_name} v (no quotes, no underscore). I
commented out my own version and ran with the default, which correctly
includes the mail server name in the dkim check but still has
UNPARSEABLE_RELAY.
I suppose it m
Thanks, but I already had that. Although I had the "v" before the
daemon_addr when I first tried it...
milter_connect_macros="i j {daemon_name} v {daemon_addr} _"
I have now tried it with the v where you suggest it but still gives
UNPARSEABLE_RELAY. Also, I understand the quotes are essential
Ok, thanks. I can live with that.
But what about UNPARSEABLE_RELAY? How can I preoperly fix that? Do I
really have to nullify the rule or is there something in postfix that
I've got wrong?
I applied the recommendations from this thread (for which, many thanks!)
with some help from the spamassassin forum. Almost all of it works now
with the following exception. On postfix restart the following message
is logged.
"Could not retrieve sendmail macro "i"!. Please add it to
confMILTE
Jaroslaw Rafa wrote
> Dnia 4.11.2019 o godz. 04:31:51 linkcheck pisze:
> I don't know as I don't use DMARC. I only DKIM sign outgoing mail, I don't
> verify DKIM nor DMARC on incoming mail. Just try what order works best.
Ok. Thanks for all the help. :)
--
Sent from
@lbutlr wrote
> On 01 Nov 2019, at 10:03, linkcheck <
> postfix@.co
> > wrote:
>> Jaroslaw Rafa wrote
> Apache should not be posting mail via pickup. Use an SMTP plugin that
> authenticates just like anyone else.
If the mail and web servers were separate I would
Sorry for the delay in replying. I've been looking at this and trying to make
it work in my head, but keep coming up with DKIM running twice. Please bear
with me. Your setup of...
smtpd_milters = inet:localhost:10025, unix:spamass/spamass.sock
non_smtpd_milters = inet:localhost:10025
...suggests
Jaroslaw Rafa wrote
> Dnia 31.10.2019 o godz. 12:16:56 linkcheck pisze:
> The best answer is to use spamassassin as a milter, not as a post-queue
> content filter as you have (and as I had).
> After I changed configuration to run spamassassin as milter, everything is
> signed onl
I've looked online for solutions to this problem (including postfix and
sendmail documentation) but with no luck so far.
I've been running a Postfix mail server for several years (currently Linux
Mint 18.1 (Ubuntu 16.4) with postfix 3.1.0) and implemented SPF, DKIM and
DMARC a few years ago. All
Viktor Dukhovni wrote
> With Postfix 3.x the default value of the key file
> parameter is the cert file, and the same file can hold both the
> cert and the key.
Letsencrypt supplies 2 files. I don't think it combines them inso a single
one, though I may be wrong. I know it's possible to combine th
Viktor Dukhovni wrote
>> On Oct 1, 2019, at 9:21 AM, linkcheck <
> postfix@.co
> > wrote:
>
> See http://www.postfix.org/master.5.html (or man -s 5 master).
>
> Since the "-o" options are *overrides*, if an option has the
> right value in main.cf
Viktor Dukhovni wrote
> On Mon, Sep 30, 2019 at 06:53:38AM -0700, linkcheck wrote:
>
>> I have the following for smtp and submission...
>>
>> smtp inet n - n - - smtpd
>> [...]
>> -o smtpd_tls_cert_file=/etc
@lbutlr wrote
> On Sep 30, 2019, at 7:53 AM, linkcheck <
> postfix@.co
> > wrote:
>> I have the following for smtp and submission…
>
> Seems like a lot.
>
> This is all I have, in main.cf:
>
> smtpd_tls_cert_file =
> /usr/local/etc
> In Postfix 3.4
Thanks, but I'm on 3.1.1 due to Ubuntu/Mint version.
> smtpd_tls* is for receiving connections.
> smtp_tls* is for outgoing connections.
> You're specifying the same certificate thus makings it redundant.
> You may shorten it to just two lines in your main.cf:
Thanks. Is that ju
I have been running postfix for several years. The latest certificate has
almost run out so I switched to letsencrypt. Whilst installing the
certificate and key in master.cf it occurred to me to wonder if I wasn't
over-specifying their use. I have checked around the web and found nothing
like my se
67 matches
Mail list logo
