Re: Anti spam filtering tools
Le 6 mars 2015 à 00:48, Noel Jones a écrit : > > All anti-spam tools require configuration and updating. > > Updating (via the FreeBSD ports system or the various linux package > management tools) should be fairly painless for any antispam tool > you choose, or at least they should all have a similar level of pain. > > Amavisd-new does not stand out as particularly difficult to use. > All the antispam tools I'm aware of require some level of expertise > along with periodic care and feeding. > > So mostly "what spam tool do you prefer" is an open-ended discussion > with no real right or wrong, and most folks on this list don't have > time for a pointless argument. > > The one suggestion I have is to use the amavisd-new built-in SPF > tools instead of a separate program. > Ok Thanks for your answer. We are using a flat file for one server and an integrated PostgreSQL solution for the other. I’ll follow your advice for SPF. Thanks. > > > -- Noel Jones «?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§ Your provider of OpenSource Appliances www.osnet.eu «?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§ PGP ID --> 0x1BA3C2FD
Re: Trying to forward root's email to the sysadmins who need it
On Thu, Mar 05, 2015 at 05:36:20PM -0800, Kai Lanz wrote: > > We have an RHEL-6 host on which jobs like cron and logwatch generate emails > to the local root user. No one logs into this host as root to read those > emails; we want to forward them to the managers (like me) who need to see > them. I can get postfix working to send emails to remote users, but I can't > seem to get it to forward root's email. http://www.postfix.org/MULTI_INSTANCE_README.html#split With simple null-clients you can stop after setting up the null-client without adding an MTA instance. > I initially made the following changes to the freshly-installed postfix > config: > > # postconf -e myorigin=stanford.edu > # postconf -e 'relayhost=[smtp.stanford.edu] > # postconf -e local_transport="error:local delivery disabled" > # postconf -e smtp_use_tls=yes With "myorigin" remote, rewriting needs to use virtual(5) not aliases(5), as explained in the null-client example. > I then edited /etc/aliases and added the alias for the root user: > > root: manag...@sesmail.stanford.edu Local aliases have no effect on mail that is relayed, rather than delivered locally. -- Kai Lanz Stanford University School of Earth Sciences P.S. The stanford.edu domain is one of the few .edu domains with DNSSEC enabled. I'd like to see Stanford be the first ".edu" with DANE TLSA records. The postmaster for stanford.edu can contacting me off-list for guidance if there any questions.
Re: Adding a Reply-To header to forwarded e-mails
MegaBrutal: > I use a virtual alias to create a simple distribution list to make > communication easier within our group. I'd like to add a "Reply-To" > header to e-mails being forwarded through the virtual alias, because > I'd like to direct replies back to the list by default. > > How can I configure Postfix to add a "Reply-To" header? This is a standard mailing list manager feature. You could try to use the PREPEND action in an SMTP server access(5) table, but you will be missing other features are common with mailing list managers such as loop detection. listn...@example.comprepend Reply-To: listn...@example.com > I only want to add a Reply-To to e-mails sent to a specific virtual > address. I would not like to use a dedicated mailing list software. You want a mailing list manager feature. Use a mailing list manager. Wietes
Re: Policy attributes to PERL script
On Fri, Mar 06, 2015 at 01:54:54AM +, Mick wrote:
> Hi Markus,
>
> I am pleased to say my 'moonshine' perl based policy is now up and running.
>
>
> Benning, Markus wrote:
> >The reject_sender_login_mismatch in smtpd_sender_restriction
> >already does that
> >as a native postfix check:
> I didn't know that. There is a lot I don't know or understand, which
> is why I decided to try to come up with something myself. Regarding
> blocking sender login mismatch, I will keep that in the policy. I
> added an extra field to the policy mysql DB table enabling mailboxes
> to be group linked by an administrator. This means that an SMTP
> login within a specific group, can send messages on behalf of anyone
> else provided that has the same group code. A very simple addition
> where both the sender and sasl-username are cross checked with the
> group name (if any).
>
> $action= "action=DUNNO\n\n";
> if ($sasl_username ne $sender)
> {
> if(length($sasllink)>0 && length($senderlink)>0 && $sasllink eq
> $senderlink) {}
> else { $action= "action=REJECT Not authorised\n\n";}
> }
> }
Suggestion:
$action =
$sasl_username eq $sender || (length($sasllink) && $sasllink eq
$senderlink)
? "action=DUNNO\n\n";
: "action=REJECT Not authorised\n\n"
Paul.
--
Paul Hoffman
Systems Librarian
Fenway Libraries Online
c/o Wentworth Institute of Technology
550 Huntington Ave.
Boston, MA 02115
(617) 442-2384 (FLO main number)
Re: Policy attributes to PERL script
Paul Hoffman wrote:
$action= "action=DUNNO\n\n";
if ($sasl_username ne $sender)
{
if(length($sasllink)>0 && length($senderlink)>0 && $sasllink eq
$senderlink) {}
else { $action= "action=REJECT Not authorised\n\n";}
}
}
Suggestion:
$action =
$sasl_username eq $sender || (length($sasllink) && $sasllink eq
$senderlink)
? "action=DUNNO\n\n";
: "action=REJECT Not authorised\n\n"
Paul.
Hi Paul,
I like your suggestion. I didn't realise you could format a TRUE / FALSE
statement like that so I have replaced that particular part of the
script with yours so I have something to refer to later. It was a bit a
bit misleading of me stating $action is declared where it is shown to
be, as it goes through the quota and already blocked sections first
where it can be changed to reject. I have adjusted your suggested script
to keep original $action value if TRUE is returned.
I guess this is sloppy programming on my part. As soon as a rejection is
spotted, I suppose I could just add;
print"action=REJECT reason being..";
exit(0);
.. and end the program.
Here is how that part of the script looks now ;
if($sasl_username ne "\n")
{
$action = $sasl_username eq $sender || (length($sasllink) && $sasllink
eq $senderlink)
? "$action"
: "action=REJECT Not authorised\n\n";
}
Much neater than my burn offerings. Thanks again. The' if($sasl_username
ne "\n") ' is still needed as non SASL authenticated incoming mail would
be rejected otherwise.
Cheers,
Mick.
Re: Trying to forward root's email to the sysadmins who need it
On Mar 5, 2015, at 8:49 PM, Noel Jones wrote: > maybe this will help. > http://www.postfix.org/STANDARD_CONFIGURATION_README.html#some_local I’ve solved our problem. Turns out we were missing the virtual_alias_maps line in main.cf. Once I added that, things started working much better. To summarize, our current main.cf now contains the following lines: relayhost = [smtp.stanford.edu] local_transport = error:local delivery disabled smtp_use_tls = yes myhostname = seswsbackup.stanford.edu myorigin = stanford.edu virtual_alias_maps = hash:/etc/postfix/virtual And in /etc/postfix/virtual, we have just: rootmanag...@sesmail.stanford.edu Entries in maillog now show that r...@stanford.edu is being rewritten the way we want: Mar 6 10:38:30 seswsbackup postfix/smtp[4085]: 4B6ECC0A7D: to=, orig_to=, relay=smtp.stanford.edu[171.64.13.8]:25, delay=0.32, delays=0.11/0.13/0.05/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 83D73341215) — Kai Lanz Stanford University School of Earth Sciences
