Very Computer

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

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
--

When fact is fiction and                    |http://spodzone.org.uk/
T.V. is reality,                            |

Quote:> 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.

[snipped, return-path checking on steroids]

Quote:> 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.

Quote:> 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.  

Quote:> 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

http://piglet.is.dreaming.org     |and settled down to sleep.

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

Quote:>> 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.

That's interesting. Come to think of it, I would have a similar situation
where pc9.org is somewhat dynamic. I don't know exactly how RMX will be
implemented, but maybe it could support CNAMEs ?

Quote:> 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 won't stop people from sending spam from their own domains, but it
will offer domain owners a way to protect their domain names from being
abused. In the context of this thread, domains supporting RMX would not
be the victims of these bounces because a mail server would know that
this email did not actually come from there.

Quote:> 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.

Well there's no reason you can't update your RMX records just as you do
your domain's A. I don't think this is a huge problem...

:)

Quote:> 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.

Quote:> 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

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.

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

http://piglet.is.dreaming.org     |Another apt-get dist-upgrade

Some of them do a nice job of decrypting the header to find the *REAL*
IP address sending the spew. "sanitizer" does a nice job, although I'd
be happy to find one that takes less hand-tuning.

Formail selects the envelope header by default. And if you don't think they
can forge those I have some pacific ocean beach front property in Nevada,
cheap!

Alan C

--

   take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a

Well, yes, but *extremely* few do anything other than forge the "From:"
line.

If that was the case, then wouldn't it be easy to track them down?

Alan C

--

   take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a

It is. But reading the "Received" lines is usually done by hand, since
various SMTP servers and clients have somewhet different but legal
formats for writing them, depending on the host names. Usually yoo have
to read them carefully to get the IP address of the sending machine,
then look up the real admins or upstream feed for that site to send your
protest to the right admins. You can take a very good guess at the
original source by parsing all the Received lines, sorting them by time,
and making sure that line A leads to line B to line C, etc.

Forgers of "Received" lines, who are usually spam authors avoiding
automated filters and not virus authors, seem to find it quite difficult
to do correctly. Usually there are big, odd time gaps, often inverted,
and missing SMTP servers in the chain they list.