Am 22.09.2017 um 18:19 schrieb Davide Marchi:
Hi friends,
On Debian Jessie, Postfix 2.11.3 and Spamassassin 3.4.0-6, I've just
setup an MX email backup server and now I realize that new spam come
from the MX backup server..
Is there any way to tell to reject any mail coming to the MX backup
server, if the primary server is up?
*Reindl Harald wrote:*
how do you define "the primary is up"
just because you reach it don't mean it's reachable from the whole
internet over every route - that's to start why this is just impossible
and i have seen fools implement this
frankly SMTP is designed to deliver later - the only justification
for a backup-mx is a second IP on the same machine as the primary which
*always* makes a temporary 4xx reject and since most spambots which
first try the backup-mx won't fall back to the primary problem solved
Thank you for your suggestions, I will consider it
*Marc Perkel wrote:*
Yes - that's a favorite trick of spammers to hit the backup server.
If you want you can add a third (fake) backup server:
tarbaby.junkemailfilter.com
It returns 451 on everything and gets rid of some of that spam
(spammers don't retry) and I get some training data for my black lists.
interesting, (i didn't know this trick), but as David Jones wrote this
could cause "very long delays with greylisting":
[..]
*David Jones wrote:*
I tried using tarbaby.junkemailfilter.com as my highest/third MX and
ran into delivery problems due to greylisting. MTAs will back off and
retry at different intervals which can cause very long delays with
greylisting.
Look at the MX records for ena.com. My smtp2.ena.net _always_ temp
fails everything which is attacked by spammers and bots. smtp.ena.net
has mutliple A records to load balance across two different data
centers. This has worked very well with greylisting so if you can
rethink your A records behind the MX records, then I would recommend
going that route like I did.
# dig ena.com mx +short
10 smtp.ena.net.
20 smtp2.ena.net.
# dig smtp.ena.net +short
96.5.1.4
96.4.1.4
and then:
What is the MTA you are using?
Postfix 2.11.3
You could script some postconf commands on the secondary (higher
priority) MX to temp fail everything until the primary is unavailable
then adjust/reload default configs from the primary server to start
accepting mail.
This is not clear for me: what do you mean (and eventually how do it)
for: "script some postconf commands on the secondary (higher priority)
MX to temp fail everything until the primary is unavailable then
adjust/reload default configs from the primary server to start accepting
mail"?
Thanks!
If you do this, then you need to make sure the secondary servers are
setup identically to the primary to filter identically.
the two setup are identically.
*Ralph Seichter ha scritto:*
[..] Have you not just recently asked this on the Postfix mailing
list? [..]
Yes I do. And even if it could not be a problem closely linked to
SpamAssassin, discuss it here, as you can see, is always useful.
Especially for that like me is not so expert on postfix/spamassassin.
Add a Postfix sender restriction that rejects all mail apparently
sent
by foo@your.domain via port 25 of your MX. Only allow this to happen
on
port 587 (submission) and for authenticated users. See Postfix docs
for
details.
on my server, the port 25 is closed, and only port 587 is operative,
thanks!
*Marc Stuermer wrote:*
The easiest way by far is to shut down the backup server forever.
Every sane MX host normally queues outgoing mail for five days and
retries its delivery frequently, so when the primary MX is down for a
short period of time, you'll loose nothing, because when he's up
again
all waiting mail starts to come in anyway.
So the use case and need for a backup MX normally is quite narrow
down
to non existant for most people.
It is true what you say and I am aware of it and even this could be a
solution, but I would like to consider it only as an extreme solution
Thanks!
Thanks to all,
I hope I haven't done too much chaos putting all the mails in the same
answer!
Have pity on me
Davide
--
cosmogoniA
cosmogoniA<https://www.cosmogonia.org/>
n o p r o v a r e n o f a r e o n o n f a r e n o n c e p r o v a r e
