On 5/25/11 9:09 AM, Eric J Esslinger wrote:

Mac Mail (and others) have a "feature" that allows my customers to generate a fake NDR message and send it back through my server. I get about a customer every few months that discovers this 'solution' to spam emails, and when it happens they cause delivery problems for my customer mail server by generating backscatter.

Today I just ended up on a list that won't take me off for quite a while (or unless I pay).

Does anyone know of a way for me to block the following, using postfix, either via refusing to accept the mail or by dropping it in /dev/null: Mail from <> or postmaster that originates within our customer IP blocks/is sent using authentication at the submission port and/or that does not have a valid local recipient.

I can't find any ready made recipies online for this sort of thing in a short dig around for it, and while I think it's possible, I was wondering if anyone else was already dealing with this and could say 'oh yeah just put line blah in header_checks'. I would think it would be simple once you find it but you know how it is.

(I've already dealt with the customer in question but I'm getting tired of this popping up every month or three.)

You can check for a combination of two or more of these headers: Auto-Submitted: auto-generated (failure) X-Mailer: Apple Mail (x) Content-Type: multipart/report; boundary=x; report-type=delivery-status ~Seth

-----Original Message----- From: Eric J Esslinger [mailto:eesslinger@fpu-tn.com] Sent: Wednesday, May 25, 2011 11:10 AM To: 'nanog@nanog.org' Subject: blocking annoying 'bounce mail' "feature" from customers use.

Mac Mail (and others) have a "feature" that allows my customers to generate a fake NDR message and send it back through my server. I get about a customer every few months that discovers this 'solution' to spam emails, and when it happens they cause delivery problems for my customer mail server by generating backscatter.

Today I just ended up on a list that won't take me off for quite a while (or unless I pay).

Does anyone know of a way for me to block the following, using postfix, either via refusing to accept the mail or by dropping it in /dev/null: Mail from <> or postmaster that originates within our customer IP blocks/is sent using authentication at the submission port and/or that does not have a valid local recipient.

I can't find any ready made recipies online for this sort of thing in a short dig around for it, and while I think it's possible, I was wondering if anyone else was already dealing with this and could say 'oh yeah just put line blah in header_checks'. I would think it would be simple once you find it but you know how it is.

(I've already dealt with the customer in question but I'm getting tired of this popping up every month or three.) __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165

A couple of people asked me to follow up with a solution if I found one. What I did was perhaps not elegant, but functional. I was hindered by a lack of time and lack of clear understanding of something in the header checks (namely, that the various postfix UCE 'checks' are not stateful and only can do multiple comparisons against a single line at a time. I can't check to: and from: both using header_checks if/endifs. I don't have time to learn how to build a custom milter atm so this will have to do for now, though that would likely be the ideal solution). After some research, some trial and error, and some suggestions, this is what I came up with: For all of the clients that have this capability on the windows side (I don't have direct access to a mac at this time, and apparantly everyone using this is using mailwasher and similar apps) it appears the following line in the body_checks filter catches all of them: /mail.local: unknown name:/ DISCARD I had one other user that I've located that was a problem after that. I fixed his issue by discussion with him and some jusdicious port filtering; His issue was a bit more complex: He is running his own mail server in my static range; He doesn't have a good spam filtering setup, specifically his new spam filter is unaware of actual valid email addresses on his domain, thus accepts a lot of illegitimate email for his domain, which the server then bounces with an invalid recipient. Since he realized he had a problem with getting on bounce lists last month, he decided the solution was a custom delivery filter. Bounce messages from his server are relayed through our public mail server. Since he doesn't see any issues with maintaining this solution on his end, I see no issue with blocking his smtp access to our mail server. BTW: If anyone out there has a mac and wishes to generate a bounce to my address above so I can check my filters against what mac mail generates, I'd appreciate it. I can send an email directly to you for that purpose. (a bounce to fpu-tn.com will get through because it's our corporate mail server and not filtering the same way). Thanks to the list for the assistance rendered. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.