For cases like the one you have in mind, it is necessary to use a
milter.
Thank you for saving me some head scratching. It wouldn't be the end
of the world to spin up an Exim VM (its system_filtering is capable of
this black magic), but would prefer staying in Postfix.
Do you have a
My Postfix server handles message for a dozen domains, for one of these
domains, I want the subject replaced with the recipient's local part, so
something like this, but put in a format that Postfix understands:
# domain3.com is the one recipient domain we want affected by this rule
#
michae...@rocketmail.com:
I've a generic question to all more experienced than me postfix users
here: Is it nowadays (reasonable) possible to run postfix with IPv6
only? E.g "mail.example.com" and "smtp.example.com" with only ipv6
records in the DNS, no A / ipv4 anymore?
In
Ranjan Maitra:
Wietse Venema:
Corrected code follows (missing do/done).
Save to file, chmod +x name-of-file, don't run this script from cron.
It needs to be started at boot time, or before you make a VPN
connection.
#!/bin/sh
while :
do
ifconfig xxx | egrep 'UP|DOWN'
sleep 2
Stefan Claas:
postfix should modify outgoing email headers that *only* go to mail2news
gateways, using the email gateway addresses for parsing, so that the
right part of the message ID, after the @ charachter, will be modified
with a defined string.
Do you mean "should modify outgoing
Hi,
I'd second Viktor Dukhovni's opinion. For the vast majority of mail
servers, a minimalistic DMARC policy suffices, just add the following
record in the domain's DNS root zone:
_dmarc 10800 IN TXT "v=DMARC1; p=none;"
If you want to go a step further, you can just monitor how DMARC is
Plain old greylisting can yield many false positives, but recent
implementations of milter-greylist for example will not greylist
messages that validates SPF. It helps *a lot*.
The question is: does it only help "a lot", or is the result "zero false
positives"? I personally don't
And there are various techniques (for example connection rate limits,
response delays, greylisting) that prevent you from "accepting all
mail" and that have zero false positives.
As for greylisting, it's no more true now.
Some large and popular mail sending services started some time ago
*Everything* short of accepting all mail regardless has false positives.
Rejecting emails for non-existing users, or for domains of which your are
neither the final destination nor a relay, or coming from non-existing
domains, are filtering schemes that have zero false positives. And
Sending systems will automatically back off and retry at intervals (I
have seen this happen when I have upgraded my home server in the past)
so will a secondary/backup MX actually help at all?
It's up to you to decide what your priorities are. It's true that sending
systems
My purpose is to setup two MX servers in different locations for high
availability.
I'm not sure I understand your question, but I guess that what you want is
a secondary MX in case the primary MX becomes unavailable for some reason
(power outage, server crash, whatever). If this is
This should really be fixed. SMTPD_ACCESS_README (five times),
ADDRESS_VERIFICATION_README and RESTRICTION_CLASS_README specify that
"reject_unauth_destination is not needed here [= in
smtpd_recipient_restrictions] if the mail relay policy is specified
under smtpd_relay_restrictions".
Nick wrote:
But postconf(5) says "smtpd_recipient_restrictions ... applies in the
context of a client RCPT TO command, after smtpd_relay_restrictions."
If smtpd_relay_restrictions applies first, why didn't its
reject_unauth_destination cause rejection before anything in
1 Nov 18 01:28:37 rolly postfix/postscreen[26770]: CONNECT from
[162.246.19.201]:61693 to [46.235.227.79]:25
2 Nov 18 01:28:43 rolly postfix/postscreen[26770]: PASS NEW
[162.246.19.201]:61693
3 Nov 18 01:28:43 rolly postfix/smtpd[26774]: warning: hostname
rever.aftermathdevelopment.com
Now I try to send mail to box and what happen:
Nov 18 17:12:35 netcup.silviosiefke.com postfix/smtpd[6215]: NOQUEUE:
reject: RCPT from unknown[81.91.160.182]: 450 4.7.25 Client host
rejected: cannot find your hostname, [81.91.160.182];
from= to=
proto=ESMTP helo=
This means that a
Two other users replied to your question. For real-world mail servers,
my experience is that the only safe restriction (safe = no false
positives) is "reject_unknown_reverse_client_hostname".
Irrelevant to HELO argument filtering.
Relevant to rejecting emails. Perhaps I should have
Hi,
I know it’s an RFC violation, but I see no email that is delivered with
a bare IP helo that is legitimate.
That might be your experience, but RFC 2821 (3.6) and RFC 5321 (2.3.5 and
4.1.4) explicitly state that an address literal can be used after
HELO/EHLO. So it's a RFC violation
Hi,
Is it safe (or mostly safe) to simply block attempts to deliver mail
with a helo that is only an IP address? (I am talking about only on
postfix/stmpd and obviously not on postfix/submit or related).
No it is not, it's a RFC violation. The string that follows HELO/EHLO is
purely
Hi,
Postfix is giving me a very unhelpful message of just "SASL plain
authentication failed:".
My guess is that you have set "log_path" in your dovecot.conf. If this is
the case, the other line of the message appears in the dovecot log file,
for instance:
mail.log: ... SASL PLAIN
19 matches
Mail list logo
