alan wrote:
It probably makes sense to standardize those filtering options that are based
on envelope data. It is easier, because there are not many of those.
not many???
Well, some...
sending ip > countless DNSBL and several DNSWL {user selectable} {most locally
served from mirrors as aggregate zone files ie one lookup serves 32 bit encoded
DNSBL results}
http://www.mxtoolbox.com/blacklists.aspx lists just about one hundred.
However, only a couple of them have widespread significance. And I
know of only one dnswl.org.
then PTR tests {ie does it have ptr}
does it have FQRDNS
These are standard checks.
then enumerating it to a country {for users blocking based on country code}
(nonsensical, IMHO: only reflects whether an operator's customers have
any correspondent in those countries.)
and enumerating to an esp/isp {for users whitelisting/blacklisting by isp
{hotmail/gmail etc}
By mail domain may make more sense than by ISP. But then it is not
clearly stated what should the helo name reflect. That's why SPF has
to wait for the MAIL FROM command.
sending HELO 60ish tests
then mail-from several DNSRL {dns reputation lists like rfc ignorant etc}
then rcpt to {take results of above 32 at a time and logical-and them with
recipients options then reject on any non zero result}
currently most of our filtering options to the user are pre-data
It's still a pretty manageable set, specially if compared to SA rules.
For the content, I'd only bother a few relevant header fields, e.g.
Authentication-Results, X-Spam-Status, X-Spam-Level, SPF-Received, if at all.
It is not practical to require expansive filtering.
the content filtering atm is clamav + spamassasin so we have a per user SA
reject score a
and a binary reject viri and binary reject on {phish/other non-viri clamav
result}
someday we hope to have more on the content filtering, like i'm building dkim
in soon
but soon want to investigate separate classes of SA rulset and depending on
class of adress(s) accepting the email at this pass, run the tweaked SA over
the email
This varies a lot more, among mail sites.
{by class of user i mean currently the first address to accept at RCPT time
decides the class {8 digit binary}
[snip descr of recipient partitioning]
(I think this is standard, although not currently well worded)
Obviously, any mail site may add whatever (optional) filtering rules. The
purpose of _requiring_ some of them is in case a message is forwarded multiple
times. Consider this scenario:
sender-> user(_at_)site -> alias(_at_)intermediate -> other(_at_)final
In such cases, the rules at the final site must not be stricter than those at
the intermediate one.
or more simply what we do is mail to a forwarding recipient, from a forwarders
ip, is just accepted regardless, {so we aren't creating backscatter due to the
forwarders crappy filters}
Yup. However, it would be preferable to check that the forwarder
actually performed the checks that it is supposed to perform, on each
message. You can only double-check those checks that your server is in
turn configured for.
It could be done this way: Alice goes to the "final" webmail site; it
downloads an html form from the "intermediate" site; the latter, in
turn downloads a form from the "site". Although Alice is working on
the "final" webmail page, she uses that composite form for configuring
her "user(_at_)site" upstream address. Alice sets any available option and
submits the form to "final". The "final" site looks at the options it
understands and saves them for double-checks, then submits the form to
"intermediate". The "intermediate" site does the same, so the form is
eventually submitted to "site".
When a message is forwarded, both "intermediate" and "final" can
double-check some of the options. Is that too cumbersome?
{it is not our job to save them from spam that their other receiver didn't
block! as if we do there is no pressure on the forwarder to institute decent
anti-spam solutions}
Agreed, but we only marginally trust the other receivers.
Double-checks allow to verify their work.
{its an idealogical thing ie filtering should all be at the point of initial
reception, as once past this point the spammer has been paid and any further
rejection will only result in
A DSN's bothering the forged-from
B DSN repression causing the non-forged-from {but sending suspicious mail} not
being notified that the user didn't get it
Agreed.
both are worse than user getting the spam {suitably marked as such} in my book
I think we should all try to ensure DSN's are only normally generated by
originating-senders where possible {to force them like us to police their
outflow and ensure their users cannot generate forgeries}
Policing issues may be better handled via abuse reports, when it will
be clear where they should be addressed.
in our case every authenticated submission can only send envelope-from that
users list of verified from address's, and mail servers can only send
envelope-from their list of allowed domains {or from-any to their list of
outbound-forwarding destinations}
Fine. However, if the "cumbersome" behavior described above has been
agreed between a forwarder and its target, there may be better options
than checking the envelope-from.
so if a user here generates spam {uce or ube} it is entirely traceable and the
NDR's are local and logged by us for monitoring so we can TOS them
Abuse reports would also allow to trace whether the upstream
transmitter blocks its spammy users after spam has been notified.
Thus, there should be no need to fine-tune downstream sites. It would then be
sufficient to configure whitelistings at one site only, as standardized
settings can easily be exchanged between compliant sites, if the given
standardization provides a way for doing that.
not really a good idea in my experience most users with more than one address
want wildly different filtering on each
so it would be bad to assume a forwarded address would want the same filtering
as a receiving address
{as for example some of our users have the forwarders receiving all kinds of
crap but have the end receivers {usually dedicated address' for forward
reception} simply setup to deny 0.0.0.0/0 except forwarders-ip's
this obviously wouldn't want to be auto-propagated
Yes, we are saying the same thing. I just wrote it loosely: when I wrote
Thus, there should be no need to fine-tune downstream sites.
I meant
Thus, there should be no need to fine-tune downstream sites as far as the
forwarded stuff is concerned.
Alice would configure her "other(_at_)final" options using a different
form, still at the "final" webmail site.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/
[http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com