Re: [exim] More embedded Perl functionality

* Tor Slettnes

> 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).

But when you got thousands of accounts, and lose/get hundreds of users
every day, you'll never reach a point where you're "finished"
introducing yourself to greylisting sites.

* Tore Anderson

> 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.

* Tor Slettnes

> Is this taxation mainly in terms of spool/storage, delivery
> retries/bandwidth, or something else?

Well, the average time spent on queue per message on the egress MXes
increases. Because of that, queues get larger, which in turn leads to
degraded performance all-over, as Exim's not designed to work with
large queues, as Philip himself admits to in the Book.

For me this is not a problem today. I've just tried to imagine what
the world will look like in a few years if the adoption rate will be
going up rapidly, and I don't like the answer I get. Which is why I'm
not at all enthusiastic about it. Of course, the scenario John W.
Baxter is depicting isn't unlikely either: When greylisting is more
widely adopted, the technology dies - the spammers will have enough
incentive to bypass it (by doing each run twice, for instance).

> 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 noble cause indeed, but I fear that war is lost. :-( I don't think
DSNs as we know them will ever be useful again.

> 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.

But usually just as (read: much too) cryptic for normal users to
comprehend as any other DSN generated somewhere else.

> 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.

I'm not really advocating anything else than to endeavour to minimize
the burden placed on others when attempting to relieve oneself of the
pain of junkmail. In my humble opinion, SMTP-time rejections and
greylisting both fall short of the mark by impacting users or
postmasters around the globe negatively. On the other hand, though,
they're by far not the worst things around.. C-R systems, for
instance, are in a different leauge entirely.

You're right, too, I do /dev/null the most egregious (according to SA)
junk messages plus ClamAV-detected viruses, and filter the rest into a
spambox which I review once in a while. Works for me, but I'm not
going to tell you that it will for you. But I do not think it's any
worse in terms of degrading the email infrastructure than the 550 after
DATA-approach; both will, if the automated systems have misclassified
a solicited email, lead to the loss of said email.

Kind regards,
--
Tore Anderson