> -----Original Message----- > From: Greg A. Woods [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] and it will come right through, send it to [EMAIL PROTECTED] 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. -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
