A request to all mail admins

A request to all mail admins

Post by Jem Berke » Fri, 29 Aug 2003 14:38:19



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.

 
 
 

A request to all mail admins

Post by Tim Hayne » Fri, 29 Aug 2003 18:21:55



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

 
 
 

A request to all mail admins

Post by Jem Berke » Fri, 29 Aug 2003 23:20:56


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.

 
 
 

A request to all mail admins

Post by Tim Hayne » Fri, 29 Aug 2003 23:48:22


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

 
 
 

A request to all mail admins

Post by Nils Petter Vaskin » Sat, 30 Aug 2003 00:09:19



> 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

 
 
 

A request to all mail admins

Post by Jem Berke » Sat, 30 Aug 2003 00:41:51


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

A request to all mail admins

Post by Nils Petter Vaskin » Sat, 30 Aug 2003 00:47:06




> [snipped, return-path checking on steroids]

:)

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

 
 
 

A request to all mail admins

Post by Bruno Wolff II » Sat, 30 Aug 2003 02:24:43



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

A request to all mail admins

Post by Tim Hayne » Sat, 30 Aug 2003 07:16:12



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

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

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

 
 
 

A request to all mail admins

Post by Nico Kadel-Garci » Sat, 30 Aug 2003 09:41:19



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

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.
 
 
 

A request to all mail admins

Post by Alan Conno » Sat, 30 Aug 2003 10:04:00




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

> 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

 
 
 

A request to all mail admins

Post by Nico Kadel-Garci » Sat, 30 Aug 2003 11:39:46





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

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

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

A request to all mail admins

Post by Alan Conno » Sat, 30 Aug 2003 12:53:10






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

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

> 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

 
 
 

A request to all mail admins

Post by Nico Kadel-Garci » Sat, 30 Aug 2003 21:01:53



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

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.

 
 
 

1. admin user can't admin non-admin groups

In the attributes for user profile "jean" I've specified "adminstrative
user=true" and "administrative group=staff".

In the "staff" group profile attributes I've specified "administrative
group=false" and "administrator list=jean".

The above were done as by "root".

When I then sign in as "jean" and look at the "staff" group attributes
(via SMIT) it shows "adminstrative group=true" and the "administrator
list=" parameter is blank.  If I try to make an addition, say, to
the "user list=" parameter and hit OK, SMIT dies and the change doesn't
get made.  Further, if I go into Application Manager as "jean" and try
to edit "staff" group I am told "you do not have access to edit this
dialoge."

Have I got a bug or am I doing something wrong in the way I set
up "jean" and "staff"?

Thanks.

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

2. A chroot environment link to the root filesystem

3. AIX Sys Admin Exam - Request for Study Info

4. Can linux be installed on a system with only a secondary ide controller running the drives?

5. Request for more Unix Admin Horror Stories

6. 8361-110

7. Request for Info 'bout Student Sys Admins

8. FTP site for Solaris binaries

9. SendMail admins - survey request

10. request recommendation on admin tool a la rdist

11. Admin Request Tracking

12. UNIX admin/user book request

13. How do I delete mail from mail file /var/mail/su after reading mails