David Woodhouse writes:
Implementing different policies for _data_ for different users is hard
because of the way SMTP works. There are many options you can take.
1. Recognise that it's going to be relatively rare that different users
actually receive the same mail _and_ differ in their acceptance, and
just accept that you'll generate a bounce in that rare case.
This is NOT rare, at least not here, and I don't think my service is
unusual in this respect.
What I used to do to address this was limit the number of recipients
per envelope to one at my border MTAs. Each message can then be
processed according to the acceptance criteria if its one recipient.
(After discovering that some spammers detected this and did RSET after
RSET, apparently automated, to generate separate envelopes, I added
limiting the number of envelopes per SMTP connection to one. This is
RFC-dubious if not outright RFC-disallowed, but it's very effective.)
For a random machine out there on the Internet to generate a bounce to
_me_, merely because it (or its backup MX) didn't bother to check the
contents (or even the recipients) before accepting it from the spambot,
is not fine.
If you don't like bogus bounces, implement SRS or SES for all your
outgoing mail. That way you'll know which bounces are of mail you
actually sent and which are fake after RCPT.
(Mark [the asarian-host Mark] has a web page on how to do this with
sendmail. His scheme needs some tweaks for multiple-MTA sites, but
any decent sendmail admin should be able to adapt his scheme to local
needs.)
This means, amongst other things, that your backup MX should apply the
same content filtering as the primary, and the same recipient filtering.
If your backup MX doesn't know which users are valid on the primary, it
can do SMTP callouts. The times that the backup can't contact the
primary are _rare_; in the majority of cases when spammers just target
the backup because it's considered an easy target, you'll correctly
reject the mail. Just make sure you use the equivalent of Exim's
'defer_ok' option, so that if the primary is _really_ down your backup
does continue to accept mail. Otherwise it's a bit pointless as a backup
MX :)
For a mail system handling any volume, MXs aren't just for "backup",
they are basically for load balancing.
Once you decide to reject at SMTP whenever possible, you have to do AV
scanning, anti-spam scanning, and all other acceptance processing on
the fly. This quickly means a single-server setup is overwhelmed for
even a small multi-domain mail service. That means you need a set of
border-MTA MXs dedicated to just receiving and judging mail, which in
turn means you have the problem of keeping them all in sync with
respect to all acceptance criteria.
The problem isn't just the average size of the load, it's the load
distribution. If you see an average of, say, 10 SMTP connections per
second, you will have some seconds with zero connections and some with
100+ connections. To reject at SMTP, you need enough total capacity
to process those 100+ connections in one second. However, if you
accept all mail and process it in batches, you only need enough
resources to process your average 10 connections' worth of mail in one
second.
In other words, for a high-volume mail service to reject at SMTP, it
must both devote many times the resources to receiving mail and take
on all the problems of keeping all the resources in sync under dynamic
conditions.
Batch processing is so much easier and cheaper that I think large mail
services are going to do it, no matter how much people wail about it.
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com