Re: [exim] Looking to Create and Addtional Header Record to …

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: W B Hacker
Ημερομηνία:  
Προς: exim users
Αντικείμενο: Re: [exim] Looking to Create and Addtional Header Record to Solve AOL Redaction Problems
Lloyd Tennison wrote:
> AOL will allow the information in a footer, but that makes for much more
> overhead (and hard to do in Mailman if you have HTML messages.)


Different, yes. But not really 'harder'

> The
> information is still available from AOL, they just made it harder to get.
> Here is AOL's postmaster blog link on the issue.
>
> http://journals.aol.com/pmtjournal/blog/entries/2008/08/13/more-on-the-upcoming-feedback-loop-conversion/3001.
>
> Since people report even individual emails sent only to them as SPAM -
> accidentally or on purpose, doing it in the MTA is much more effective.
>


More universal, perhaps, yes.

> Every list gets SPAM complaints, well-run or not.


Not so far here (knock wood). But we run exclusively 'closed' lists, so....

> Ask the moderators here or
> any other list. People are both lazy and can hit the SPAM button as it is
> next to the Delete button accidentally. (Incidentally, if my lists were
> not well-run, AOL would not still have me whitelisted. That is not an easy
> task to be whitelisted and have it for several years.)
>
> I use Mailman - just like this list. It does not have a fingerprinting
> capability, that is why I asked here for help.
> Trying to add it will create
> quite a bit of overhead, and then would not be able to check the origin of
> non-mailing list messages.


> Doing it in Exim would make life easier and
> then would cover all emails sent from the server.
>


So long as the message id is all that is furnished, and so long as it is
common to all recipients of a particular 'post' that the MLM broadcasts,
I don't see that as consistently 'good enough' on its own to ID the
specific list member who threw the flag.

IF, as we do, one does NOT 'batch' to f'rinstance AOL, then timestamps
can help separate which of 'many' AOL users on your list are involved.
(they would be separate deliveries for our configs).


> BTW - you can only get an individual id in the maillog - as it is created by
> Exim. MLM logs never have that


Ecartis logs the same ones Exim has.

[10/03/2008-18:49:58] [16967] Response: 250 OK id=1Klnqo-0004Ph-E5


- just as you sending an email from your
> own personal computer to more than one person does not have the individual
> queue id. The message id you have, but that would be the same for all
> people on your distribution, just like it is for all emails on a mailing
> list.
>
> Example the ID you machine used when sending the reply was
>
> Message-ID: <48E842B1.2020103@???>
>
> That id would be the same for every person who received this email on the
> list.
>


ACK. But that one is created by the composing MUA - not by Exim.

That said, Exim CAN add a 'more unique' code to every message transited.

The need is not all that different from others - such as bounce-abuse
prevention - so there are plenty of examples here.

> The id from exim.org is:
>
> (envelope-from <exim-users-bounces@???>)
>     id 1KmLFc-0000JE-OQ;

>
> That id is only for me.
>
> Here is comment from the creator/programmer of Mailman, Brad Knowles :
>
> "Personally, I'm about ready to get together with a few other people and
> rewrite the RFC describing the ARF format, and update it such that you
> cannot possibly be compliant with the 2.0 format if you redact any
> information whatsoever. Then the entire Internet can beat the holy living
> crap out of them for not being 2.0 format compliant.
>
> And I say this as the former Sr. Internet Administrator for AOL.
>


*sigh* RFC's are already diverging from 'real world' enough as it is...

And 'real world' means we must satisfy:

- Governments and their laws and rules.

- Carriers and coloc providers who run the facilities and can cut off
bandwidth or UPS power.

- Paying customers.

... before we worry overly much about the subtle nuances of RFC's that
are always out of date by 'Time Y' where 'Y' is the delay in years
required for publication, discussion, compromise, [loop while NOT].
eventual acceptance. Not to mention actual in-the-field adoption.

Typically 2 to 15 years.

IOW, not all that responsive to threats, so we honor the first three...

Have to.

Bill