On Wed, 2004-11-03 at 00:12 +0100, Tore Anderson wrote:
> 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.
This is an interesting point. However, I think this fear is a bit
exaggerated - as I am sure real-world impact on your outgoing mail
exchangers is (and will remain) minimal. The key is that greylisting
takes effect only on the first contact between a particular sender and
recipient - most of the time, people on your site will send mail to
people they already have established contacts with. (Typically,
"one-off" mails go to non-personal recipients, not on sites that are
likely to greylist).
> 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!
Is this taxation mainly in terms of spool/storage, delivery
retries/bandwidth, or something else?
> 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"?
What I probably did not write too clearly in the first paragraph is that
the tendency to ignore DSNs is a direct result of collateral spam; by
reducing or eliminating collateral spam, people may pay more attention
to the DSNs they _do_ get.
A 550 SMTP response is a lot better than a bounce message in terms of
generating DSNs only to the legitimate sender of a message. In the case
of legitimate mail, the actual bounce message will be generated by their
own ISP/organization, based on your 550 response. In the case of
virii/ratware, no message is generated.
> > '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..
Yeah. That's a problem, I agree.
Still, IMHO, accidentally rejecting mail from mailing list servers is no
worse than sending a bounce message back to the envelope sender (which,
in the case of Debian's mailing list servers contains a "cookie" that
identifies the recipient). Whether you do bounces or SMTP rejections,
you may need to whitelist such servers to remain on the lists .
OTOH, I get the feeling that you advocate sending suspected spam to the
bit bucket (or a temporary/expiring junk mail store), without doing
_either_ SMTP-time filtering _or_ creating DSNs. That's a different
approach, which - granted - does not generate collateral spam, but can
also make the mail infrastructure unreliable.
-tor
