Re: [exim] Anti Phishing Trick

On Thu, 25 Aug 2005, Fred Viles wrote:

> Skipping the bits Marc answered:
>

> On 25 Aug 2005 at 11:34, Marilyn Davis wrote about
>     "Re: [exim] Anti Phishing Trick":

>

> | On Thu, 25 Aug 2005, Fred Viles wrote:
> |... 
> | > On 25 Aug 2005 at 10:18, Marilyn Davis wrote about
> | >     "Re: [exim] Anti Phishing Trick":
> |...
> | I'd say that spam ought not generate an auto-response or DSN that gets
> | anywhere, except back to the spammer or a blackhole.

>
> Then we agree.

I'm thinking this too. But I'm guessing that there's probably a limit
and I'm hoping to push on it.

>
> |...
> | > If by "collateral mail" you mean all auto responses and DSNs,
> | > nothing. My point is that every reasonable effort should be made to
> | > avoid generating such for cases 2 and 3. Specifically, generating
> | > such for detected spam from known forwarding hosts should be avoided.
> |
> | Detecting spam from "known forwarding hosts" means using the
> | blacklists?
>
> No. The context here was Alan's message talking about specific
> external hosts on which he and/or his users have accounts, and those
> accounts are configured to forward all messages to accounts on his
> system.
>
> So that's what I meant by "known forwarding hosts", not open relays.
>
> | If you auto-respond to spam from a known forwarding host,
> | unless it is a joe job, what is the bad thing?
>
> If you respond to *any* spam, auto- or otherwise, the bad thing is
> that in the real world the most likely recipient of that response is
> an innocent third party. But in Alan's case, his system is not
> generating a response itself, it is doing an SMTP-time rejection that
> is known to cause a known forwarding host to generate a DSN.
>
> The "known forwarding host" part is important. Rejecting mail that
> is being forwarded by abused or open relays will also led to DSNs
> being generated, but in that case I'm unconditionally in the camp
> that says it is the relay's problem.
>
> More similar to Alan's case, I'd also agree that there's no
> reasonable way an ISP could give special treatment to forwarders its
> customers may set up.

Yes. There are several instances where autoresponse, not at SMTP
time, is indicated, like it or not.

>
> Alan's case is more grey, as the admin of a university system with a
> limited (but large) set of users. But by his own description, he
> knows about a specific set of external hosts that he and other users
> have forwarding accounts at, which cause problems. It's his decision
> to inflict avoidable damage on third parties for those known cases,
> rather than risk silently dropping an occasional false positive or
> expend more resources to prevent it.
>
> I'll readily agree that quarantine-and-review is not feasible in
> Alan's case (unlike my small site), so it comes down to us
> disagreeing which is the lesser of two evils: knowingly causing
> collateral spam to be generated, or dropping an occasional legitimate
> message.

I'm with Alan on this one.

I'm a big fan of object-orientation in code, I note that it is the
rule in Nature, and believe it's the best rule for the mail system too
(and political entities as well). So my first obligation is to my own
system and users, to deliver all their legitimate mail and not bother
them with junk. My second obligation is to the system at large, and
to you and your customers.

In this regard, I like the architecture implied by SPF because I
publish and maintain my own SPF record and the SPF is not an
"authority" but a service. And I don't like the architecture implied
by blacklists because someone else publishes info about me (breaking
object-orientation) and serves as a central authority/cop. (My son's
domain was once spuriously black-listed and that's a terrible thing.)

And, I do like challenge/response because I can protect my users from
a joe job, as well as spam. Of course, being ridiculously moral, I
don't want to contribute to your joe job, but, by object-orientation,
it's my secondary consideration. And my best idea (so far) for that
is to suggest some new protocol to simply accept and control
auto-response mail and stop joe jobs.

If we were in cahoots on this, it could go like this. On all your
outgoing (non-autoresponse) mail, you would include a new header,
maybe Autorespond-Key: and put anything you want in that field, and
change it often and have it contain any helpful info you'd like to
receive back. On all autoresponse messages that I send, that are
generated past SMTP-time, I add a Autorespond-Key: header and copy
your header data. Then you know that that autoresponse is legit, no
doubt and absolutely. If you don't send me an Autorespond-Key:
header, I can put the $sender_host_address in the Autorespond-Key and
give you a hint that way.

It's not a perfect world and I wouldn't expect many mail admins to be
interested in such a scheme, but a mail admin who did conform would be
doing the best she could to keep joe job's out of innocent people's
mail.

And I don't like spam filtering because, as you guys point out, the
ads get more and more targeted, and because the battle puts us on the
expensive defensive where a spammer does a little tweak and we have to
work and scramble to catch up again. With C/R, we do a little tweak
on our OCR font and the spammer has to work and scramble to try to get
through again.

Now, I'm breathing deep and expecting flames, which always hurt.

But please, before you flame me, take the whole argument into
consideration, and especially the details.

With fondness and huge respect for this list,

Marilyn

>
> - Fred
>
>
>
>
>
>

--