|
|
 |
| Re: BACKSCATTERER problem... We are an ISP |
|
 |
|
 |
|
 |
|
 |
Author: phil-news-nospam Date: Jan 31, 2008 20:00
On Thu, 31 Jan 2008 17:08:17 GMT Larry M. Smith fahq2.com> wrote:
| Martijn Lievaart wrote:
| (snip)
|>> Such discarding or "dead.letter" silliness goes against the published
|>> SMTP specs.
|>
|> Yes and no.
|>
|> First and most important, the RFCs were written without massive spamruns
|> in mind. So the argument that something is required by RFC, an argument I
|> use in different situations myself quite often, is less applicable to
|> todays Internet mailing systems.
|>
|
| Irrelevant. If you need to break SMTP in order to fix it; then you need
| to either expand it via extensions, or scrap it and write another
| transport for email. Either way you will need to write another set of
| specs and hope the world also finds them useful.
The existing specs, save for the few changes suggested here to deal with
spam, still work. The "non-compliant" changes suggested simply result in
a different behaviour, not an incompatibility.
|> Secondly, storing in some dead.letter (or spamfolder, or whatever) counts
|> as a delivery for me, so the RFCs are sattisfied. Dropping is indeed
|> against RFCs.
|>
|
| I guess this depends on how you define "dead.letter" ... From the
| original reference I took it to mean "a file that may or may not be
| looked at, and not under the control of the intended recipient"... This
| is NOT a form of delivery that would satisfy the RFCs; as the intended
| recipient hasn't received the message. However, dropping it into a junk
| mailbox that the recipient controls IS delivery.
This is one reason I do not do content scanning/filtering. I base all
the accept/reject decisions based on the client IP and information that
can be obtained about it. The decision then constitutes a peering
policy, rather than a protocol behaviour. If the mail is rejected, it
is because I don't want to peer with that client. In a non-peering
state, all protocols are irrelevant. I'm just courteous enough to go
ahead and pretend to continue as SMTP and give a rejection, rather than
simply dropping all IP packets and let the connection go stale or not
even accept the connection in the first place. I could do the latter
and in fact have not ruled out the possibility in the future. But I
consider the "pretend SMTP" to be a not-too-costly form of courtesy.
|> But the best solution is not backscattering by checking wether one can
|> deliver before accepting the message. This is not always possible, but
|> more often than not it is.
|
| The best solution for reducing the symptom is; to reduce the problem...
| But in this case the problem is forged spam that is returned
| undeliverable, and not Aunt Hattie's misspelled recipient. We still
| want our favorite aunt (on our mother's side) to know that mail to us
| hasn't been received... The best way to do this is to block it as soon
| as possible and not accept the message into the remote system.[1]
Right.
| MTAs have become more and more advanced over the years, and nothing in
| SMTP prevents the MTA from actually checking to see if the user is
| valid, or check for other problems that might prevent local delivery.
| It gets a little trickier for forwarded mail, but I suspect that even
| backscatter from this could be minimized. But either way, MTA authors
| need to be aware that backscatter is a problem and write their MTAs with
| additional tools that can address the issue.
Even the forwarding issue is solvable, although the solution is costly.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-01-31-2135@ipal.net |
|------------------------------------/-------------------------------------|
|
|
|
|
|
|
RELATED THREADS |
  |
|
|
|
|
