> On Nov 19, 2019, at 5:31 AM, Viktor Dukhovni
> wrote:
>
> If you are considering blocking, try to look at the SpamHaus
> (or similar) TLD worst-offender list, and block just a few of those and review
> the list from time to time.
You may also find useful (a bit dated, but perhaps still releva
Thanks for the info Viktor.
On 2019/11/19 6:48 下午, Viktor Dukhovni wrote:
On Nov 19, 2019, at 5:31 AM, Viktor Dukhovni wrote:
If you are considering blocking, try to look at the SpamHaus
(or similar) TLD worst-offender list, and block just a few of those and review
the list from time to time.
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 in
On 18 Nov 2019, at 15:38, Gregory Heytings wrote:
replace the contents of /etc/resolv.conf by:
nameserver 8.8.8.8
nameserver 8.8.4.4
your problem will likely be solved.
Note that doing this (using Google's public DNS service) will kill the
effectiveness of DNSBLs and of anti-spam tools like
On 19 Nov 2019, at 1:04, Merrick wrote:
Hello,
We plan to setup two postfix as MX servers.
One is in west location, such as CA state.
Another is in east location, such as NYC.
The usefulness of such an architecture in modern times is marginal. If
the "4th nine" (or maybe 5th) is worth doubli
Matus UHLAR - fantomas wrote:
On 18.11.19 18:10, Gregory Heytings wrote:
Bill Cole wrote:
Rejecting mail is a far better choice than delivering to a 'spam box'
since most users never bother looking there for anything. Rejections
at least stand some chance of making enough noise on the sender s
On Tue, Nov 19, 2019 at 09:21:23AM -0500, Bill Cole wrote:
> Generally, a mail server should have a caching recursive resolver
> running locally: either on the same machine or the same truly local
> network.
+1, especially for running on the MTA host itself, on the loopback
interface, with only
Running postfix-2.10.1-7.0.1 on a fully updated CentOS 7.7 box. Postfix is
configured with an OpenDKIM milter like so, which works fine under normal
circumstances:
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept
However, when file permissions
On Mon, 18 Nov 2019 21:08:47 +0100 (CET)
Bernardo Reino wrote:
> $ dig -x 81.91.160.182
> office.denic.de. 3600IN A 81.91.160.182
>
> $ dig office.denic.de
> office.denic.de. 3508IN A 81.91.160.182
>
> which looks OK. See if your resolver also produces the
On Tue, Nov 19, 2019 at 08:13:49PM +0100, siefke_lis...@web.de wrote:
> I use unbound.
>
> I have stop unbound an use the dns direct with resolv.conf.
Why did you stop unbound? Presumably it provides the recursive
service on 127.0.0.1, which is listed below...
> $ cat /etc/resolv.conf
> namese
On Tue, Nov 19, 2019 at 11:10:38AM -0800, Jeremiah Rothschild wrote:
> Running postfix-2.10.1-7.0.1 on a fully updated CentOS 7.7 box. Postfix is
> configured with an OpenDKIM milter like so, which works fine under normal
> circumstances:
>
> smtpd_milters = inet:127.0.0.1:8891
> non_smtpd_milter
On Tue, 19 Nov 2019 14:20:43 -0500
Viktor Dukhovni wrote:
> Why did you stop unbound? Presumably it provides the recursive
> service on 127.0.0.1, which is listed below...
It work not. That's why so a line direct to nameserver and it work
also not.
> > Nov 19 19:58:20 netcup.silviosiefke.com p
On Tue, Nov 19, 2019 at 02:28:34PM -0500, Viktor Dukhovni wrote:
> On Tue, Nov 19, 2019 at 11:10:38AM -0800, Jeremiah Rothschild wrote:
>
> > Running postfix-2.10.1-7.0.1 on a fully updated CentOS 7.7 box. Postfix is
> > configured with an OpenDKIM milter like so, which works fine under normal
> >
On Tue, Nov 19, 2019 at 11:39:03AM -0800, Jeremiah Rothschild wrote:
> > It seems the tempfail is from the milter, not from Postfix. Postfix
> > is not in a position to know that the milter is not working as it
> > should, the milter is responding "normally".
>
> That's too bad. I'm surely overs
On Tue, Nov 19, 2019 at 08:38:53PM +0100, siefke_lis...@web.de wrote:
> > Why did you stop unbound? Presumably it provides the recursive
> > service on 127.0.0.1, which is listed below...
>
> It work not.
Then figure out how to make it work. That should be your one and
only nameserver.
> > >
On Mon, 18 Nov 2019 17:23:43 +0100 Matus UHLAR - fantomas
wrote:
seems something is wrong with your (or maybe their) reverse DNS
resolution...
On Mon, 18 Nov 2019, siefke_lis...@web.de wrote:
This is what I had:
[siefke@sisi-dell ~]$ nslookup 195.128.103.214
214.103.128.195.in-addr.arpa
On 19.11.19 10:24, Angel L. Mateo wrote:
I have a mail server relaying for different domains and using a
transport map to deliver local domains.
Now I need the following:
* Mail from @internal1.com and to @external1.com to be relayed through
relay.provider.com
do you mean, random spam
Am 19.11.19 um 10:58 schrieb Merrick:
> may we suggest ICANN not open a new TLD anymore?
yes, you can: https://www.icann.org/public-comments
Hi,
In http://opendkim.org/opendkim.conf.5.html there are several error
conditions defined, with the default actions for them, for instance
"On-SignatureError", "On-KeyNotFound". Ar least some conditions default
to tempfail. Configure the milter correctly and you should be fine.
Kind regards
But I predict it will fall on deaf ears…
Suggesting this is tantamount to suggesting the PSTN not increase the # of area
codes or NXX numbers. Things like this are created as the demand grows…and due
to the complete metamorphosis of the Internet over the last last 20 years,
demand has definite
> On Nov 19, 2019, at 3:28 PM, Antonio Leding wrote:
>
> But I predict it will fall on deaf ears…
>
> Suggesting this is tantamount to suggesting the PSTN not increase the # of
> area codes or NXX numbers. Things like this are created as the demand
> grows…and due to the complete metamorpho
Demand is demand…it doesn’t matter from where it originates….
> On Nov 19, 2019, at 12:59 PM, Charles Sprickman wrote:
>
>
>> On Nov 19, 2019, at 3:28 PM, Antonio Leding wrote:
>>
>> But I predict it will fall on deaf ears…
>>
>> Suggesting this is tantamount to suggesting the PSTN not inc
On Tue, Nov 19, 2019 at 10:24:30AM +0100, Angel L. Mateo wrote:
> * Mail from @internal1.com and to @external1.com to be relayed through
> relay.provider.com
If internal1.com is just one of your internal domains, and the policy
should apply to just some of your internal users, then this is a pol
Thanks Bill for the kind suggestion.
regards
Bill Cole wrote:
On 19 Nov 2019, at 1:04, Merrick wrote:
Hello,
We plan to setup two postfix as MX servers.
One is in west location, such as CA state.
Another is in east location, such as NYC.
The usefulness of such an architecture in modern t
On 2019-11-19 05:59 GMT, Viktor Dukhovni wrote:
> On Mon, Nov 18, 2019 at 09:40:24PM +, Nick wrote:
>
> > Why did reject_unauth_destination (line 11) only take effect after the
> > probe (line 8, if that's what it is) and after check_policy_service
> > (line 10)?
>
> Because Postfix evaluates
On Tue, Nov 19, 2019 at 08:21:07AM +, Nick wrote:
> > Because Postfix evaluates smtpd_relay_restrictions *after* it checks
> > smtpd_recipient_restrictions.
>
> postconf(5) says the opposite.
>
> smtpd_recipient_restrictions (default: see postconf -d output)
>Optional restrictions
On 2019-11-19 08:37 GMT, Viktor Dukhovni wrote:
> Sadly, the implementation changed without a documentation update.
I see.
> > If possible, when my server receives an unwanted relay attempt I would
> > prefer it did not make pointless queries to third parties. Can that
> > be accomplished?
>
>
On Tue, 19 Nov 2019, Merrick wrote:
Bernardo Reino wrote:
The messages should be stored in one place, such as webmail/IMAP could
read all messages directly from this location.
Use a single IMAP server. Have both mail servers deliver the messages to
the single IMAP server.
Do you mean I set
Bernardo Reino wrote:
Perhaps you first need to think/consider what you actually want. I
cannot recommend you to install an IMAP server in Dallas or any other
location.
Maybe you don't even need or want IMAP but want to deliver mail to a
local mailbox, or relay to another server, etc.
If
On Tue, 19 Nov 2019 at 08:56, Merrick wrote:
> My purpose is to setup two MX servers in different locations for high
> availability.
> But I am not sure how the two MX servers handle message storage.
>
If you are a small organisation you could consider relaying into Gmail. Or,
easiest of all, us
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
smtpd_recipient_r
Hi,
I have a mail server relaying for different domains and using a
transport map to deliver local domains.
Now I need the following:
* Mail from @internal1.com and to @external1.com to be relayed through
relay.provider.com
* the rest of mails, to be deliver or relayed according to
Dominic Raferd wrote:
If you are a small organisation you could consider relaying into Gmail.
Or, easiest of all, use G Suite (which is free for non-profits).
I know there is gsuite exists, :)
Also a lot of cheap providers like MXroute on the world.
We just want to make an email service for o
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".
in the coming future, everything is a TLD, the cat, the dog, the pig,
the rose, the coffee, the wine, the bike ...
that would be terrible for domain based validation.
we have already too many TLDs today.
may we suggest ICANN not open a new TLD anymore?
regards.
> On 19 Nov 2019, at 09:58, Merrick wrote:
>
> in the coming future, everything is a TLD, the cat, the dog, the pig, the
> rose, the coffee, the wine, the bike ...
> that would be terrible for domain based validation.
> we have already too many TLDs today.
> may we suggest ICANN not open a ne
On Tue, Nov 19, 2019 at 05:58:02PM +0800, Merrick wrote:
> May we suggest ICANN not open a new TLD anymore?
More gTLDs are already planned, and will likely be added soon. Many are
"brand" TLDs, and are just "hoarded" as trademarks, or very lightly used
exclusively by the trademark holder, so are
37 matches
Mail list logo
