On Wed, Nov 30, 2005 at 12:43:02PM +0000, David Woodhouse wrote:
Implementing different policies for _data_ for different users is hard
because of the way SMTP works. There are many options you can take.
1. Recognise that it's going to be relatively rare that different users
actually receive the same mail _and_ differ in their acceptance, and
just accept that you'll generate a bounce in that rare case.
I would worry that's whats rare by accident might nevertheless be exploitable
3 is the scheme I was trying to decribe. Never having implemented it
or seen it discussed in detail, I wasn't certain that it would work
or what pitfalls it may have. In many ways it reminds me of greylisting.
For a random machine out there on the Internet to generate a bounce to
_me_, merely because it (or its backup MX) didn't bother to check the
contents (or even the recipients) before accepting it from the spambot,
is not fine.
Agreed, seems vast majority of the problem is not that people haven't
implemented spf or ses or whatever, but just the systems sending such
bounces. I don't hold out much hope of taming the internet (even if
I occassionally try ;) but I am trying to make my systems the best I can,
and I'm also looking at SES. non <> bounces seem to be a similar problem,
needing a different solution. Pragmatically I'm drawn to techical solutions
like automated recognition, but idealistically I'd love to think I could
solve the problem by dropping the other party a polite note :)
SPF isn't particularly relevant to this question -- except that it's
just another filtering method which, if you _are_ going to use it to
reject mail (although I think that would be foolish), should be applied
at SMTP time and not used to trigger a bounce later.
Agreed, the bounce later option is just wrong ...
I don't understand why you think using SPF to reject would be foolish.
Isn't that what the sender asked for ? Is there a reason why you
couldn't reject after DATA, but actually quarantine or tag-and-deliver
the mail for the recipient to be able to get to if they need if that's
the worry ?
Shouldn't we distinguish between good bounces and bad bounces,
and explain how to get utility and how to avoid causing nuisance?
The rule is simple -- you reject as early as you can, and during normal
operation you should almost never generate any bounce messages.
Agreed, which is why I'm trying to understand the corner cases, and
how I came to be interested in the whole proxy and filtering during
the session thing.
Just make sure you use the equivalent of Exim's
'defer_ok' option
not familiar with that but I sudenly realise that from what you are saying
that what I said about failover times elsewhere in this thread, is close
to nonsense if you contact the primary to check at something like connect
time. I'd previously thought about using something like heartbeat.
Now to find the sendmail equivalent ...
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com