Re: Extended 5xx code (was Re: Drop UCE instead of forwarding off-site?)
- From: "D. Stussy" <spam@xxxxxxxxxxxxxxxx>
- Date: Sat, 16 May 2009 18:04:58 -0700
"David F. Skoll" <dfs@xxxxxxxxxxxxxxxxxx> wrote in message
news:355cc$4a0ec3fc$d1d97a75$27016@xxxxxxxxxxxx
D. Stussy wrote:friendly
Also note that there is a potential race condition regarding spam
classification that uses external databases (DNSBLs, checksums,
etc.). No matter how good your front end MTA is, there's always a
chance that a given message's spam status changes after the front
end has accepted it and before the back end forwarded target MTA
receives it. That validates the suggestion for "ExtendedErrorDrop"
and its purpose to quash backscatter.
No, it doesn't validate the suggestion. If the back-end server
(a) thinks something is spam, and (b) realizes it's coming from a
server, it should silently discard it rather than rejecting it.
This kind of test is trivial in MIMEDefang and is in fact built into
our commercial product. We avoid backscatter by not 5xx'ing spam from
friendly servers.
OK, but that still requires that the sending server transfer the message.
I note that such a rejection need not occur at the DATA stage.
For example, with MIMEDefang, we have $RealRelayAddr, which is set at the
front-end of a group (two or more) of cooperating MTAs. It's possible that
a back-end could still perform a DNSBL check on this value, and due to
changes in listing at the DNSBL, the message source is now listed (but
wasn't when the front-end system checked). In such a case, the back-end
system may be rejecting at the MAIL FROM stage, thus saving both systems
the cost and overhead of transferring the message. What you suggest is
that the message be accepted (by returning DISCARD from "filter_sender()")
so that the message is transferred out of the front-end with the back-end
MTA placing it in the bit bucket.
If the back-end were to reject, using a DSN recognized by the front-end to
discard instead of NDR, the same overall delivery result happens (discard),
but we AVOID a worthless transfer (instead, the FRONT-end bit buckets the
message). Such a transfer could be on a private network or across the
Internet if a known forwarding service is used. [e.g. a registrar where a
domain has a "private registration"]. Note that the two MTAs involved in
the forwarding need not be under the same administrative control and this
could still work.
I see that under the current state of SMTP and the software available,
having the back-end accept and discard is all that is possible. However, I
don't like it because technically, it's a lie: Accepting a message just to
throw it out vs. telling the sender to throw it out (the proposal) - which
is cleaner?
I think it's cleaner to have a back-end (forwarded to) server tell the
front-end (forwarder) that it may/should discard. Servers check several
sources to determine the maliciousness of a message - and I see no reason
why the next server in the delivery chain should be excluded from those
sources*.
* - I note that MIMEDefang has a feature, md_check_against_smtp_server(),
which can call ahead (as well as execute "dreaded callbacks"), but as long
as we're checking the back-end server, we might as well actually deliver
the message - instead of performing those steps twice.
.
- Follow-Ups:
- Re: Extended 5xx code (was Re: Drop UCE instead of forwarding off-site?)
- From: David F. Skoll
- Re: Extended 5xx code (was Re: Drop UCE instead of forwarding off-site?)
- References:
- Drop UCE instead of forwarding off-site?
- From: Hauke Fath
- Re: Drop UCE instead of forwarding off-site?
- From: D. Stussy
- Extended 5xx code (was Re: Drop UCE instead of forwarding off-site?)
- From: David F. Skoll
- Drop UCE instead of forwarding off-site?
- Prev by Date: Re: Emails bypassing Barracuda, going straight to Sendmail
- Next by Date: Re: Extended 5xx code (was Re: Drop UCE instead of forwarding off-site?)
- Previous by thread: Re: Extended 5xx code (was Re: Drop UCE instead of forwarding off-site?)
- Next by thread: Re: Extended 5xx code (was Re: Drop UCE instead of forwarding off-site?)
- Index(es):
Relevant Pages
|