Mailing List Archive

Ok, so what would the policy of the sorting interface be?

The "spam script" could be something different from the general
sort-my-mailinglists-etc script, and be partly hardcoded with spam in mind.

Any script with "spam" and "reject" within 50 characters of one another could
be considered invalid.

Any user found to be unaware of good spam management policies could be
prevented from uploading Sieve scripts and thus forced to use the default.

Aaron


Bill Hacker <wbh@conducive.org> said:

> Aaron Stone wrote:
>
> > It's something that end users, who are writing their Sieve scripts or
> > using interactive web happy Sieve editors, should take into account! It's
> > not something that I would want to ban programmatically, however, because
> > of the messy compexities and general klugey borkage it would involve.
> >
> > Aaron
> >
>
> ?? If you mean you would write an MTA that would *readily permit*
> bouncing spam, then you should expect to be branded irresponsible.
>
> This has a long history of causing serious grief - to the extent of
> getting otherwise-good-guys blacklisted...
>
> - I hope I misunderstood your stance. Or that you will research the
> issue, and - hopefully, modify it.
>
> ....Else you may be in an IP battle with Micros**t, who own most of the
> rights to software irresponsibility and abdication.. <G>
>
> Bill
>
> >
> > Bill Hacker <wbh@conducive.org> said:
> >
> >
> >>Christian G. Warden wrote:
> >>
> >>
> >>>On Tue, Nov 25, 2003 at 04:57:59PM -0000, Aaron Stone wrote:
> >>>
> >>>
> >>>>I believe that the best way to handle spam is by using an MTA based spam
> >>>>checker which adds identifying headers, prefixes the subject line, or
> >>>>otherwise marks the incoming email without disrupting the MTA path towards
> >>>>DBMail delivery.
> >>>>
> >>>>At delivery time, use a Sieve script to put all of the spam into a
folder, or
> >>>>discard it, or keep it in INBOX, or bounce it back, or call you pager, etc.
> >>>
> >>>
> >>>You should *not* bounce spam as the sender is always forged (or often
> >>>enough that it's safe to say always). Either keep it, discard it, or
> >>>reject it at SMTP time.
> >>>
> >>>xn
> >>>_______________________________________________
> >>>Dbmail-dev mailing list
> >>>Dbmail-dev@dbmail.org
> >>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>
> >>>
> >>
> >>Second the 'not bounce' as too often the spam-bastards even have clever
> >>forgeryways to utilize a mis-directed 'bounce' to propagate their garbage...
> >>
> >>Bill Hacker
> >>
> >>_______________________________________________
> >>Dbmail-dev mailing list
> >>Dbmail-dev@dbmail.org
> >>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>
> >
> >
> >
> >
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--

Hi Feargal -

> Christian Warden suggested using the -m flag of dbmail-smtp
> to deliver it to a seperate mailbox. I wasn't actually aware
> of that option as it's not mentioned in the man page, and it
> does the job pretty well (although it'll hurt my head to
> figure out the sendmail config...).

Re: your sendmail hassles, we use a small perl wrapper script (albeit crude)
which pipes the message through to the dbmail-smtp program and calls
dbmail-smtp with appopriate args.

Sendmail -> wrapper -> dbmail-smtp (flags)

The wrapper basically reads in stdin in, caching the header parts (look for
the first blank line), and then if that has X-Contains-Spam, etc -- changes
$mailbox from "inbox" to "spam"... Then opens "dbmail-smtp -m $mailbox" as a
pipe, outputs the cached headers and then streams <stdin> from then on to
the pipe. Thus only the headers are cached and you move your 'filtering'
intelligence to this wrapper program rather than sendmail/dbmail. The perl
interpreter overhead is there, which isn't great, and you need to make sure
you return the exit codes to sendmail if dbmail-smtp barfs, etc. As a plus
though, because it's perl - you can pretty much do anything you want in
terms of filtering capabilities...

/Mark

Aaron Stone wrote:

> Ok, so what would the policy of the sorting interface be?
>
> The "spam script" could be something different from the general
> sort-my-mailinglists-etc script, and be partly hardcoded with spam in mind.
>
> Any script with "spam" and "reject" within 50 characters of one another could
> be considered invalid.
>
> Any user found to be unaware of good spam management policies could be
> prevented from uploading Sieve scripts and thus forced to use the default.
>
> Aaron
>
*SNIP*

This might not be possible, but a pie-in-the-sky goal....


- Regardless of the location, 'quality', point-of-introduction/action of
the inline, batched, <whatever> spam filtering (be it seive or something
else)....

- It would seem to me to be desirable that the "system" be aware that
the source of the 'attempted bounce' is a spam-detection process, hence
by (developer's recommended, hence default) policy, is *not permitted*
to send a 'bounce' (as these are too often from forged addresses, result
in 'bunce wars', ricochet to other servers, etc.)

IOW - perhaps 'bounces' can only be permitted to originate *within* the
SMTPD, *before* spam detection occurs.

Come to think of it.... if one does a 'reject' on invalid users, would
that leave a 'mailbox full' the only commonly valid reason to do a 'bounce'?

We could drop *seriously* malformed messages on the floor... handling
the merely stupidly malformed OE ones is a road well-traveled already..


(You see why I want to control the SMTPD as well as the rest of the animal)

Bill Hacker

And - BTW, SMTPD's can be had that are quite small...

On Tue, Nov 25, 2003 at 05:36:47PM -0000, Aaron Stone wrote:
> It's something that end users, who are writing their Sieve scripts or using
> interactive web happy Sieve editors, should take into account! It's not
> something that I would want to ban programmatically, however, because of the
> messy compexities and general klugey borkage it would involve.

I wasn't saying that tools like Sieve should prevent bouncing spam, but
that administrators should prevent (or at least make it difficult) users
from configuring their sorting rules to bounce spam.

> Aaron
>
>
> Bill Hacker <wbh@conducive.org> said:
>
> > Christian G. Warden wrote:
> >
> > > On Tue, Nov 25, 2003 at 04:57:59PM -0000, Aaron Stone wrote:
> > >
> > >>I believe that the best way to handle spam is by using an MTA based spam
> > >>checker which adds identifying headers, prefixes the subject line, or
> > >>otherwise marks the incoming email without disrupting the MTA path towards
> > >>DBMail delivery.
> > >>
> > >>At delivery time, use a Sieve script to put all of the spam into a folder, or
> > >>discard it, or keep it in INBOX, or bounce it back, or call you pager, etc.
> > >
> > >
> > > You should *not* bounce spam as the sender is always forged (or often
> > > enough that it's safe to say always). Either keep it, discard it, or
> > > reject it at SMTP time.
> > >
> > > xn
> > > _______________________________________________
> > > Dbmail-dev mailing list
> > > Dbmail-dev@dbmail.org
> > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > >
> > >
> > Second the 'not bounce' as too often the spam-bastards even have clever
> > forgeryways to utilize a mis-directed 'bounce' to propagate their garbage...
> >
> > Bill Hacker

Christian G. Warden wrote:

> On Tue, Nov 25, 2003 at 05:36:47PM -0000, Aaron Stone wrote:
>
>>It's something that end users, who are writing their Sieve scripts or using
>>interactive web happy Sieve editors, should take into account! It's not
>>something that I would want to ban programmatically, however, because of the
>>messy compexities and general klugey borkage it would involve.
>
>
> I wasn't saying that tools like Sieve should prevent bouncing spam, but
> that administrators should prevent (or at least make it difficult) users
> from configuring their sorting rules to bounce spam.
>
>
>>Aaron
>>

Understood. But I think that is the larger task, given that it has to be
constantly applied over a finite, but open-ended time span - and one
filled (Lybarger's Corrolary to Sod's Law [1]) with a finie, but
seemingly endless supply of sloppy, or just plain *tired* 'lusers'.

A restrictive (DB 'rules' driven?) SMTPD, OTOH, has to be written and
tested just *once*.


[1] Lybarger simplified Sods' Law (Murphy's Law to you Yanks <G>) to:

"All else being equal, *you lose*!"

Bill

Christian G. Warden wrote:

> The destination mailbox doesn't have to be hard-coded into the MTA. For
> example, I configured a transport (Exim) that takes addresses of the
> form /username~mailbox/ and delivers them to the correct mailbox using
> dbmail-smtp. The mailbox to deliver to is the result of a
> user-configurable filter which is stored in the users table in the
> database.

It is not always easy to retrieve such delivery-oriented configuration
data at transport time. As an example:
You can use DBMail to easily build mail-reflectors. You can insert
multiple rows into the table 'aliases' with the same 'alias' but
different destinations to 'deliver_to'. DBMail will duplicate a mail to
such an alias and deliver it to all destinations/users.
These users can have different settings (should headers be added, should
headers or body be modified, in which folder should 'spam suspects' be
delivered, ...). Which of these users' settings should be applied at
transport time? At this point of time it is still only one message.
The duplication process later on is completely unknown to the MTA.

>>Finally, as I mentioned, I have no experience with IMAP, so should a
>>spam mailbox be called 'Spam', '/Spam', or something else?
> 'Spam' is fine, or 'Quarantine/Spam' or similar.

Maybe it should be user-configurable?

Best regards,
Michael

P.S.:
Sorry to the list-admin for previously sending two (now obsolete) mails
with the wrong from-address.

On Wed, Nov 26, 2003 at 06:06:19AM +0100, Michael Häusler wrote:
> Christian G. Warden wrote:
>
> > The destination mailbox doesn't have to be hard-coded into the MTA. For
> > example, I configured a transport (Exim) that takes addresses of the
> > form /username~mailbox/ and delivers them to the correct mailbox using
> > dbmail-smtp. The mailbox to deliver to is the result of a
> > user-configurable filter which is stored in the users table in the
> > database.
>
> It is not always easy to retrieve such delivery-oriented configuration
> data at transport time. As an example:
> You can use DBMail to easily build mail-reflectors. You can insert
> multiple rows into the table 'aliases' with the same 'alias' but
> different destinations to 'deliver_to'. DBMail will duplicate a mail to
> such an alias and deliver it to all destinations/users.
> These users can have different settings (should headers be added, should
> headers or body be modified, in which folder should 'spam suspects' be
> delivered, ...). Which of these users' settings should be applied at
> transport time? At this point of time it is still only one message.
> The duplication process later on is completely unknown to the MTA.

I do alias expansion in my MTA too, so I only do two types of
deliveries, to a specific mailbox using -u <user> -m <mailbox> and to a
specific user without alias expansion using -u <user>. (The latter is
equivalent to -u <user> -m INBOX)

xn

On Tue, 25 Nov 2003 09:25:44 -0800, Christian G. Warden wrote:

> On Tue, Nov 25, 2003 at 04:57:59PM -0000, Aaron Stone wrote:
>> I believe that the best way to handle spam is by using an MTA based spam
>> checker which adds identifying headers, prefixes the subject line, or
>> otherwise marks the incoming email without disrupting the MTA path towards
>> DBMail delivery.
>>
>> At delivery time, use a Sieve script to put all of the spam into a folder, or
>> discard it, or keep it in INBOX, or bounce it back, or call you pager, etc.
>
> You should *not* bounce spam as the sender is always forged (or often
> enough that it's safe to say always). Either keep it, discard it, or
> reject it at SMTP time.
>


If you are going to reject a message, then by RFC you should bounce it.

Yes, most of the time the sender is forged, but it's that 1% of the time
where the sender MUST be informed that their message did not reach the
intended destination. Otherwise, you have not had a full accounting of the
delivery.

If you have sent someone's $10K contract into the bit bucket without letting
the sender know, you will have a pretty p*d-off customer.




Brian

Brian Blood wrote:

> On Tue, 25 Nov 2003 09:25:44 -0800, Christian G. Warden wrote:
>
>
>>On Tue, Nov 25, 2003 at 04:57:59PM -0000, Aaron Stone wrote:
>>
>>>I believe that the best way to handle spam is by using an MTA based spam
>>>checker which adds identifying headers, prefixes the subject line, or
>>>otherwise marks the incoming email without disrupting the MTA path towards
>>>DBMail delivery.
>>>
>>>At delivery time, use a Sieve script to put all of the spam into a folder, or
>>>discard it, or keep it in INBOX, or bounce it back, or call you pager, etc.
>>
>>You should *not* bounce spam as the sender is always forged (or often
>>enough that it's safe to say always). Either keep it, discard it, or
>>reject it at SMTP time.
>>
>
>
>
> If you are going to reject a message, then by RFC you should bounce it.
>

Unfortunately, the RFC is obsolete w/r the real world.


> Yes, most of the time the sender is forged, but it's that 1% of the time
> where the sender MUST be informed that their message did not reach the
> intended destination. Otherwise, you have not had a full accounting of the
> delivery.

You will not get that - or much of anything else - if your bounce to a
forged address gets you into a 'bounce war' with the ISP who was the
victim of the forgery.

Worse - there are , and have been for sometime, script-kiddies and
MS-Weenies offering advice/products to send fake bounces, and do so from
the MUA.

This is one fire to NOT pour gasoline onto - RFC or not.

>
> If you have sent someone's $10K contract into the bit bucket without letting
> the sender know, you will have a pretty p*d-off customer.
>
>
>
>
> Brian
>
If a $10K contract was sent solely by email, was not already traveling
along a previously proven route (prior messages were exchanged
successfully between the parties), did not request or
receive-if-requested a delivery confirmation, or make a follow-up phone
call or contact, then you have a pretty careless customer.

And your Terms of Service should *always* remind folks that
internet-base email is a "best efforts" animal.

Bill Hacker