Loading ...
Sorry, an error occurred while loading the content.

Re: Restriction class limitations

Expand Messages
  • Glen Lee Edwards
    ... Yes, that s correct. Is there a work around? I suppose I could change the ownership of the sendmail command so the webserver can t use it and force
    Message 1 of 7 , May 1 6:36 AM
    • 0 Attachment
      On Thu, 2008-05-01 at 13:26 -0500, Noel Jones wrote:
      > Glen Lee Edwards wrote:
      > > Background:
      > >
      > > I'm trying to set up a local_only restriction class, but apparently am
      > > doing something wrong. In the directions, it states the following:
      > >
      > > ************
      > > Note: this scheme does not authenticate the user, and therefore it can
      > > be bypassed in several ways:
      > >
      > > * By sending mail via a less restrictive mail relay host.
      > >
      > > * By sending mail as someone else who does have permission to send
      > > mail to off-site destinations.
      > > ************
      > >
      > > I'm guessing that it's failing due to the line, "By sending mail as
      > > someone else..." Here's what I'm trying to do:
      > >
      > > I have no local users who need off site access. The only local user who
      > > needs to send any mail at all is the apache web server, who is user
      > > www.
      > >
      > > My goal: I want no off site deliveries of mail that originates from the
      > > web server, so contact forms on web sites that I host that send out mail
      > > must be sent so that the mail has to be delivered to a local POP3 box,
      > > otherwise it must to be rejected by Postfix if addressed to any off site
      > > destination.
      > >
      > > The problem: Mail is still being delivered off site even though I've set
      > > up a local_user restriction class.
      > >
      > > The cause (I think): Mail is leaving here with the envelope sender being
      > > www@.... The contact forms are rewriting the From: line to show
      > > the address of the individual who is filling out the form. Is that my
      > > problem? If so, is there a fix?
      > >
      >
      > I would guess the problem is that your web server submits mail
      > using the 'sendmail' command rather than through SMTP.
      > Postfix smtpd_*_restrictions are only effective on mail
      > submitted via SMTP.

      Yes, that's correct. Is there a work around? I suppose I could change
      the ownership of the 'sendmail' command so the webserver can't use it
      and force everyone to use SMTP.

      I keep getting black listed by AT&T, and I'm getting tired of it. I'm
      trying to shut off all outgoing mail originating from here, and serious
      limit the number of users who have forwarding addresses that accept off
      site mail and forward said mail to off site locations.

      Glen
    • Ralf Hildebrandt
      ... Look at authorized_submit_users -- Ralf Hildebrandt (Ralf.Hildebrandt@charite.de) snickebo@charite.de Postfix - Einrichtung, Betrieb und Wartung
      Message 2 of 7 , May 1 11:40 AM
      • 0 Attachment
        * Glen Lee Edwards <gle@...>:

        > Yes, that's correct. Is there a work around? I suppose I could change
        > the ownership of the 'sendmail' command so the webserver can't use it
        > and force everyone to use SMTP.

        Look at authorized_submit_users

        --
        Ralf Hildebrandt (Ralf.Hildebrandt@...) snickebo@...
        Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
        http://www.arschkrebs.de
        "Ninety-eight percent of the adults in this country are decent,
        hardworking, honest Americans. It's the other lousy two percent that
        get all the publicity. But then, we elected them." - Lily Tomlin
      • Wietse Venema
        ... You don t have to change sendmail file permissions. Instead, you can specify the legitimate senders with the main.cf authorized_submit_users paramater.
        Message 3 of 7 , May 1 12:13 PM
        • 0 Attachment
          Glen Lee Edwards:
          > > I would guess the problem is that your web server submits mail
          > > using the 'sendmail' command rather than through SMTP.
          > > Postfix smtpd_*_restrictions are only effective on mail
          > > submitted via SMTP.
          >
          > Yes, that's correct. Is there a work around? I suppose I could change
          > the ownership of the 'sendmail' command so the webserver can't use it
          > and force everyone to use SMTP.

          You don't have to change sendmail file permissions.

          Instead, you can specify the "legitimate" senders with the main.cf
          authorized_submit_users paramater.

          Wietse

          authorized_submit_users (default: static:anyone)
          List of users who are authorized to submit mail with the sendmail(1)
          command (and with the privileged postdrop(1) helper command).

          By default, all users are allowed to submit mail. Otherwise, the real
          UID of the process is looked up in the system password file, and access
          is granted only if the corresponding login name is on the access list.
          The username "unknown" is used for processes whose real UID is not
          found in the password file. To deny mail submission access to all users
          specify an empty list.

          Specify a list of user names, "/file/name" or "type:table" patterns,
          separated by commas and/or whitespace. The list is matched left to
          right, and the search stops on the first match. A "/file/name" pattern
          is replaced by its contents; a "type:table" lookup table is matched
          when a name matches a lookup key (the lookup result is ignored). Con-
          tinue long lines by starting the next line with whitespace. Specify
          "!pattern" to exclude a user name from the list. The form "!/file/name"
          is supported only in Postfix version 2.4 and later.

          Example:

          authorized_submit_users = !www, static:all

          This feature is available in Postfix 2.2 and later.
        Your message has been successfully submitted and would be delivered to recipients shortly.