> -----Original Message-----
> From: Greg A. Woods [mailto:woods@building.weird.com]On Behalf Of Greg
> A. Woods
> Sent: Wednesday, June 29, 2005 4:24 PM
> To: Rick Cooper
> Cc: Exim User's Mailing List
> Subject: RE: [exim] a large number of domains fronted by Exim are
> refusing bounces...
>
>
> [ On Saturday, June 25, 2005 at 08:05:36 (-0500), Rick Cooper wrote: ]
> > Subject: RE: [exim] a large number of domains fronted by Exim
> are refusing bounces...
> >
> > I have several addresses that never, ever, send mail. In fact I
> have an ACL
> > that will catch any attempt for one of these accounts *to* send
> mail. I fail
> > to see how there could be a valid reason for any system to send
> mail to one
> > of these accounts with a null sender.
>
> As Philip said though all mail destined to such addresses probably
> conforms pretty closely to various rules unrelated to the sender address
> and so there's no need to use the sender address when implementing
> policies which control what mail can be accepted to those addresses.
Actually not exactly true. There are several which will recieve mail from
about anywhere. The resulting mail is distributed to several other mailboxes
and those that recieve the mail respond with their own address, and in/out
is tracked for internal purposes (hence the check for outbound mail from
those addresses as that is never supposed to happen). The reject from null
was specifically added because of joe-jobs and virus bounces.
You are correct in the assumption that there are other accounts that don't
send mail and only receive it based on specific origination criteria having
nothing to do with sender.
>
> > And then there are those systems that send "you sent a virus"
> bounces out
> > from a null sender. If a system sends a message from null with
> a subject of
> > "our antivirus... or your mail contained a virus, or virus
> detected,..." why
> > should I accept it?
>
> You shouldn't. However once again that has _nothing_ whatsoever to do
> with whether or not such messages arrive with a null return path.
>
> You shouln't accept such messages no matter what their null return path
> is and thus there's no need to use the sender address when implementing
> policies which reject such messages. These kinds of policy
> implementations are are what I've referred to generically as
> content filters.
The use of null, mailer_daemon, etc in the checks for virus bounces is to
make sure that mails arriving from an individual concerned with someone
sending them a virus are not dropped offhand. We deal with a top three
automobile manufacturer and they *regularly* get infections that can result
in literally thousands of virus laden emails being sent from a single user's
address book... huge distribution lists on a single user's machine(which is
wrong in the first place IMHO). I don't want the bounces from automated
systems of notification to end up cluttering a mailbox just because it came
from null, and I don't want to block emails from a honest to God human,
something I can deal with.
>
> Using the fact that a message arrives with a null return path to
> implement a policy which might result in that message being blocked
> almost certainly means that your other policies and/or their
> implementations are incomplete and insufficient. You should not ever
> have to use the fact that a message has arrived with a null return-path
> to block that message.
>
We are almost in agreement. To block based solely on null is absurd and
irresponsible... I too have encountered servers that do this and it's more
than frustrating. However, there are circumstances where using 'null and
something' is valid. In the world where the original RFCs were born, many of
the everyday garbage that we deal with did not exist and the idea of it
wasn't even considered. If it had been the original specs for SMTP would
have included some form of verifying senders and signing mail that could be
tested from the recipient host. Who would have thought that a method of
sending a virus would be generating a false bounce from a valid domain and
including the payload in that bounce... I doubt that the concept of a
joe-job was even discussed (why on earth would someone do that?).
Up until the last year or so I didn't even reject "you sent us a virus"
bounces, I redirected them to myself and I sent notices to the admin/abuse
mailbox of the domain in question. I cannot think of a single time the admin
took action (based on the logs) so I decided not to bother trying anymore.
You send a bounce to joe@??? and it will come right through, send it
to neversendsmail@??? and it will be rejected at rcpt time. Send a
"you sent a virus" from null (or mailer_daemon, etc) and it will be rejected
at data as I have know way to test the subject or content prior to that
time, I wish I did.
Exim's job is not to force admins to do things the author's way... If I
wanted that I would use a Microsoft product. I wouldn't use a product
produced by an author who is convinced that he has encountered every
situation, every possible need or policy and therefore has the
right/responsibility to force those that use the software to conform to his
ideal. Flexibility is why I use exim in the first place.
Your point is absolutely valid, taken in the context of normal emails,
normal circumstance... in other words in general. It is not, however, valid
in all situations, circumstance and needs.
Rick
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
