From: list-ietf-antispam(_at_)faerber(_dot_)muc(_dot_)de
(=?ISO-8859-1?Q?Claus_F=E4rber?=)
But secondaries are not only used when the primary MX is not available.
Spammers reportedly use them to circumvent problems with the primary.
There are far simpler ways to deal that spammer attack than to make
the secondary try to contact the primary to pass the message syncronously
through the primary.
1. If you really think that passing the message synchronously through
to the primary can work, then you don't need the secondary and should
delete it. In these days, MX secondaries often cause more problems
than they fix, particularly for systems that deal with fewer than
500,000 message/day.
2. hide the secondary among duplicate RRs for the primary. For example,
srvr IN A 10.2.3.4
IN MX 10 srvr
IN MX 20 real-secondary
IN MX 20 srvr
...
It's not saying "don't return bounces" but "dont't return bounces if you
can avoid it".
If you can't do it due to performance reasons, a network outage, or any
other reason, then don't do it. But the MTAs should take all sensible
measures to avoid having to send bounces.
Nobody disagrees with that. The problem is with uninformed and
incorrect claims incorrect that bounces are not needed, and with the
unworkable and inapplicable mechanisms to eliminate relaying.
A bigger issue is that no one has shown that bounces are a significant
spam problem. The talk about fixing bounces amounts to individual
demonstrations of problem solving powers and has little or nothing to
do with solving the spam problem.
.......
] From: Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
] ...
] Delays in closing off transmission of the content very much DO lead to
] duplicates. ...
] CF> The receiving MTA can take all the time it needs to process the message
] CF> as long as it can still abort processing.
]
] People forget that connections can terminate abnormally ...
It might help to paint the duplicate problem explicitly:
SMTP client SMTP server
1. send("DATA\r\n"
msg text
"\r\n.\r\n") -->
2. recv(msg)
(delay for spam filtering etc)
(network between client & server dies)
3. <-- send("250 OK")
4. close()
5. (gets error on recv()) (gets error on close())
At this point, the SMTP server has no idea whether the SMTP client heard
the "250 OK", and so the SMTP server cannot know whether to deliver or
discard the message. The SMTP client has no idea whether the server
sent "250 OK", "5yz reject", or crashed, and so the SMTP client cannot
know whether to send again. No matter what the client and server decide,
there will be cases of duplicate or lost mesages. The more time between
step #2 and step #3, the more likely this problem becomes.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg