* Tor Slettnes
> In particular for busy sites (at least those that receive a fair
> amount of spam) greylisting would essentially reduce the demand for
> bandwidth and server resources (e.g. you won't receive the message
> body for most spam; you won't need to run content scanning such as
> SpamAssassin or Brightmail...).
The problem with busy sites and greylisting isn't implementing
greylisting upon reception, but sending to other sites that do use it.
The queue size of the egress MXes will grow painfully large as more and
more sites implement greylisting. Implementing greylisting myself
wouldn't be a problem, the fact that I don't is rather due to altruism.
> I don't think Yahoo! has a deliberate policy of no-retry deliveries
> with greylisting in mind. Their SMTP behaviour dates further back
> than that.
No, I don't think they implemented it because of greylisters, either.
The point I was trying to make was that for sites with an enormous
traffic amount, like Yahoo! Groups, keeping messages around in the
queue for retry attempts is simply too painful to be bearable. If
greylisting becomes ubiquitous, expect other large sites to follow
their example.
None of the sites that I run can compare to Yahoo! in volume, but at
least some should qualify as fairly large (~1.5M deliveries/day). And
I can already tell that greylisting is beginning to tax the egress MXes
in a noticable manner. Not in any way problematic yet, but noticeable.
And for that reason I'm worried where it's going to end - will I have
to follow the example of Yahoo! in two years time? I hope not!
> - In the case of "false positives", the sender address is usually
> legitimate; they will get the DSN via their own service provider.
As I elaborated on in another thread, I don't think this is very
likely to be useful. Quoting from your own page, discussing DSNs:
«This last form is particularly troublesome, because it is harder to
weed out than "standard" spam or malware, and because such messages
can be quite confusing to recipients who do not possess godly skills
in parsing message headers. In the case of virus warnings, this often
causes unnecessary concern on the recipient's end; more generally, a
common tendency will be to ignore all such messages, thereby missing
out on legitimate DSNs.»
I agree very much with this passage. However, near the bottom of the
page, one of advantages of rejecting SMTP-time is:
«You will be able to notify the sender in case of a delivery failure
[..]»
Unless I'm off my rocker and you didn't mean for this to be done by a
DSN generated by the sending MTA who got the 550 from us, I feel those
two passages are glaringly contradictory. How can these notifications
be of any value, at all given that "[the] common tendency [is] to
ignore all such messages"?
> 'course, there is the special case of mail forwarded to you from
> "trusted" sources, such as back MXes, accounts elsewhere, etc. For
> that, you use host-based whitelists.
[...]
> http://tldp.org/HOWTO/Spam-Filtering-for-MX/forwardedmail.html
[...]
> "Closed" relays, such as mailing list servers, *should* be
> whitelisted. This, too, can be supported per-user, without
> restricting each mail to one recipient. See the links above for
> details.
I'm getting the impression that you must be blessed with only
extremely technically savvy users. :-) There is no way in hell that
most normal users will be able to maintain such a whitelist. Not even
everyone of my fellow Debian developers do (cf. another of my emails
in this thread) and they're (supposedly?) a fairly techical bunch..
Kind regards,
--
Tore Anderson
