Justin Mason wrote:
do you mean the one I posted about earlier, or the original?
Sorry, I haven't looked at it in a while and wouldn't remember.
Looking at yours - why don't use use the global parameters that specify
trusted header hosts instead of adding your own? I can't think of a
time
Jo Rhett writes:
Justin Mason wrote:
do you mean the one I posted about earlier, or the original?
Sorry, I haven't looked at it in a while and wouldn't remember.
Looking at yours - why don't use use the global parameters that specify
trusted header hosts instead of adding your own? I
Justin Mason wrote:
Jo Rhett writes:
Justin Mason wrote:
do you mean the one I posted about earlier, or the original?
Sorry, I haven't looked at it in a while and wouldn't remember.
Looking at yours - why don't use use the global parameters that specify
trusted header hosts instead of
Jo Rhett writes:
Justin Mason wrote:
Jo Rhett writes:
Justin Mason wrote:
do you mean the one I posted about earlier, or the original?
Sorry, I haven't looked at it in a while and wouldn't remember.
Looking at yours - why don't use use the global parameters that specify
trusted
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
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
Justin Mason wrote:
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
