Re: [Asrg] where the message originated (was: DKIM role?) (SM)
2009-01-21 05:01:15
--On 20 January 2009 18:21:30 +0100 "Peter J. Holzer" <hjp-asrg(_at_)hjp(_dot_)at>
wrote:
On 2009-01-20 11:30:33 +0000, Ian Eiloart wrote:
--On 20 January 2009 08:34:51 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it>
wrote:
> Daniel Feenberg wrote:
>> On Mon, 19 Jan 2009, Paul Russell wrote:
>>> On 1/19/2009 10:38 AM, Ian Eiloart wrote:
>>>> 1. You can bounce selectively.
>>>
>>> I know that sendmail can be configured to accept for one recipient
>>> and reject for another recipient.
>>
>> Sendmail can selectively reject receipients while processing "RCPT
>> TO:" commands, but not after the header and body are received.
>> [...]
>> As I understand it, this is a consequence of the SMTP
>> protocol, and not something that sendmail can program around.
>
> Given a set of recipients (r1, r2, ..., rn) the server can partition it
> in subsets that have homogeneous filtering recipes. It does that in
> steps. Each step consists in responding 250 for r1 and any other
> recipient with identical filtering, 4xx to the rest.
Yes, that's the scheme I was referring to. It can be implemented with my
MTA - Exim. However, if any filter subset doesn't want the message, then
you should give a 5yz response after seeing the body. RFC2821 says that
the sending MTA "SHOULD not again attempt delivery to the same server
without user review and intervention of the message".
<http://www.apps.ietf.org/rfc/rfc2821.html#sec-4.2.5> I guess most MTA's
aren't RFC2821 compliant in that respect.
I'm not sure how you interpret this sentence. Consider:
MAIL FROM:<sender(_at_)example(_dot_)com>
250 ok
RCPT TO:<recipient1(_at_)example(_dot_)net>
250 ok
RCPT TO:<recipient2(_at_)example(_dot_)net>
450 try again later
DATA
354 send message
...
550 message rejected
Should the client assume a permanent failure for both recipients?
Or should it assume a permanent failure only for
<recipient1(_at_)example(_dot_)net> and requeue the message for
<recipient2(_at_)example(_dot_)net>?
Well, to me it means that there's something wrong with recipient1's mailbox
- perhaps currently over quota, but that the DATA isn't acceptable
according to some site policy. I think the RFC's authors probably didn't
have in mind the contortions of the selective filtering mechanism.
Really, autonegotiation of a switch to LMTP would be the solution here. Of
course, spammers wouldn't adopt it. But, if it caught on then eventually
people would start treating smtp clients which refused to switch to LMTP
with suspicion.
RFC 5321 says the client "may either return it to the user or requeue it
for a subsequent attempt". That's an improvement,
Erm, that's for a 4xx reply. I am quite certain that RFC 5321 did not
intend any semantic changes relative to RFC 2821. All changes are only
meant to clarify.
Sorry, you're quite right. I confused two fairly similar paragraphs. Both
drafts say that you MAY retry after a 4xx post-data error, and that you
SHOULD NOT retry after a 5xx error. So, the proposed mechanism shouldn't
work.
However, I'm sure I've heard of sites that actually do implement it, so
perhaps MTAs are mostly requeueing messages after they see the 4xx on RCPT
TO.
there's no guarantee that members of the second and subsequent subsets
will ever see the message. If they do, it will be after a delay that
many people find unacceptable.
If the number of subsets is large enough, you may even exceed the retry
timeout on the sending MTA, so a large site had better not have too many
filter recipes.
Right. That's why I didn't consider looking at "filter recipies", when I
implemented a similar scheme for qpsmtpd. Instead I look at the result.
There are only 2 different results: Accept or reject, so unless the
result changes between delivery attempts (which can happen if e.g., a
blackist is updated or a recipient changes a rule), there are at most
three delivery attempts:
1) The results of the content filters for the different recipients
don't agree. Use the results to split the recipients into two sets.
2) All the recipients from set1 get 2xx reply to RCPT, all the
recipients from set2 get a 4xx reply. Now the results of the content
filters for all recipients agree (they are all from set1), so we can
reply with either 2xx or 5xx.
3) All the remaining recipients are now from set2, so the content
filters agree again, and we can again reply with 2xx or 5xx.
(the actual implementation is a little bit more complicated, but that's
the basic idea).
For most mails, the content filters of all recipients agree on the
result, so the mail can be accepted or rejected at the first delivery
attempt.
It's a really ugly hack, but it works quite nicely.
hp
--
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
|
|