Ah, I see. Nope, I can't think of any way to (a) allow users to send via their own choice of outgoing relay, (b) without any prior knowledge at the sending end, (c) without sending-side code changes *and* (d) catch backscatter without catching "real" bounces. This ruleset does require knowledge of what outgoing relays are used.
Using SPF or DKIM won't work, because the bounces won't contain enough information for them. BATV is the only option in that case. --j. Jo Rhett writes: > Justin Mason wrote: > > why? Can you not simply list all the outgoing relays for the > > organizations/domains, or even a pattern that matches all of their > > names? How many outgoing relays do you have? (I'm not sure I > > understand the problem here.) > > Okay, let's go with my personal colo box. It's the simplest. I can't > imagine trying this on a production mail server. > > There are 24 domains here. > * 7 are mine or under my control and origin only here. No problem. > * 12 or so I know enough about to make some reasonable guesses. > * 5 domains I know nearly nothing about. > > And seriously, these are all domains of close personal friends. > > AND of those 24 domains, almost *EVERY* one of them has someone in the > domain who is sending mail via their ISP either because they are forced > to, they want to for some misguided reason, or they are just too inept > to change their mail server settings. > > This makes source sending address information difficult to detect using > manually configured host headers. > > I'd rather use SPF and/or DKIM information (or any other information we > can determine dynamically) to determine if the message was originally a > forgery. > > This has the dual added benefit of providing backscatter protection only > for the domains who are protecting others against their forgeries. > > -- > Jo Rhett > Network/Software Engineer > Net Consonance
