Re: A request to all mail admins

Jem Berkes <jb@users.pc9.org> writes:

> A request to mail system admins: if you have virus scanners or some sort of
> worm/attachment blocking mechanism, please configure it to NOT send notices
> back to the sender that they sent a virus.
>
> These modern windows worms all forge the sender anyway. There are people
> like me who, unfortunately, have their addresses on too many windows
> users' address books and my inbox is flooded with "you sent a virus"
> notices. The notices just add to network congestion, and these are an
> avoidable bounce.

Agreed, with a couple other thoughts:

a) if you're going to bounce a viral mail, damn' well leave the attachment
in place so I can reject it.

b) bouncing virus mails is just as stupid as replying to any other kind of
UBE - it's automation of generating replies (new mails with different
envelopes), and is similarly moronic.

c) If you reject at the SMTP stage (ie the last state message after reading
in all the DATA is `550 Bog Off') then while you are giving the real sender
a message, and you're not generating the bounce yourself, you do risk
causing bounces from clueless smarthosts. I still maintain that this is a
misconfiguration error, for which the masses of innocent victims of
backscatter should mail postmaster@[smarthost's domain] to complain.

d) It would be nice if there were more of a way to tie in checks that "is
the bounce likely to go back where it came from?" at SMTP stage; we already
have the ability to do MX lookups on the Sender/Return-Path/mail-from
domain, and to connect into those MXes to see if they accept mail for the
user from <>; it should be possible to devise an algorithm where the
closeness of IP# for the MX of the return-path-to-be-used-in-a-bounce is
measured relative to the incoming connection - that way, relayed mail can
be detected, and you can influence your do-I-bounce-this-virus? decision
accordingly as well.

~Tim
--
And it's true we are immune. |piglet@stirfried.vegetable.org.uk
When fact is fiction and |http://spodzone.org.uk/
T.V. is reality, |

> d) It would be nice if there were more of a way to tie in checks that
> "is the bounce likely to go back where it came from?" at SMTP stage;
> we already have the ability to do MX lookups on the
> Sender/Return-Path/mail-from domain, and to connect into those MXes to
> see if they accept mail for the user from <>; it should be possible to
> devise an algorithm where the closeness of IP# for the MX of the
> return-path-to-be-used-in-a-bounce is measured relative to the
> incoming connection - that way, relayed mail can be detected, and you
> can influence your do-I-bounce-this-virus? decision accordingly as
> well.

If it was possible to check this, it truly would be a dream come true; this
would solve much of the spam issue or at least make the sender responsible
for their actions because they couldn't forge the From field.

There were several huge discussions on slashdot about this, which I read in
for ideas. The problem is getting everyone to ADOPT any proposed new
scheme, so the best idea is to stick close to what we already have.

One suggestion that has been well formulated is the RMX resource record in
DNS. A domain owner would list all mail servers authorized to send mail on
behalf of the domain name. Mail servers that support RMX checking would do
a type=RMX lookup on the domain name in the From field, and get back a list
of authorized relay IPs for the domain. Then it's a simple check; is the
connecting mail relay one of these authorized IPs?

It's a nice method because it's purely an extension of what already exists,
using familiar DNS. And it allows hotmail.com and little domains alike the
ability to protect _themselves_ from being used as forged addresses.

Jem Berkes <jb@users.pc9.org> writes:

[snipped, return-path checking on steroids]

> If it was possible to check this, it truly would be a dream come true;
> this would solve much of the spam issue or at least make the sender
> responsible for their actions because they couldn't forge the From field.

Yup.

> There were several huge discussions on slashdot about this, which I read
> in for ideas. The problem is getting everyone to ADOPT any proposed new
> scheme, so the best idea is to stick close to what we already have.
>
> One suggestion that has been well formulated is the RMX resource record
> in DNS. A domain owner would list all mail servers authorized to send
> mail on behalf of the domain name. Mail servers that support RMX checking
> would do a type=RMX lookup on the domain name in the From field, and get
> back a list of authorized relay IPs for the domain. Then it's a simple
> check; is the connecting mail relay one of these authorized IPs?

Does this thing contain netblocks instead of just IP#s, so an ISP's
allocated blocks could be trusted? I mean, I wouldn't want to adopt such a
system if I couldn't say that stirfried.vegetable.org.uk was OK to come
from blueyonder's netblocks in entirity.

(I have absolute control over that domain; I don't know what IP# BY are
going to allocate me over DHCP from their /16 pools tomorrow, but I do want
to be able to send mail direct from the Pigsty if I want, without fear of
it being rejected too often - heck, dialup-RBLs are evil enough.)

Speaking of which: it's entirely possible to abuse this system, isn't it?
You just send your spam in the name of a domain you own, or an equally-evil
friend owns, and they set their permitted netblock to 0/0 in the RMX
records.

> It's a nice method because it's purely an extension of what already
> exists, using familiar DNS. And it allows hotmail.com and little domains
> alike the ability to protect _themselves_ from being used as forged
> addresses.

If you include netblocks, it's going to be open to abuse. If you don't, and
only permit spot IP#s to send mails in the name of a given domain, the
zone-files are going to get *large*, arguably to the extent that it become
inefficient to transfer even 256 IP#s for the size of a small (1-liner)
spam.

~Tim
--
15:34:43 up 83 days, 6:10, 1 user, load average: 0.58, 0.39, 0.26
piglet@stirfried.vegetable.org.uk |Bagpuss gave a big yawn,
http://piglet.is.dreaming.org |and settled down to sleep.

On Thu, 28 Aug 2003 14:20:56 +0000, Jem Berkes wrote:

> One suggestion that has been well formulated is the RMX resource record
> in DNS. A domain owner would list all mail servers authorized to send
> mail on behalf of the domain name. Mail servers that support RMX
> checking would do a type=RMX lookup on the domain name in the From
> field, and get back a list of authorized relay IPs for the domain. Then
> it's a simple check; is the connecting mail relay one of these
> authorized IPs?

That's a great idea. And the really good thing is that it can be
introduced gradually without breaking anything.

Step 1: reject messages if RMX exists and the sender doesn't match.
Step 1b: Insert extra header indicating there was no RMX to make it easy
for spam filters.
Step 2. Bounce and/or require resending to whitelist if there is no RMX
Step 3. Reject if there is no RMX

In step 1 everything will work as it has now. When RMX record have become
more common step 2 will mean the mail still gets there, but cause pressure
on late movers. step 3 is for when close to everyone is using this.

As I said a good idea that can make email useful again.

regards
NPV

On Thu, 28 Aug 2003 15:48:22 +0100, Tim Haynes wrote:

> Jem Berkes <jb@users.pc9.org> writes:
>
> [snipped, return-path checking on steroids]

:)

> Does this thing contain netblocks instead of just IP#s, so an ISP's
> allocated blocks could be trusted? I mean, I wouldn't want to adopt such
> a system if I couldn't say that stirfried.vegetable.org.uk was OK to
> come from blueyonder's netblocks in entirity.

If it doesn't already it should.


> Speaking of which: it's entirely possible to abuse this system, isn't
> it? You just send your spam in the name of a domain you own, or an
> equally-evil friend owns, and they set their permitted netblock to 0/0
> in the RMX records.

It's open to abuse yes, but the job is that much easier for blocking
software. Now all you have to do is check the RMX and then check if the
from address is evildomain.com. Since a domain registration (usually)
takes a little time and money.

Blocking a spammer domain would hurt the spammers a lot more since it
would cost a lot to continually register new domains.

Relay raping would become less attractive too, since you could only fake a
from address belonging to the domain(s) the relay is for, and only that
domain would get hurt by the bounces. Another incentive for the owners to
close their relay. Also the bounces going back to the relays domain
instead of all over the internet will limit the capacity available for
sending out the spam.


regards
NPV

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/TjJ6rynHGRJLYfoRAh1YAJwIa+jaDXexdn28JlIYT6bAXG2TDA CfRHgi
vtQhIsARENVYWXUHSvWk5Jk=
=yTJL
-----END PGP SIGNATURE-----

In article <86fzjmw30s.fsf@potato.vegetable.org.uk>, Tim Haynes wrote:
>
> b) bouncing virus mails is just as stupid as replying to any other kind of
> UBE - it's automation of generating replies (new mails with different
> envelopes), and is similarly moronic.

Since these messages are being detected by a virus scanner, the scanner should
know whether or not the virus forges the envelope sender or not and send
a bounce message or not accordingly. Some virus scanners actually do this.

Brad Olin <bwo@bwo1.com> writes:

> On Thu, 28 Aug 2003 15:48:22 +0100, Tim Haynes
> <usenet-20030828@stirfried.vegetable.org.uk> wrote:
>
>>Speaking of which: it's entirely possible to abuse this system, isn't it?
>>You just send your spam in the name of a domain you own, or an equally-evil
>>friend owns, and they set their permitted netblock to 0/0 in the RMX
>>records.
>>
> My thought is, that if you are going to make a rule then you have to
> stick with the spirit of it. So if they set RMX to 0/0 (or anything
> reserved/invalid) then you don't accept smpt connections from them.
>
> Maybe that is viewed as harsh policy, but... If you don't address the
> issues then you find yourself fixing it over and over again.

No, I entirely agree; there's absolutely no point in coming up with a
half-assed "solution" that even I can see through in under a 5 minutes.

So in addition to RMX, implementations need a method of discerning how wide
the RMX values are and what's permissible. Fair enough.

Now, RFCs, and multiple open-source implementations for my MTA, please? ;8)

~Tim
--
23:14:36 up 83 days, 13:50, 2 users, load average: 0.10, 0.07, 0.04
piglet@stirfried.vegetable.org.uk |Another day,
http://piglet.is.dreaming.org |Another apt-get dist-upgrade