In message <200604121721.24914@???>, Magnus Holmgren
<holmgren@???> writes
>> In message <200604121400.40493@???>, Magnus Holmgren
>> <holmgren@???> writes
>>
>> >It is a good idea to reject likely to certain spam
>>
>> ITYM "fail to accept"
>
>What do you mean?
Reject has an active connotation, whereas "fail to accept" makes it
quite clear that you just send a 5xx response to the attempt to send it
to you. The world is full of systems that accept email, mull it over
and then create a DSN :(
ie it was basically a remark made in clarification for the onlookers...
>> >, because in the rare cases
>> >of false positives the legitimate sender will be notified. It is also a
>> > good idea to have at least as good spam protection at the (forwarding)
>> > secondary MXes as at the primary. But what is the best way(s) to handle
>> > .forward-ed mail coming from friendly but slightly stupid (in the sense
>> > that they lack adequate spam protection) hosts,
>>
>> It is best to ensure that you do not use any scheme that is traffic
>> based (viz: "the last <n> from here were spam, hence I will make an
>> assumption about the next <n>") but only content-based (viz: "I will
>> look at each message and form an opinion about it").
>
>Well, I'm not saying anything about how spam should be detected.
I am.
I'm pointing out that when considering systems that are expected to
forward you email, most of the "reputation" types of analysis are
useless (indeed counterproductive). You can only consider the content.
> I'm saying
>that if we get what we (our software) believe is a piece of spam from a host
>that the recipient knows does not belong to a spammer, then perhaps we
>should, out of courtesy, not cause that host to bounce it.
Unless your analysis is perfect and you are 100% sure that the sender
did not intend to send it, then accepting it and discarding it will
sometimes (not often, but sometimes) cause problems.
Consider, just for a moment, the effect of a false positive :(
It will be the other host's bandwidth, disk space and reputation that
take a beating. That's very much their decision and tradeoff not yours.
Second-guessing what they are trying to achieve is unhelpful.
For one example about second-guessing: systems that fail to accept
email for invalid recipients produce very distinctive patterns in the
logs of the sending MTA. These logs can be analysed and action taken
to deal with insecure customers. If the remote site accepts all the
email, it isn't possible to distinguish this case from the operation
of a legitimate mailing list.
>> Note that the world is full of people who are forwarding email from one
>> site to another, one ISP to another -- and schemes (readers are familiar
>> with several) which assume that you can read something into the
>> relationship between the source of an email, where it says it comes
>> from, and how legitimate it is, are doomed to fail in today's
>> conditions.
>
>Again, I'm not making any assumptions as to what is spam and what is not. How
>spam is recognised is a separate issue. What schemes are you thinking of?
SPF, Sender-ID and their many friends
>> >d) User-managed ~/.backward (or a database or whatever) containing
>> > addresses and/or hosts forwarded from.
>> If you have 3 users, go for it. If you have 30, 300 or 3 million then
>> get yourself a more interesting (and less privacy invading) hobby! You
>> will merely end up rejecting a lot of legitimate email and dealing with
>> extremely annoyed users :(
>
>No, you have misunderstood me. Let's say that you have a policy to reject mail
>that is with 99.9% certainty spam, accept mail that is with 99% certainty
>ham, greylist the rest a
If you are dealing with legitimate forwarders then the greylisting is
either not going to do anything (they once retried and are now in a
permitted list) or is causing them to have longer queues than necessary
(which, frankly, is dumb).
>nd tag any probable spam that slips through
>(hopefully under 10 per day) so the user can deal with it any way she wants.
>Now, for mail from some hosts (different for each user), instead of rejecting
>we just tag it. That will *not* cause a lot of legitimate email to be
>rejected.
correct, but your users may not be impressed. There you were, 99.9%
certain that it was spam and you put it into their inbox anyway, just
because the previous hop was a competently run MTA...
... but they're your users. So I should not really judge.
>And is this more privacy-invading than .forward files?
Uf you're dealing with lots of customers and trying to work out which
flows of email are forwarded and which are spam runs coming through
insecure customers at major ISPs (but traversing their MTA) then you
will have to look at a lot of their traffic data
You may be considering letting users configure this themselves. That may
also be jolly good fun when their idea of the source "Gradwell",
"Virgin" or "Yahoo!" doesn't match the host level identification you
require :(
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
