Re: PMDF Inner header rewriting and PMAS rules - VMS

This is a discussion on Re: PMDF Inner header rewriting and PMAS rules - VMS ; > Unfortunately it seems practically all the anti-spam products try to use > X-MAILER headings and other header information to detect when mail is claiming > to be from one client but isn't really. Apparently quite a lot of spam ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: PMDF Inner header rewriting and PMAS rules

  1. Re: PMDF Inner header rewriting and PMAS rules

    > Unfortunately it seems practically all the anti-spam products try to use
    > X-MAILER headings and other header information to detect when mail is claiming
    > to be from one client but isn't really. Apparently quite a lot of spam
    > generating programs claim to be particular mailers but often get it wrong in
    > the details.


    And there's nothing wrong with it as long as the tests you perform aren't
    against something that's likely to be modified during normal message
    processing.

    > > > Since anti-spam software is now performing these checks of the formats of
    > > > Mime header lines is it a good idea to stop doing inner header rewriting ?


    > > That depends on whether or not the rewriting is doing anything else for
    > > you. However, do not for a minute expect that disabling this will solve
    > > the problem. It won't, for the simple reason that there are all sorts
    > > of other ways that MIME scanning can be triggered, some of them
    > > unavoidable.


    > Are you saying that even if I removed inner header rewriting the Mime header
    > might still in some circumstances be altered by PMDF so that it wasn't in the
    > "matching" format for the X-MAILER line ?


    That's exactly what I am saying. And PMDF is far from the only agent that does
    this sort of thing. This is hardly surprising given that this sort of
    alteration is required by various standards (e.g., MIME downgrading, negotiated
    content downgrading, etc.).

    > > If this is a serious problem I'd recommend (a) Disabling the rule locally (b)
    > > Complaining to the SA folks that this is broken, and maybe (c) Stripping
    > > X-Mailer fields unconditionally.


    > I've never been sure with PMDF what headers I can and cannot strip
    > unconditionally using headertrim.


    It's quite simple: There's a list. If your header is on it you can trip it
    without affecting other fields, if not you cannot. Items are added to the
    list from time to time as needs and tastes change. I'm sure that by now
    the lists in iMS and PMDF have diverged.

    The simplest way to see the list is to run PMDF MAIL, enter "set
    header_trimming " and hit question mark to see the available options.

    > The manual seems to suggest you can only strip headers which are standardised
    > in the RFCs otherwise you have to use the special header line name Other:.


    Not sure where you got that idea. It has never been true.

    > I wouldn't have thought X-MAILER was a standardised header (but I maybe wrong).
    > Hence I'd presumably need to use the Other: syntax but I'm not sure how to
    > do that - an example would be very useful.


    The trimming file

    x-mailer: maximum=-1

    should do the trick.

    > Stripping the X-MAILER heading on mail I emit would seem to be a sensible
    > work-around to this problem unless you or anyone else (Hunter ?) could see
    > other problems that this would cause.


    I for one never use X-mailer: in the mail I send; not using it has never caused
    me any trouble. It is precisely because of dain-bramaged checks like this that
    I don't use it.

    Ned

  2. Re: PMDF Inner header rewriting and PMAS rules

    In article <01LO7NL5MJFW00004T@mauve.mrochek.com>, ned+info-pmdf@mauve.mrochek.com writes:
    >> Unfortunately it seems practically all the anti-spam products try to use
    >> I've never been sure with PMDF what headers I can and cannot strip
    >> unconditionally using headertrim.

    >
    >It's quite simple: There's a list. If your header is on it you can trip it
    >without affecting other fields, if not you cannot. Items are added to the
    >list from time to time as needs and tastes change. I'm sure that by now
    >the lists in iMS and PMDF have diverged.
    >
    >The simplest way to see the list is to run PMDF MAIL, enter "set
    >header_trimming " and hit question mark to see the available options.
    >


    Thanks



    >> The manual seems to suggest you can only strip headers which are standardised
    >> in the RFCs otherwise you have to use the special header line name Other:.

    >
    >Not sure where you got that idea. It has never been true.
    >


    From section 2.3.7.2 Header option file format

    Simply put, the contents of a header option file are formatted as a
    set of message header lines. Note, however, that the bodies of the
    header lines do not conform to RFC 822.

    The general structure of a line from a header options file is then:

    Header-name: OPTION=VALUE, OPTION=VALUE, OPTION=VALUE, ...

    where Header-name is the name of a header line that PMDF recognizes
    (any of the header lines described in this manual may be specified,
    plus any of the header lines standardized in RFC 822, RFC 987, RFC
    1049, RFC 1421, RFC 1422, RFC 1423, RFC 1424, RFC 2156, and RFC 2045).

    Header lines not recognized by PMDF are controlled by the special
    header line name Other:.

    ..
    ..
    ..




    >> I wouldn't have thought X-MAILER was a standardised header (but I maybe wrong).
    >> Hence I'd presumably need to use the Other: syntax but I'm not sure how to
    >> do that - an example would be very useful.

    >
    >The trimming file
    >
    >x-mailer: maximum=-1
    >
    >should do the trick.
    >
    >> Stripping the X-MAILER heading on mail I emit would seem to be a sensible
    >> work-around to this problem unless you or anyone else (Hunter ?) could see
    >> other problems that this would cause.

    >
    >I for one never use X-mailer: in the mail I send; not using it has never caused
    >me any trouble. It is precisely because of dain-bramaged checks like this that
    >I don't use it.
    >

    I've replaced the X-Mailer header line with a X-Orig-Mailer line using

    X-MAILER: RELABEL="X-Orig-Mailer"

    Hence if someone really needs to know this came from an Apple mail client then
    the information is there just under a different header.


    David Webb
    Security team leader
    CCSS
    Middlesex University




    > Ned


+ Reply to Thread