Re: Extended 5xx code (was Re: Drop UCE instead of forwarding off-site?)



"David F. Skoll" <dfs@xxxxxxxxxxxxxxxxxx> wrote in message
news:355cc$4a0ec3fc$d1d97a75$27016@xxxxxxxxxxxx
D. Stussy wrote:
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
friendly
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.


.



Relevant Pages

  • Re: auditing activesync logon events
    ... A front-end server keeps an HTTP session connected to it and proxies the ... the appropriate back-end server for the mailbox. ... the Internet so that Internet clients don't need to contact the back-end ...
    (microsoft.public.exchange.admin)
  • Re: Front-End and Back-End Configuration Options
    ... Advantages of a Front-End and Back-End Topology ... Configuring and Securing Microsoft Exchange 2003 Server and Clients ...
    (microsoft.public.exchange.setup)
  • Re: auditing activesync logon events
    ... I don't see advantages in having Front-End servers. ... the performance of the Back-End gets better if you put a Front-end server. ... Ok, but then, if you want a good security system I think ...
    (microsoft.public.exchange.admin)
  • Re: Need ideas for managing large table...
    ... What kind of server is running your SQL-Server back-end? ... I'm not sure why an Access front-end for reporting purposes ... > queries to get the results I need. ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Help please. Outlook express or comcast is creating misleading mail headers
    ... and go down to the "Outgoing Mail Server" section. ... > headers, but the smtp mail host that comcast uses now includes that in all ... MTA, and the aosake.net MX. ... that the filters are working for. ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)