At 09:30 29/11/2009 Sunday, Alessandro Vesely wrote:
alan wrote:
I agree with Ian that it would be nice to have something like this as a
standard. That might provide for the sender setting up any relevant detail,
and (non-geek) users just having to agree, either manually or automatically.
However, the obvious advantage of your approach is that it requires minimal
or no compliance from senders.
as far as standards yup hopefully in the end {whenever that is} the websites
api will be documented well enough and structured in a way
that 3rd party plugins could talk direct to it so all the user has to give
the plugin is the base url of the admin site and their admin id/password
and then thus plugin could present whatever options it wished from the mail
client
{and similarly webmail clients could be tweaked to present their own api to
the filtering}
but currently even the filtering site api dosn't present all available
options to the user, many still require calling me and having me alter their
preferences
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???
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}
then PTR tests {ie does it have ptr}
does it have FQRDNS
then enumerating it to a country {for users blocking based on country code}
and enumerating to an esp/isp {for users whitelisting/blacklisting by isp
{hotmail/gmail etc}
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
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
{by class of user i mean currently the first address to accept at RCPT time
decides the class {8 digit binary}
any further recipients rejecting on envelope details rejects as usual
any further recipients not-rejecting on envelope and being in the same
content-class accept the mail {thus far}
any further recipients not-rejecting on envelope but in a different
content-class defer the mail
thus mail to 6 users in six different content classes {with say only one
rejecting on envelope}
will try 5 times and each will get 1 user
but a mail to 6 users in two content classes {with say the same one rejecting
on envelope}
will try twice to get to all
{as most users fall into the default content class of reject on all clamav hits
reject on SA score 10+
11101010
postmaster and abuse though are
10000000
ie reject only viri
viri phish use-SA {SA-Score}
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}
{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}
{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
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}
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}
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
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
One added benefit is that users have a means to maintain a list of their
whitelistings, subscriptions, etcetera.
In the above scenario, subscriptions might be retrieved recursively and result
in a single web page.
-------------------------------------------
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
-------------------------------------------
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