On Tue, 2005-11-29 at 12:01 +0000, paddy wrote:
Suppose I am offered mail for usera(_at_)example(_dot_)org and
userb(_at_)example(_dot_)org
Say, for example, usera wishes to receive .exe attachments, but userb
must not. Is there a scheme something along the lines of tempfail
after data, remember the transaction, tempfail the second user
at rcpt time next time around, to cause the mail to split.
(if that works then presumably you could simply always force seperate
delivery to users with different content filtering settings, but that
may be undesirable) Is this what lmtp is intended to address?
And if that is thought to work, can anyone point me at an
implementation?
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.
2. For users with different policies, reject RCPT with a temporary
failure if a sender tries to include a recipient whose policy doesn't
match the policy of previous recipients of the same mail. In this way,
you force the mail to be sent in more than one SMTP transaction, and you
can reject one and accept the other.
3. Since the case where the outcome differs for different users is rare,
a variant on #2. Normally you allow all the RCPTs in one, but you defer
after DATA if you find a mismatch. Then you revert to #2 the next time
you see mail from that sender.
Another thing that bothers me is the more general idea
'bounces/DSNs are broken, don't use them'
(even though at the simplest level this is true)
Surely they are potentially useful, and if they are broken we should
fix them and that is one of the results that schemes like SPF offer?
Or do you believe that the problem is unfixable?
Bounces are fine within reason. For a MSA to generate a bounce to a
'local' user who authenticated himself when submitting the mail is
fine.
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.
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.
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.
This means, amongst other things, that your backup MX should apply the
same content filtering as the primary, and the same recipient filtering.
If your backup MX doesn't know which users are valid on the primary, it
can do SMTP callouts. The times that the backup can't contact the
primary are _rare_; in the majority of cases when spammers just target
the backup because it's considered an easy target, you'll correctly
reject the mail. Just make sure you use the equivalent of Exim's
'defer_ok' option, so that if the primary is _really_ down your backup
does continue to accept mail. Otherwise it's a bit pointless as a backup
MX :)
--
dwmw2
-------
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