Re: SPF ("senders permitted from") support in PMDF? - VMS

This is a discussion on Re: SPF ("senders permitted from") support in PMDF? - VMS ; > In article , Selden E Ball Jr writes: > >Gentle folk, > > > >Are there plans for supporting SPF ("senders permitted from") in PMDF? > > > >See http://spf.pobox.com/for-mit-spam-conference.gif > >and > > http://spf.pobox.com/ > > > >for ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: SPF ("senders permitted from") support in PMDF?

  1. Re: SPF ("senders permitted from") support in PMDF?

    > In article <01L6655JHNTA90F3P3@LNS62.LNS.CORNELL.EDU>, Selden E Ball Jr writes:
    > >Gentle folk,
    > >
    > >Are there plans for supporting SPF ("senders permitted from") in PMDF?
    > >
    > >See http://spf.pobox.com/for-mit-spam-conference.gif
    > >and
    > >http://spf.pobox.com/
    > >
    > >for more information.
    > >
    > >It seems to break quite a few things, but it probably should be
    > >available for those sites who decide it's appropriate.
    > >


    > Yes looks like it could cause major problems if the ISPs were to adopt it.
    > This would stop the standard practise of home users setting their from address
    > to be their work email address but sending through their local ISPs mailhub in
    > order to get around their work mailhub's anti-relaying rules.
    > The alternatives SMTP AUTH or POP-before SMTP aren't widely enough deployed -
    > on a central mailhub without user accounts it can be difficult to find a usable
    > authentication source.


    While it is true that these schemes (there are at least five others besides
    SPF) will break a fair amount of stuff, I'm convined that their widespread
    adoption is inevitable. The only question is whether we end up with one
    or many schemes.

    One consequence of this is that while support for whichever one of these
    ends up deploying may be useful, even more important is support for the
    various facilities we'll need to work around the problems these things
    cause. These include tricky address rewriting to make forwarding work and
    perhaps better authentication schcmes more sites can deploy.

    Ned

  2. Re: SPF ("senders permitted from") support in PMDF?

    In article <01L67EZJQ2O800Q4RU@mauve.mrochek.com>, ned+info-pmdf@mauve.mrochek.com writes:
    >> In article <01L6655JHNTA90F3P3@LNS62.LNS.CORNELL.EDU>, Selden E Ball Jr writes:
    >> >Gentle folk,
    >> >
    >> >Are there plans for supporting SPF ("senders permitted from") in PMDF?
    >> >
    >> >See http://spf.pobox.com/for-mit-spam-conference.gif
    >> >and
    >> >http://spf.pobox.com/
    >> >
    >> >for more information.
    >> >
    >> >It seems to break quite a few things, but it probably should be
    >> >available for those sites who decide it's appropriate.
    >> >

    >
    >> Yes looks like it could cause major problems if the ISPs were to adopt it.
    >> This would stop the standard practise of home users setting their from address
    >> to be their work email address but sending through their local ISPs mailhub in
    >> order to get around their work mailhub's anti-relaying rules.
    >> The alternatives SMTP AUTH or POP-before SMTP aren't widely enough deployed -
    >> on a central mailhub without user accounts it can be difficult to find a usable
    >> authentication source.

    >
    >While it is true that these schemes (there are at least five others besides
    >SPF) will break a fair amount of stuff, I'm convined that their widespread
    >adoption is inevitable. The only question is whether we end up with one
    >or many schemes.
    >
    >One consequence of this is that while support for whichever one of these
    >ends up deploying may be useful, even more important is support for the
    >various facilities we'll need to work around the problems these things
    >cause. These include tricky address rewriting to make forwarding work and
    >perhaps better authentication schcmes more sites can deploy.
    >


    Yes for PMDF we definitely need additional authentication methods builtin
    eg

    Kerberos support
    LDAP with TSL/SSL

    to work with directories such as Novell's NDS and Microsoft's active directory
    as well as other LDAP directories.

    Personally (although I can see from a financial point of view this probably
    wouldn't appeal to Process) I'd also like TSL to be added into the main product
    rather than being an expensive addon. Most other mail systems now seem to
    provide such support in with the base product - you just need to buy the
    certificates.

    David Webb
    VMS and Unix team leader
    CCSS
    Middlesex University


    > Ned


+ Reply to Thread