[EMAIL PROTECTED] a écrit :
Matthew.van.Eerde wrote:
At RCPT TO: time, check the pref of the user.
The pref of the FIRST ACCEPTED USER should be used to scan the mail.
The SECOND AND FURTHER legitimate users should be accepted or
tempfailed according to this recipe:
If this user has the same pref as the first accepted user, accept.
If this user has a different pref, tempfail. (Optionally build a
greylist entry.)
After some further thought... what if an email is addressed to 100 Doormat
users and a single Draconian user? A sane email sender will batch the RCPT's
50 at a time... but if the Draconian user is second in each batch (including
retries) it might be an awfully long time before he's accepted...
So lets make the greylist entry mandatory.
After the DATA is received, all users should be in agreement as they
share the same spam preferences.
Also, let's scan the email five times, under all five different prefs, and
remember the results in the greylist as well.
If the message is legitimate, the sender will retry all the
tempfailed RCPT's.
The fact that they retry may be good enough to accept without
spam-scanning at all. Or it might just be worth a few negative spam
points.
On the retry, we already know the spam-score results under all five different
prefs. So we can accept and reject at RCPT TO: time for all the retries, plus
all the new email addresses from the next batch of RCPTs.
Consider:
Email from a MLM vendor [EMAIL PROTECTED]
A particular organization example.org has 100 subscribees to this MLM email:
[EMAIL PROTECTED]
...
[EMAIL PROTECTED]
The MLM vendor batches their RCPTs in 20 per SMTP transaction.
The first attempt to deliver the mail goes like this:
-> HELO mail.example.com
<- OK
-> MAIL FROM: [EMAIL PROTECTED]
<- OK
-> RCPT TO: [EMAIL PROTECTED]
<- OK
-> RCPT TO: [EMAIL PROTECTED]
<- 4xx retry later, different spam pref
-> RCPT TO: [EMAIL PROTECTED]
<- OK
...
-> RCPT TO: [EMAIL PROTECTED]
<- 4xx retry later, different spam pref
-> DATA ...
At this point the data is scanned. let's suppose it is acceptable to all but
Draconian users. user1, user3 and others are not Draconian.
<- OK
Later, the MLM vendor connects again.
-> HELO mail.example.com
<- OK
-> MAIL FROM: [EMAIL PROTECTED]
<- OK
-> RCPT TO: [EMAIL PROTECTED]
<- 5xx user2 has Draconian spam policies and doesn't want that
You can't do that. you don't yet know it is the same message.
-> RCPT TO: [EMAIL PROTECTED]
<- OK user20 has Doormat spam policies and will be happy to accept that
-> RCPT TO: [EMAIL PROTECTED]
<- OK user21 has a medium-level spam pref but I know this email is good under
that
-> RCPT TO: [EMAIL PROTECTED]
<- 5xx user22 has Draconian spam policies and doesn't want that...
...
-> DATA ...
No need to re-spam scan here, just use the known results
unless you use a hash or something like that, you do need to rescan
since you don't know if this is the same message.
<- OK
This assumes that the triplet of (connecting IP, HELO, MAIL FROM) uniquely
identifies spam-classes of email for all users, at least within a greylist
window.
