Forwarding mail - SPF SRS
Hi, I have mail forwarders used for SPAM mitigation where the addresses appear on a public web page. With many ISPs using SPF, I'm concerned that it won't be too long before these forwarded messages start to be discarded. I have read that implementing a Sender Rewriting Scheme may solve this problem, and viewed a couple tutorials showing 'pfixtools' and 'postsrsd'. At least one of those schemes re-writes the envelope for every received message which seems overkill to me. Does anyone know if there's a table based way to get cleanup(8) to rewrite on matching the local alias? canonical(5)?? I will be pleased to read of any alternatives, if there are any. Best regards, Mick.
Re: Forwarding mail - SPF SRS
On 27/08/2015 14:07, Viktor Dukhovni wrote: On Thu, Aug 27, 2015 at 02:02:36PM +0100, Mick wrote: At least one of those schemes re-writes the envelope for every received message which seems overkill to me. That's what needs to be done. Okay. I'm surprised though. Does anyone know if there's a table based way to get cleanup(8) to rewrite on matching the local alias? canonical(5)?? No. Secure SRS rewriting that does not turn your machine into an open relay is too complex for lookup tables. I'm don't understand how, but I don't doubt your words. Thank you for pointing this fact out. When choosing, is there is anything between 'pfixtools' and 'postsrsd' methods that you know of that makes one better than the other? If not, I will try 'postsrsd'. Best regards, Mick.
Re: Forwarding mail - SPF SRS
On 27/08/2015 14:26, Wietse Venema wrote: Viktor Dukhovni: On Thu, Aug 27, 2015 at 02:02:36PM +0100, Mick wrote: Does anyone know if there's a table based way to get cleanup(8) to rewrite on matching the local alias? canonical(5)?? No. Secure SRS rewriting that does not turn your machine into an open relay is too complex for lookup tables. And that is not all. Depending on the original From: domain, receivers that enforce DMARC policy may also require that the original From: header address is replaced with one in the forwarder's domain. Thanks Wietse. Mick. Wietse
Re: Forwarding mail - SPF SRS
Thanks for your reply Benny. On 27/08/2015 20:19, Benny Pedersen wrote: Mick skrev den 2015-08-27 15:02: I will be pleased to read of any alternatives, if there are any. drop sender-id, drop srs Dropping sender-id? Do you mean leave MAIL FROM: <> blank or have I got the wrong end of the stick and you mean modify the message headers? I'm not sure I could, or even if I'd want to do either, but thanks for the suggestion. I've now installed 'PostSRSd'. Should I be nervous of reverse SRS abuse or is the cryptographic signature and a time stamp enough to prevent this ? use spf, sign with dkim Yes, I use both. monitor dmarc https://dmarcian.com/ i can only say good things about this domain, it have helped me on track with it all, even for domains that have there own server problems with spf, or servers where i just managed the dns for example.net Fair that dmarcian.com only charge by the SPF passes and not the failures. They have a free service too which is definitely good. I've only touched on DMARC and wonder (at the moment) why you would need a service like that? My limited understanding is ; you publish a DMARC DNS text record with email address, then service providers email that address in the event of a rejection? I've probably got that all wrong. Something else to read up on as it's my next project. if all the above is not possible stop forwarding Yes, that is an option that I have considered. Best Regards, Mick.
Dynamic 'myhostname'
Hi, I'm trialling DMARC to two of my domains. On checking the results when posting from the secondary domain I receive 'SPF Domain Alignment Result = FAIL'. I think this is because postfix always says HELO with the primary domain name, which is obviously different to the secondary. Is there a way to rewrite the message envelope to say HELO using the same domain used in the from field? Thanks, Mick.
Re: Dynamic 'myhostname'
On 10/09/2015 21:13, Wietse Venema wrote: Mick: Hi, I'm trialling DMARC to two of my domains. On checking the results when posting from the secondary domain I receive 'SPF Domain Alignment Result = FAIL'. I think this is because postfix always says HELO with the primary domain name, which is obviously different to the secondary. Is there a way to rewrite the message envelope to say HELO using the same domain used in the from field? I suspect that the problem is that the SMTP client IP address no not match the SPF rule. You may want to set up sender_dependent_default_transport to use different Postfix SMTP clients depending on the envelope sender email address, with "-o smtp_bind_address" settings in master.cf for the proper client IP address. Hi Wietse, I only have 1 IP address (2 if you count the IPv6 address). A reverse DNS lookup will always find my primary domain so even if I used 'sender_dependent_default_transport' and set up multiple switches just to change HELO name, they still have to point to the same IP. If reverse DNS was then carried out, secondary domain provided in the HELO would not match and mail could be rejected. Think I'm stuffed without additional IPv4s, but at least I know why. Thanks for your advice. Mick. Wietse
Re: Dynamic 'myhostname'
Hi Christian, Hi Wietse, I only have 1 IP address (2 if you count the IPv6 address). A reverse DNS lookup will always find my primary domain so even if I used 'sender_dependent_default_transport' and set up multiple switches just to change HELO name, they still have to point to the same IP. If reverse DNS was then carried out, secondary domain provided in the HELO would not match and mail could be rejected. Think I'm stuffed without additional IPv4s, but at least I know why. Your setup should work. I have a similar setup with 5 domains of which the one that holds the helo-name of my Mailserver is not my primary maildomain... and that works well with spf dkim and dmarc. When searching for your error message it seems that maybe your envelope and from aren't aligned, this could be checked on spf test websites that analyse your setup after you send them an email to a special one-time address. Thank you very much indeed for your help. As a result I re-checked my configuration and found you were spot on, the culprit being postsrsd. The very thing I added to allow forwarding without breaking SPF / DMARC appends the From field to the primary domain regardless of the domain the message comes from. I've withdrawn postsrsd for now while I look into a possibility of work around or something to replace it. Have you had a look at the spf rfc 7208? Yes. It's a good document. I'm more a pragmatist than theorist so always appreciate examples which rfc7208 provides plenty. Best regards, Mick. Regards Christian Thanks for your advice. Mick. Wietse
Re: Dynamic 'myhostname'
Hi, Quoting myself The very thing I added to allow forwarding without breaking SPF / DMARC appends the From field to the primary domain regardless of the domain the message comes from. I've withdrawn postsrsd for now while I look into a possibility of work around or something to replace it. I know this is not strictly on topic, but it probably concludes this thread : After realising it wasn't 'myhostname' that needed to be made dynamic, I searched for a way to get postsrsd to make 'SRS_DOMAIN' dynamic. I hoped this could be set by the domain of the local recipient (not the final destination). I gave up after yielding no positive results though. My get out : As only 'domain2' forwards any mail externally, I decided to set 'SRS_DOMAIN' to 'domain2' and 'SRS_EXCLUDE_DOMAINS' to exclude all other domains using config file '/etc/default/postsrsd'. From then on, only 'from' headers from 'domain2' are re-written by postsrsd and are appended '@domain2' meaning no failed SPF domain alignment results. I can now set DMARC adkim to strict I suppose. If anyone has managed to make 'SRS_DOMAIN' dynamic, I'd love to hear how, otherwise please considder this resolved. Thanks Wietse and Christian for your help. Best regards, Mick.
Re: Fwd: Adding a noreply address
On 27/01/2016 12:00, Matt Bayliss wrote: However when I send mail to nore...@domain.com <mailto:nore...@domain.com> from an external source (Gmail) I get a bounceback and "Recipient address rejected: User unknown in local recipient table;" in the log. Similarly when I try to use it in a To: address field I get the same response. 'nore...@domain.com' needs to exist as a mailbox in order for you to discard mail to it as far as I can tell. Mick Thanks,
Re: Adding a noreply address
Indeed.
On 27/01/2016 20:45, @lbutlr wrote:
On 27 Jan 2016, at 05:46, Mick wrote:
'nore...@domain.com' needs to exist as a mailbox in order for you to discard
mail to it as far as I can tell.
Obviously not, since Wietse posted:
transport_maps = inline:{u...@example.com=discard:}
Re: Adding a noreply address
Prior to Wietse's earlier post on this thread, I didn't know you could
alias a non existent address back on itself in order to make the
address known to Postfix. That's simply clever! I did know you can't
silently discard messages using Transport if the address didn't exist,
nor by aliasing such an address to an existing mailbox if the
destination accepts mail. I don't reject 'noreply' addresses myself,
but would opt for Wietse's method should I ever feel the need to do
so. Both methods work though.
Mick.
On 27/01/2016 21:03, Wietse Venema wrote:
@lbutlr:
On 27 Jan 2016, at 05:46, Mick wrote:
'nore...@domain.com' needs to exist as a mailbox in order for you to discard
mail to it as far as I can tell.
Obviously not, since Wietse posted:
transport_maps = inline:{u...@example.com=discard:}
Unfortunately, transport_maps does not decide what addresses are valid;
that decision is based on virtual_alias_maps, local_recipient_maps,
relay_recipient_maps, and virtual_mailbox_maps.
Wietse
Installing Postfix version that is newer than offered in the Debian repository.
Hi Postfix users, I would like to try and install a later version of Postfix (and postfix-mysql) than the Debian stable (Jessie) repository currently offers (2.11.3-1). I've looked at building Postfix 3.1 from source, but I'm finding it hard to follow the instructions. This is wholly down to *my* lack of understanding regarding the building process and dependences I would need to build in for my system and no reflection on the author. As an alternative to building from source, I am also considering the easier option of installing version 3.0.4-5 from the Debian testing source (Stretch) using a pinned source list. This leaves me with a question on dependencies. Should I install postfix dependencies from the Debian Stretch source list which may upset Jessie's stability, or instead download them from Jessie which may cause Postfix problems ? If I were to attempt to build 3.1, would it be better to first install 2.11 and get that up an running? I ask as there may be less dependencies to build into 3.1, and certainly less to configure if the main.cf and master.cf already exist. To sum up, I don't know which way to go, though I'm thinking 3.1 would be the best route long term. Any suggestions welcomed. Best wishes, Mick.
Re: Installing Postfix version that is newer than offered in the Debian repository.
On 26/03/2016 18:54, Scott Kitterman wrote: On Saturday, March 26, 2016 05:44:45 PM Mick wrote: Hi Postfix users, I would like to try and install a later version of Postfix (and postfix-mysql) than the Debian stable (Jessie) repository currently offers (2.11.3-1). I've looked at building Postfix 3.1 from source, but I'm finding it hard to follow the instructions. This is wholly down to *my* lack of understanding regarding the building process and dependences I would need to build in for my system and no reflection on the author. As an alternative to building from source, I am also considering the easier option of installing version 3.0.4-5 from the Debian testing source (Stretch) using a pinned source list. This leaves me with a question on dependencies. Should I install postfix dependencies from the Debian Stretch source list which may upset Jessie's stability, or instead download them from Jessie which may cause Postfix problems ? If I were to attempt to build 3.1, would it be better to first install 2.11 and get that up an running? I ask as there may be less dependencies to build into 3.1, and certainly less to configure if the main.cf and master.cf already exist. To sum up, I don't know which way to go, though I'm thinking 3.1 would be the best route long term. Any suggestions welcomed. We are close to uploading Postfix 3.1 to Debian Unstable, which means it should be in Testing (Stretch) soonish. There are a number of historical differences between the upstream and Debian approach to packaging postfix that are substantially narrowed starting in Postfix 3.0. We're still working on adapting the Debian packaging and I expect 3.1 to have less difference in this regard. I would not recommend updating a Debianized Postfix 2.11.3 to an upstream built from source Postfix 3.0/3.1. If you want to go the route of building from source, I would remove the Debianized version first. If you choose to go the route of adding Stretch to your sources.list with appropriate pinning, the dependencies should only be pulled in from Stretch if they are not present in sufficient version in Jessie. Do pay close attention at what is being upgraded and decide for yourself if it is too much to be comfortable with (for example if the package pulls in a new libc6 version that would be a sign to be concerned in my opinion). Another alternative would be to rebuild the Debian Postifx 3.0 packaging specifically for Jessie. If you don't know how to do this, http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial has some good advice (don't panic about the size of the document, you'll only need to deal with a small part of it). This would likely eliminate the need to upgrade dependencies. If it were me, I'd to the last option. For further information on working with the Debianized packaging, I would suggest contacting a Debian specific support resource as it's not particularly on topic here. Scott K Hi Scott, I will follow your advice and have a go at your suggestion of rebuilding the Debian Postfix 3.0 packaging for Jessie from Stretch source code. This has veered OT as you mentioned, so I won't say any more except that I apologise to the others here for making noise and thank you Scott much for you help and idea. Mick.
Logging sender and recipient when message size exceeds fixed limit
Hi, While checking the mail log yesterday morning, I noticed that Postfix didn't log the sender or recipient when it rejected a message due to exceeding the message_size _limit. I'd be interested to know if this is the intended behaviour. I'm running Debianized Postfix 3.1.0. Log excerpt; Jun 20 03:53:34 skin P25/smtpd[13887]: connect from mail-it0-x22b.google.com[2607:f8b0:4001:c0b::22b] Jun 20 03:53:35 skin P25/smtpd[13887]: NOQUEUE: reject: MAIL from mail-it0-x22b.google.com[2607:f8b0:4001:c0b::22b]: 452 4.3.4 Message size exceeds fixed limit; proto=ESMTP helo= Jun 20 03:53:40 skin P25/smtpd[13887]: disconnect from mail-it0-x22b.google.com[2607:f8b0:4001:c0b::22b] ehlo=1 mail=0/1 rcpt=0/1 data=0/1 quit=1 commands=2/5 Many thanks, Mick.
Re: Logging sender and recipient when message size exceeds fixed limit
Hi Wietse, On 21/06/2016 01:21, Wietse Venema wrote: Mick: Hi, While checking the mail log yesterday morning, I noticed that Postfix didn't log the sender or recipient when it rejected a message due to exceeding the message_size _limit. I'd be interested to know if this is the intended behaviour. I'm running Debianized Postfix 3.1.0. Log excerpt; Jun 20 03:53:34 skin P25/smtpd[13887]: connect from mail-it0-x22b.google.com[2607:f8b0:4001:c0b::22b] Jun 20 03:53:35 skin P25/smtpd[13887]: NOQUEUE: reject: MAIL from mail-it0-x22b.google.com[2607:f8b0:4001:c0b::22b]: 452 4.3.4 Message size exceeds fixed limit; proto=ESMTP helo= Jun 20 03:53:40 skin P25/smtpd[13887]: disconnect from mail-it0-x22b.google.com[2607:f8b0:4001:c0b::22b] ehlo=1 mail=0/1 rcpt=0/1 data=0/1 quit=1 commands=2/5 How would one log a recipient when the MAIL FROM command is rejected? have you discovered some way to send RCPT TO without MAIL FROM? No, but I obviously can't read log files! Apologies. I was under the (wrong) impression that for the message to be rejected due to exceeding the message size limit, it would have had to have got to the data stage. I take it from your response (and noting the log 'reject: MAIL from') that the sender just piled in over 10MB of data at the 'mail from:' stage. That never even occurred to me though it should have been obvious. Thanks for your help, Mick. Wietse
Re: Logging sender and recipient when message size exceeds fixed limit
Hi Bill, Shameful admission : I didn't realise that a sending machine using EHLO could declare the message size in the 'Mail from:'. I have been able to replicate the log behaviour using Telnet using an example in RFC1870. After issuing a EHLO command; >> mail from: SIZE=234567895 << 452 4.3.4 Message size exceeds fixed limit Log ; ... Jun 21 11:23:17 skin P25/smtpd[28880]: connect from localhost.localdomain[127.0.0.1] Jun 21 11:24:10 skin P25/smtpd[28880]: NOQUEUE: reject: MAIL from localhost.localdomain[127.0.0.1]: 452 4.3.4 Message size exceeds fixed limit; proto=ESMTP helo= Jun 21 11:24:19 skin P25/smtpd[28880]: disconnect from localhost.localdomain[127.0.0.1] ehlo=1 mail=0/1 quit=1 commands=2/3 ... It is a shame Postfix doesn't log the mail from: or data size offered, but seeing as that is this field the message fails on I understand why. The log entry makes sense now I understand what's going on. Thank you very much for your explanation and also for pointing me to RCF1870. Best wishes, Mick. On 21/06/2016 03:52, Bill Cole wrote: On 20 Jun 2016, at 20:54, Mick wrote: I take it from your response (and noting the log 'reject: MAIL from') that the sender just piled in over 10MB of data at the 'mail from:' stage. Unlikely, since it was a Google machine and that's not how size restriction works. In this case the session summary implies that the sender was pipelining commands: not waiting for or parsing replies all the way through, just stopping after DATA to figure out whether it could send message data and finding that it could not. It was the MAIL command that Postfix rejected first and after that point there's no reason for Postfix to pay attention to the specifics of later pipelined commands. See RFC1870 for the specifics but the simple explanation of how size limits work before DATA is that the server announces its maximum size in a EHLO reply along with other extensions like PIPELINING and the client announces the size it intends to send as an extra argument to the MAIL command. In this case it looks like the sender ignored what your server said was its limit, announced it would send more, and Postfix said no to MAIL while the sender kept on going all the way to DATA. Most clients respect the size limit in the EHLO reply and don't try MAIL with a larger size but it looks like Google's software takes RFC2920 (the pipelining extension) quite literally, immediately starts pipelining commands when it reads the PIPELINING line in the EHLO reply and not waiting for the "SIZE=[$message_size_limit]" advertisement of your size limit a few lines later. I don't believe I've seen any other SMTP sender behave quite that way but I suppose Google probably has data supporting that behavior as more efficient than waiting for the whole EHLO reply and parsing it. That yields a strange set of log entries, but the more common approach would log nearly nothing when a legitimate sender has an oversize message for you: just a connect line and a disconnect line with just "ehlo=1 quit=1 commands=2" describing what the client did.
Re: Policy attributes to PERL script
Hello Markus,
Thanks very much for your reply. I didn't come across Cookbook in my
searches but I don't think I will need it now as I'm very pleased to
report I got my first test policy implemented yesterday evening. Don't
laugh, all it does so far is block senders where 'sender' doesn't match
'sasl-user'. Everyone has to start somewhere right? It does put me in a
place where I can write customised policies now. I was thinking of
using mysql but everyone seems to use Berkeley DB? Maybe worth
considering as it has a locking arrangement.
One of my user email accounts was compromised a couple of months ago and
over a period of 5 hours thousands of SPAM messages were sent. G!
Since then I have become rather paranoid checking the mail log whenever
I can looking for "Relay=' and auth failures manually barring IPs that
repeatedly fail to log in. I need to relax a bit so decided to try and
write a SPAM limitation policy, as in ;
if (X number of messages sent in Y time), {
external relay access blocked until user resets password
}.
To do this I needed to read the SASL_USERNAME field into PERL in order
to log and count SMTP requests to their account, now I can, thanks to
help given here. I think by Thursday I will have a test version of it
up and running.
So far with just sasl != user;
$client_address="";
$client_name="";
$reverse_client_name="";
$helo_name="";
$sender="";
$recipient="";
$recipient_count="";
$sasl_username="\n";
$c=0;
while ($c==0) {
$b=();
$a.=$b;
if ($b =~ /=/) {
my ($key, $value) =split (/=/, $b, 2);
if ($key eq "client_address") { $client_address=$value;}
if ($key eq "client_name") { $client_name=$value;}
if ($key eq "reverse_client_name") { $reverse_client_name=$value;}
if ($key eq "helo_name") { $helo_name=$value;}
if ($key eq "sender") { $sender=$value;}
if ($key eq "recipient") { $recipient=$value;}
if ($key eq "recipient_count") { $recipient_count=$value;}
if ($key eq "sasl_username") { $sasl_username=$value;}
}
if($b eq "\n") { $c=1;}
}
$action="action=DUNNO\n\n";
if($sasl_username ne "\n") {
if ($sasl_username ne $sender) {
$action= "action=REJECT Wrong sender\n\n";
}
}
print $action;
...
Thanks for your suggestion,
Mick.
Benning, Markus wrote:
Am 2015-02-27 14:45, schrieb MickTW8:
This issue I have is knowing how to read any of the attributes listed
here
www.postfix.org/SMTPD_POLICY_README.html#protocol
Hello Mick,
it may be an option for your to implement your code as a plugin for
mtpolicyd.
There's documentation for wrinting a simple plugin at:
https://www.mtpolicyd.org/getting-started.html#Mail::MtPolicyd::Cookbook::BasicModule
Then you wont have to care about accepting connections, parsing,
logging and so on.
Another option may be to just copy over the Request class to your
project and remove
dependencies on Net::Server, etc. from it:
https://github.com/benningm/mtpolicyd/blob/master/lib/Mail/MtPolicyd/Request.pm
Markus
Re: Policy attributes to PERL script
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";}
}
}
I guess I can skip one of the two lengths being greater than 0 as if one
is and one isn't, they wouldn't be equal anyway. Only just noticed that.
Ho humm.
http://www.postfix.org/postconf.5.html#smtpd_sender_restrictions
The Accounting/Quota module in mtpolicyd can be used to count/limit mails
per sasl user in a SQL database supported by perl-DBI (SQLite, MySQL,
etc.):
https://www.mtpolicyd.org/getting-started.html#Mail::MtPolicyd::Cookbook::HowtoAccountingQuota
I had a look at your site. Cookbook looks highly customisable. Had you
sold that to me two weeks ago, I'd have bitten you right arm off to try
it out. Right now, I have everything I need ... I think?, and really
want to go down my own avenue. I have bookmarked your website for
future investigation though, thanks for the link. I did try to download
polidyd from the Debian resource, but all I got was upgrade text file so
gave up.
My idea of a quota policy differs in that it is not intended to restrict
traffic from genuine users, I want it solely to mitigate against
compromised accounts. On a average user account, say if 20 messages are
sent within a minute, relay access will be blocked. The
'recipient_count' adds to the total so that could catch people out if
sending to multiple to/cc/bcc., that is why it is all end users can
change values via a php web portal. The option to block or unblock is
there too.
In the pipeline: I will add to the php script to ensure the mail
password can't be the same as the portal password, and the maximum quota
reduces or increases depending on mail and portal password strength.
There are currently 3 sets of message (counter) per (seconds) variables,
each resetting their count after the timeout.
Why would I want to manually block my own account? Well, I for one have
various email accounts. Mailing lists, mates & friends, trusted
business, untrusted business. With the group link, all I need is one
account that is SMTP active to be able to send mail from any of these.
If other accounts are blocked by default, it cuts down the risk of a
compromised pop3 becoming open SMTP. Yeah, I know it won't catch on ;-)
Thanks again,
Mick.
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: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
Hi, P.V.Anthony wrote: Hi, Currently have the following setting in main.cf but I do not know how to create an exception. Because there are some authenticated users that should not be rejected by reject_authenticated_sender_login_mismatch. I'm a noobie to postfix myself but I'll have an educated guess and say 'reject_authenticated_sender_login_mismatch' will REJECT if sender does not match the sasl_username without any exception. If you want to allow an sasl_username to send messages for an non matching sender, then I'm pretty sure you will have to remove it from the smtpd_sender_restrictions. If you only want to grant certain users permission to do this, you could write a script and run it as an external policy in place of that restriction. Postfix will pass the sasl_username and sender details over to your script, which could then veto each request based on the sasl_username. Do you know how to do this? If you don't, I could post a simple PERL example tomorrow. Mick.
Re: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
P.V.Anthony wrote: On 03/08/2015 08:04 PM, Mick wrote: I'm a noobie to postfix myself but I'll have an educated guess and say 'reject_authenticated_sender_login_mismatch' will REJECT if sender does not match the sasl_username without any exception. If you want to allow an sasl_username to send messages for an non matching sender, then I'm pretty sure you will have to remove it from the smtpd_sender_restrictions. If you only want to grant certain users permission to do this, you could write a script and run it as an external policy in place of that restriction. Postfix will pass the sasl_username and sender details over to your script, which could then veto each request based on the sasl_username. Do you know how to do this? If you don't, I could post a > PERL example tomorrow. Thank you very much for replying. The PERL script would be very very very helpful. Thank you again for offering to help. Okay, here it goes. You know I'm a novice right? If anyone on this group thinks this is a no no, please comment. Do read the comments denoted by a # at the start of each line or after ; at the end of the line. It explains what is going on. You don't need the bottom bit of the script, except for interest / debug / future policy ideas and is not intended to be permanent. Copy, paste and save the script below as /etc/postfix/sasluser.p You can save it anywhere and by any name, but for this example it is where I have put it and named it. Once saved, from the command line set permissions, chown nobody:nogroup /etc/postfix/sasluser.p chmod 774 /etc/postfix/sasluser.p Edit the $allowed array entries to show addresses you want to bypass the sasl_username not equalling the sender restriction. Make sure you add a backslash before the '@' symbol. From the command prompt (PuTTY) switch user to nobody su nobody ... type ; perl /etc/postfix/sasluser.p If no errors, you should get a blank line without command prompt, if so type sasl_username= sender=anaddr...@anydomain.sg You should see action=DUNNO printed on the screen, this because as the sasl_username field is empty, we assume this is an external incoming mail which won't match the sender address. DUNNO tells postfix to pass onto the next test by the way. If the sasl_username is different from the sender, but is in $allowed, OR sasl_username not in your $allowed array, but matches the sender address, you should also get a DUNNO. If you test with an sasl_username not in $allowed, with a sender address that doesn't match, you will see action=REJECT + reason ONLY if you can get the above to work as shown under user nobody, considder adding it to postfix. Before doing so, do a postfix reload just to ensure your current config is working sending an email to confirm. Also *DO* backup both of these files before altering. I've been caught out like this before where a previous change I made messed up the setup, but as I hadn't reloaded I didn't notice. It took me hours to work out that the fault wasn't with what I had just done. Hours!!! Anyway, if it passes the tests shown above, add this line to master.cf policy-sg unix - n n - - spawnuser=nobody argv=/etc/postfix/sasluser.p -v Save, postfix reload, send message. If okay, add the following line to main.cf in place of reject_authenticated_sender_login_mismatch check_policy_service unix:private/policy-sg, If it was the last line, remove the comma. Save, postfix reload, send message. If it fails, comment out the line, save, postfix reload, retry sending. Check permissions are correct. The script is very basic, and though functional is only meant only as a starting point. It would be better to read the super users in from a file or database rather than having to alter / add to an array in the script as a typo / semi colon missing in the script = your mailserver SMTP dies by server configuration error. Do test thoroughly first. Just so you know, I only wrote my first PERL script two weeks ago so there is probably a much neater way write it. The purists certainly won't approve it looking more like php than PERL, but I'm still learning. Should all variables be defined by 'my'? Also, this comes with no warranty or liability. There may be typos. If you you use it, it's at your own risk Good luck, Mick. #!/usr/bin/perl # sasluser.p # PERL Script hashed up by Snakebyte # version 0.01 $action="action=DUNNO\n\n"; $sender=""; $sasl_username="\n"; # # SASL users that are allowed to play at God ; # Note : you must add a backslash \(escape character) before '@' else PERL will treat it as an array # While it won't kill the script, it won't work either. $allowed[0]="address1\@mydomain.sg"; $allowed[1]="address2\@mydomain.sg"; # add more by $allo
Re: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
P.V.Anthony wrote: On 03/08/2015 08:04 PM, Mick wrote: I'm a noobie to postfix myself but I'll have an educated guess and say 'reject_authenticated_sender_login_mismatch' will REJECT if sender does not match the sasl_username without any exception. If you want to allow an sasl_username to send messages for an non matching sender, then I'm pretty sure you will have to remove it from the smtpd_sender_restrictions. If you only want to grant certain users permission to do this, you could write a script and run it as an external policy in place of that restriction. Postfix will pass the sasl_username and sender details over to your script, which could then veto each request based on the sasl_username. Do you know how to do this? If you don't, I could post a > PERL example tomorrow. Thank you very much for replying. The PERL script would be very very very helpful. Thank you again for offering to help. Sorry, I forgot about the line wrap on emails. Make sure the # comments on the script stay on the same line. If you want me to PM you the file, let me know. Also make sure that the master.cf line stays on one line too. Mick.
Re: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
Darn formatting! I can't read it myself. Gr! Attached as a text
file. Hope attachments are allowed.
Mick.
#!/usr/bin/perl
# sasluser.p
# PERL Script abused by Snakebyte
# version 0.01
$action="action=DUNNO\n\n";
$sender="";
$sasl_username="\n";
#
# SASL users that are allowed to play at God ;
# Note : you must add a backslash (escape character) before '@' else PERL will
treat it as an array
$allowed[0]="address1\@mydomain.sg";
$allowed[1]="address2\@mydomain.sg";
# Read data passed in by Postfix and grab sender and sasl_username
$a="";
while ($b ne "\n")
{
$b=();
$a.=$b;
if ($b =~ /=/)
{
my ($key, $value) =split (/=/, $b, 2);
if ($key eq "sender") { $sender=$value;}
if ($key eq "sasl_username") { $sasl_username=$value;}
}
}
# --
# Disreguard non SASL authenticated and exit the script.
# If you don't do this, incoming mail will be rejected as sasl_username won't
equal sender
if ($sasl_username eq "\n")
{
print"action=DUNNO\n\n";
exit(0);
}
# ---
# The following line will reject in a similar way that
'reject_authenticated_sender_login_mismatch' would do.
# You can change the text following REJECT to your own custom message
if($sasl_username ne $sender) { $action="action=REJECT Not authorised to send
from this address"; }
# remove linefeed from sasl_username
chomp($sasl_username);
# The following lines loop through each entry of the $allowed array.
# If one of the entries equals the sasl_usename, it will overwrite $action to
"action=DUNNO"
foreach $loop (@allowed)
{
if($loop eq $sasl_username) { $action="action=DUNNO"; }
}
# -
# That's it, now print $action followed by a double line feeds '\n\n'
# That's it, now print $action followed by a double line feeds '\n\n'
print "$action\n\n";
#print "action=DUNNO\n\n";
# If you un-comment the above line, and comment '#'the one above, this script
will not reject anything.
# Ignore the rest but keep exit(0), also...
# If you want to see what other variables the script is receiving from Postfix,
you can log them
# Create a directory of your choice. eg /var/worldwrite. From PuTTY root
privilage command line type
# mkdir /var/worldwrite
# chown nobody:nogroup /var/worldwrite
# chmod 774 /var/worldwrite/
$file="/var/worldwrite/postreport.txt";
my($key, $time_stamp, $now);
$key = lc @_{"client_address"}."/".$attr{"sender"}."/".$attr{"recipient"};
open(my $fh, '>>', $file) or die "X";
print $fh "Start:\n$a\n$action\nEnd\n";
close $fh;
# If all is working okay, I would delete from print "$action\n\n"; to here,
Then delete the worldwrite directory.
# You will only end up with a bloated file, and a directory writable by nobody.
Not good.
exit(0);
Re: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
Viktor Dukhovni wrote: On Mon, Mar 09, 2015 at 03:36:53AM +, Mick wrote: Darn formatting! I can't read it myself. Gr! Attached as a text file. Hope attachments are allowed. I would not deploy this policy script. It requires a new Perl process for each request. That's a rather bad idea. It does not treat the sender address in a case-insensitive manner. I hadn't thought of that. If the mail server busy, a lot of processes could end up running. You could limit the number of processes in master.cf though couldn't you? policy-sg unix - n n - 5 spawn user=nobody argv=/etc/postfix/sasluser.p -v I agree running a service would be better. That's way beyond my limited knowledge though. Policy-spf uses the spawn method. Is that bad too? Good point about case insensitive and one I missed. That could easily be rectified with $sender=lc($value); Same for sasl_username. With 2.11 or later, use check_sasl_access. With 2.10 use socketmap, and with 2.9 or less the tcp table to implement smtpd_sender_login_maps. Whichever you use, make it a persistent service not one process per lookup. Out of interest, have you any links showing working examples? I doubt it be as simple as creating a file, postmapping it to a db file and adding check_sasl_access hash:/etc/postfix/sasl_checks Mick.
Re: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
Viktor Dukhovni wrote: On Mon, Mar 09, 2015 at 04:40:41AM +, Mick wrote: I would not deploy this policy script. It requires a new Perl process for each request. That's a rather bad idea. It does not treat the sender address in a case-insensitive manner. I hadn't thought of that. If the mail server busy, a lot of processes could end up running. You could limit the number of processes in master.cf though couldn't you? I am not talking about concurrency, rather this still costs a Perl invocation per lookup and Perl start-up time is considerable. Ah, I see. Thanks for clarifying the difference. I run a PERL script using spawn to block and group SMTP authenticated senders. Perhaps I should look into making that script run as a daemon to save PERL start up time. Haven't a clue how. I guess that's my free time for the next 3 months booked! The server might easily have problems under load, especially if you limit concurrency too much. True. I agree running a service would be better. That's way beyond my limited knowledge though. That's why I am suggesting a TCP table driver, (or even better SQL). I find the postfix instruction manual a nightmare, and the write-up on smtpd_sender_login_maps is no exception. It contains no examples. The manual is very good at telling you what can be achieved, but is written for those already in the know I fear. I mean no offence to whoever wrote the manual. Out of interest to me, and perhaps P.V. who asked the question in the first place, how would you even start? smtpd_sender_login_maps = exactly what? Can you create a text file containing ; a...@domain.tld, f...@domain.tld, g...@domain.tld b...@domain.tld, f...@domain.tld, h...@domain.tld, j...@domain.tld Where the left column is the sender address and addresses the right are sasl users allowed to send on behalf of that sender. I note a comma can also be white space. Save text file as "/etc/postfix/failure.1" convert to DB file postmap /etc/postfix/failure.1 add to main.cf check_client_access hash:/etc/postfix/failure.1, /etc/init.d/postfix reload Will that work? I may have got that completely wrong. The write-down mentions two further lookups. user@ and @domain. It was at that point my eyes shattered from being glazed over ;-) . With 2.10 use socketmap, and with 2.9 or less the tcp table to implement smtpd_sender_login_maps. Whichever you use, make it a persistent service not one process per lookup. Out of interest, have you any links showing working examples? I doubt it be as simple as creating a file, postmapping it to a db file and adding check_sasl_access hash:/etc/postfix/sasl_checks It's a damn simple protocol, you just need a persistent TCP listener. I'll have to take your word there, but I like the sound of it being simple. I will have to have a go at creating one if I find out enough info to start. However upgrading to Postfix 2.11 which supports check_sasl_access is surely easier. There's even less of a write-up on that so I can't comment. I would sooner add a list of valid senders to the sasl_username list. Seems more logical than the other way around. As far as Postfix 2.11 goes, I'm far too green to wander outside the realms of the regular Debian Wheezy distro where postfix is currently 2.9.6 despite 2.11 is available via backport. I think? I will wait. Thanks for your reply Viktor. Mick.
Re: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
Viktor Dukhovni wrote:
For policy services spawn is fine, because each smtpd(8) connects
once and makes many requests. However, you need to NOT exit until
the connection is closed by the client (i.e. smtpd(8)). Rather
you need to loop reading requests and writing responses until there
are no more requests.
I suspected as much, but when I tried this previously ;
do{
... rest of script
} until (time==0)
I ended up overloading my VPS. On examination, I found Postfix opened a
new policy instance each time, and each instance kept on running after
Postfix had disconnected. I killed the processes manually and did away
with the loop adding the exit(0) clause. All seemed well after that. I
not asking for advice here, but think the socket idea is the best route
to explore next.
The only per-parameter documentation is a reference manual, not a
tutorial. Reference manuals document available features and syntax.
Yeah well, that may be. I have picked up ideas from it, but then had to
look elsewhere. If I want to do something, I tend to ignore any searches
that point to postfix.org as mostly the data there is just not helpful
to me.
Out of interest to me, and perhaps P.V. who asked the question in the first
place, how would you even start? smtpd_sender_login_maps = exactly what?
A list of tables that map envelope sender addresses to lists of
SASL login names. There are many supported table types. These
are referenced from DATABASE_README which has links to per-type
documents.
With SQL tables you can make union queries that neatly solve the
problem at hand. Something along the lines of:
SELECT sasl_login
FROM sender_to_login
WHERE sender_to_login.sender = '%u@%d' -- unlike %s, no partial keys
UNION
SELECT sasl_login
FROM anysender_login
I get the basics of how MySQL works, though UNION and unlike are new to
me. Perhaps -- denotes a comment? I understand how to read and write to
them at least. What are %u, %d an %s? Global postfix variables for
$sasl_user, $domain $sender? You surely could not add ...
smtpd_sender_login_maps =
SELECT sasl_login
FROM sender_to_login
... could you? Clear as mud, but thanks for trying to explain it.
Can you create a text file containing ;
a...@domain.tld, f...@domain.tld, g...@domain.tld
b...@domain.tld, f...@domain.tld, h...@domain.tld, j...@domain.tld
Well, for simple indexed files via postmap, no comma in the key
column. Just optional commas between the RHS elements.
RHS? Royal Horticultural Society ;-)
My employer is running the 2.11 backport on wheezy just fine. This
takes very little effort (I am not the one managing the MTA).
I will wait for the distro. I'm not prepared to take the change of it
going pear shaped. It took me near on 3 months to get it running as I
wanted it. Don't want to ever spend that much time banging my head
against a brick wall again.
As for lookups by SASL user
smtpd_sender_restrictions =
check_sasl_access ,
reject_sender_login_mismatch,
...
Just use "OK" for the RHS of for logins not constrained
to any particular sender address, then they are not contrained by
the mismatch check that follows.
If you've not yet read the Postfix book by Ralf and Patrick, do.
Thanks for your input. All questions asked n this message are
rhetorical, so no reply expected. Without working commented examples I
simply won't get it. I have downloaded "The Postfix Book". Thanks for
that. A real bonus for sure. While a lot has probably changed or been
added since 2005 I'm sure I will get up a better idea of what is going
on from there.
Thanks Viktor, and good luck P.V.
Mick.
Re: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
Hi Viktor, Viktor Dukhovni wrote: On Tue, Mar 10, 2015 at 02:33:08AM +, Mick wrote: You'd have to look at postfix.org documentation I'm afraid. One of: http://www.postfix.org/mysql_table.5.html That was generally enlightening. RHS? Royal Horticultural Society ;-) How about right-hand-side. Doh! Don't want to ever spend that much time banging my head against a brick wall again. It'll get easier, but not if you're unwilling to read the documentation. First read the book, for the concepts, then the docs for the latest up-to-date details. I hope so. It is nice to have the book of postfix. The official documentation contains short examples, not complete system walk-throughs. Enjoy the book. I'm only on chapter 2, page 10 and so far, Stopped to look at http://www.ntp.org seeing as my clock is 39 seconds slow! In for a penny, in for a pound. If I carry on enjoying the book (which I'm sure I will), I may purchase a hard copy, though not at the current Amazon.co.uk price. Many thanks, Mick.
Roleaccount_exceptions
Hello all, I am currently (slowly) working my way through 'The Book of Postfix' and trying to fix problems I didn't know needed fixing. It is a very interesting and highly informative book (so far). Regarding ; check_recipient_access hash:/etc/postfix/roleaccount_exceptions on chapter 8, page 92 / 93. I have created the database using the fqdn for each domain as when using the wild card you could send an email to ab...@anywhereelse.tld. While highly unlikely to be abused, I decided to lock it down anyway. eg. ab...@domain1.tld OK webmas...@domain2.tld OK etc. To comply with RFC2142 and always accept mail destined for abuse or postmaster, the role account exceptions would have to be top of smtpd_recipient_restrictions, but should I bother to comply with mail servers that don't conform to RFC2142 themselves? If I were to move the exception line to below unauth_destination, it would seem a bit pointless having the line there at all as the message would have already passed most of the tests. smtpd_recipient_restrictions = ?#check_recipient_access hash:/etc/postfix/roleaccount_exceptions, reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unknown_client_hostname, reject_invalid_helo_hostname, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, ?#check_recipient_access hash:/etc/postfix/roleaccount_exceptions, reject_non_fqdn_hostname, reject_invalid_hostname, #check_helo_access hash:/etc/postfix/helo_checks, reject_unverified_sender, check_policy_service unix:private/policy-spf If anyone has any thoughts on this, they will be gladly received. Many thanks, Mick.
Re: Roleaccount_exceptions
Viktor Dukhovni wrote: On Tue, Mar 17, 2015 at 05:11:33PM +, Mick wrote: To comply with RFC2142 and always accept mail destined for abuse or postmaster, the role account exceptions would have to be top of smtpd_recipient_restrictions, but should I bother to comply with mail servers that don't conform to RFC2142 themselves? If I were to move the exception line to below unauth_destination, it would seem a bit pointless having the line there at all as the message would have already passed most of the tests. The point is to exempt "postmaster" from anti-UCE rules, allowing remote sites to report problems when they are blocked in error. This is not an exemption from anti-relay rules. I see. That explains why the Book of Postfix shows the example after 'reject_unauth_destination' and why 'abuse@' and 'postmaster@' wild card works when placed there. Therefore, in Postfix <= 2.9, this goes after "reject_unauth_destination", but before RBLs and the like. With Postfix >= 2.10, if you're using "smtpd_relay_restrictions", you can order the recipient restrictions however you like, and perhaps put the "postmaster" whitelist first. I on 2.9x as Debian wheezy has not yet upgraded. I know it can easily be done via backport, but I won't. smtpd_recipient_restrictions = ?#check_recipient_access hash:/etc/postfix/roleaccount_exceptions, .. check_policy_service unix:private/policy-spf If anyone has any thoughts on this, they will be gladly received. Most your reject rules are in the wrong place. Consider moving your outbound esers to port 587 (for MUAs and null-clients) or a dedicated outbound MTA when relaying for internal MTAs. Did I mention, I don't know my backport from my elbow ;-( . Currently my limited users use port 445 or 587. 25 is available but so many ISPs block it making it a waste of time for MUA use, especially on a portable device. I know spf is not widely liked, but I implement it in full so if the MU uses their own ISPs port 25, chances are message won't get through in any case. I haven't a clue about a running dedicated MTA for 445 and 587, and I'm not asking how to do this yet. I have another 300 pages of the book to get through first. Once I've got the full picture, I may try running another instance of postfix as I'm thinking you are suggesting. Otherwise: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_recipient_access hash:/etc/postfix/roleaccount_exceptions, reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unknown_sender_domain, #reject_unknown_recipient_domain, -- port 587 only #reject_unknown_client_hostname, -- too strict for most sites reject_invalid_helo_hostname, reject_unauth_pipelining, reject_non_fqdn_hostname, reject_invalid_hostname, #check_helo_access hash:/etc/postfix/helo_checks, reject_unverified_sender, check_policy_service unix:private/policy-spf with any further adjustment based on further reading and matching settings to your needs. Thank you for the above. I will adopt your revised restriction order. Where I am in the book, it shows ; reject_non_fqdn_recipient reject_non_fqdn_sender reject_unknown_sender_domain reject_unknown_recipient_domain above 'permit_mynetworks'. I wrongly assumed having the above as is shown, this would prevent any of the above attempting to log into SMTP. BUT, since running a test log of SMTP parameters passed to a Perl script, I see that this has already taken place before we get to the restrictions. I'm guessing now that 'permit_sasl_authenticated' provides a 'DUNNO' on a pass meaning other rules below / to the right still get checked? I am in your debt for pointing me towards the'Book of Postfix'. Instead of having a constant headache due to banging my head against a search engine brick wall, things are slowly starting to make sense. Long way to go yet, but at least I'm crawling now. Thanks, Mick.
Greylisting with reject_unverified_sender negative cache
Good morning, I have found 'reject_unverified_sender' superb at reducing the number of SPAM messages getting though. I've set up a whitelist for those few trusted senders or domains where their dopey mail servers' don't comply. I do have a minor problem with mail servers that do comply, but apply greylisting. Originally I omitted 'address_verify_negative_cache =no' from main.cf. This defaults to 'yes' and sender verification failures were cached saving a constantly chattering probe relay. Unfortunately it would appear that this method also caches temporary errors too (those also being a fail), so when I receive a 471 as part of a greylisting policy, that message won't be delivered. Postfix will reject when remote server re-attempts to deliver relying on its cache from the first attempt rather than sending another dummy message. I have now set the negative cache to 'no' meaning a retry for every incoming message that hasn't passed address verification. It is either that or adding all domain that use greylisting to the whitelist. Does anyone know if there's a way to exempt / prevent 471 (or other temporary reject codes) from being cached? Thanks, Mick.
Re: Greylisting with reject_unverified_sender negative cache
Noel Jones wrote: Does anyone know if there's a way to exempt / prevent 471 (or other temporary reject codes) from being cached? The best solution is to not attempt to verify external senders. Many sites will consider this abuse and blacklist you. Thanks for your comment Noel. I will bear that in mind. Mick.
Postscreen - adding a custom policy
Does anyone know if there's a way to add a custom perl policy to Postscreen (tests carried out before the 220 SMTP server greeting)? It doesn't look as though this is allowed. Best regards, Mick.
Re: Postscreen - adding a custom policy
Wietse Venema wrote: Mick: Does anyone know if there's a way to add a custom perl policy to Postscreen (tests carried out before the 220 SMTP server greeting)? It doesn't look as though this is allowed. Indeed. Use postscreen to eliminate *most* spambots as cheaply as possible. Use smtpd policies for the rest. Wietse It's a shame, but not the end of the world. Thank you for confirming. Mick.
Re: pishing from ME
On 22/03/2019 23:19, Christian Schmitz wrote: Hi everyone: I have a small mail server with fewer emails account, The server is: Opensuse/Postfix/apache Today i receive a pishing email Words more or less say that i was hacked, that he know my passwords blah blah blah and i must pay on bit_coins. The email content is 100% pishing and no real hacking because sevral reasons: list@XXX was only created for mailing lists and no other usage I have not webcam The hacker not used SASL to get real use of my account. For forums/website registrations i use mailinator.com The curious is that email seem at first time writed from me to myself. If my email is list@xxx the emails say to be list@xxx So i start a little investigation on LOG file, and all seem that the "hacker" do not know the passwords. Because the emailer has no SASL autenticated, so the "hacker"simply spoof the FROM field: 1)First question: how i can filter the spoofed emails. In other words, if the sender is not authorized to send list@xxx because this emai is managed by ME Hi Christian, If you want to stop your domain(s) being spoofed you can try the following, but note that ; 1) I've blocked authentication on Port 25 (smptd). If you use Port 25 for authentication, don't read on :- as this won't work for you (unless someone here knows different). 2) This will not stop you receiving opportunistic blackmail messages as they just as often use compromised accounts without spoofing your email address or domain. The below will only stop you getting messages pertaining to be from yourself from the outside world. Add a line to main.cf (if line and file doesn't already exist) ; header_checks = pcre:/etc/postfix/header_checks Create the file 'header_checks' and add following lines to file ; /^From:.*@yourPrimarydomain.tld/ REJECT Shut the door on your way out!. /^From:.*@yourSecondarydomainIfYouHaveOne.tld/ REJECT Get lost # (or whatever polite message you want to send) DON'T STOP NOW : Leaving the above as it is will have the undesired effect of also rejecting authenticated mail, so disable header checks from submission (port 587) and smtps (port 465) in 'master.cf' by adding an override switch under those sections. -o receive_override_options=no_header_body_checks' If you use sendmail, mail or mailx add the override to pickup as well. I'm only a Postfix novice+, so please someone put me right if I'm wrong with the above. I have received many of these threats. I've even got one in Chinese (or Japanese or something like that)! Most messages contained passwords I'd used a long long time ago, but others used passwords in recent failed attempts at auth. I think it must have proved fruitful as more people seem to be in on the act now. First message I got was very well written, sent from an IP in Russia, sender claiming he was Romanian and not to be messed with. In the later offerings, the spelling and grammar seriously deteriorated. Best wishes, Mick. 2)Seccond question :how i can adjust the sender policy to block soft fail SPF? Thanks you all. Best Regards. Christian Schmitz Info extra 1: LOG: /var/log/mail connect from mmu.ac.ug[62.75.235.12] Anonymous TLS connection established from mmu.ac.ug[62.75.235.12]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) : SPF softfail (Mechanism '~all' matched): Envelope-from: d...@mmu.ac.ug : handler sender_policy_framework: is decisive. : Policy action=PREPEND Received-SPF: softfail (mmu.ac.ug: Sender is not authorized by default to use 'd...@mmu.ac.ug' in 'mfrom' identity, however domain is not currently prepared for false failures (mechanism '~all' matched)) receiver=schweb; identity=mailfrom; envelope-from="d...@mmu.ac.ug"; helo=xray144.theg7.com; client-ip=62.75.235.12 client=mmu.ac.ug[62.75.235.12] message-id=<5s5jp2.2trzrx165hrq...@mail.mmu.ac.ug> from=, size=228789, nrcpt=1 (queue active) disconnect from mmu.ac.ug[62.75.235.12] to=, relay=virtual, delay=8, delays=6.9/0.02/0/1, dsn=2.0.0, status=sent (delivered to maildir) removed Info extra 2: when i send a email i get the log of sasl autentication: client=unknown[192.168.XX.XX], sasl_method=LOGIN, sasl_username=YYY@XXX Info extra 3: received email header Return-Path: X-Original-To: list@XXX Delivered-To: list@XXX Received-SPF: softfail (mmu.ac.ug: Sender is not authorized by default to use 'd...@mmu.ac.ug' in 'mfrom' identity, however domain is not currently prepared for false failures (mechanism '~all' matched)) receiver=schweb; identity=mailfrom; envelope-from="d...@mmu.ac.ug"; helo=xray144.theg7.com; client-ip=62.75.235.12 Received: from xray144.theg7.com (mmu.ac.ug [62.75.235.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (N
Re: spam from own email address
On 23/04/2019 18:34, Bill Cole wrote:
On 23 Apr 2019, at 11:46, John Peach wrote:
On 4/23/19 11:39 AM, Paul wrote:
Yes I agree with Kevin here, the best solution to this problem is an
spf record set to reject mail from any ip that’s not in your allowed
list of ips for your domain. Forging a from address is very easy and
is one of the main purposes of why spf was created.
There is no need to go to those lengths - assuming that all your own
email is being submitted over port 587, include -o
receive_override_options=no_header_body_checks in the master.cf entry
for submission and use a PCRE header checks file for port 25.
/^From:.*\@example\.com/REJECT
So you don't want to accept messages you or anyone else in your domain
posts to a mailing list such as this one?
Seems risky...
I hadn't thought of that, so thanks Bill for pointing it out.
To the top of my pcre header_checks file, I have added ;
/^List-ID:.*Postfix users /OK
I think this is destined to fail though???
header_checks.5' states :
'Each message header or message body line is compared against a
list of patterns.'
Because "From:" will come before "List-Id:" in the message body, a
"From:" containing my domain should match a REJECT line before an OK
from List-ID.
However, further down header_checks.5 under 'Table search Order' it says:
' When a pattern is found that matches the input line, the
corresponding action is executed and then the next input line is
inspected.'
So if the action is executed, goodbye message, but if header checks
continues to check the following lines it will find an OK by List-Id.
I suspect that I will not receive a copy this message, but don't know
for sure. One way to find out {SEND}.
Best wishes,
Mick.
Re: spam from own email address
On 23/04/2019 18:34, Bill Cole wrote: On 23 Apr 2019, at 11:46, John Peach wrote: On 4/23/19 11:39 AM, Paul wrote: Yes I agree with Kevin here, the best solution to this problem is an spf record set to reject mail from any ip that’s not in your allowed list of ips for your domain. Forging a from address is very easy and is one of the main purposes of why spf was created. There is no need to go to those lengths - assuming that all your own email is being submitted over port 587, include -o receive_override_options=no_header_body_checks in the master.cf entry for submission and use a PCRE header checks file for port 25. /^From:.*\@example\.com/REJECT So you don't want to accept messages you or anyone else in your domain posts to a mailing list such as this one? Seems risky... As per B. Reino's suggestion of header check white list, is there any reason the following main.cf config should not be used ? header_checks = pcre:/etc/postfix/header_checks_pass pcre:/etc/postfix/header_checks_fail Best wishes, Mick.
Re: spam from own email address
On 24/04/2019 21:51, Bill Cole wrote: On 24 Apr 2019, at 16:04, Mick wrote: On 23/04/2019 18:34, Bill Cole wrote: On 23 Apr 2019, at 11:46, John Peach wrote: On 4/23/19 11:39 AM, Paul wrote: Yes I agree with Kevin here, the best solution to this problem is an spf record set to reject mail from any ip that’s not in your allowed list of ips for your domain. Forging a from address is very easy and is one of the main purposes of why spf was created. There is no need to go to those lengths - assuming that all your own email is being submitted over port 587, include -o receive_override_options=no_header_body_checks in the master.cf entry for submission and use a PCRE header checks file for port 25. /^From:.*\@example\.com/REJECT So you don't want to accept messages you or anyone else in your domain posts to a mailing list such as this one? Seems risky... As per B. Reino's suggestion of header check white list, is there any reason the following main.cf config should not be used ? header_checks = pcre:/etc/postfix/header_checks_pass pcre:/etc/postfix/header_checks_fail Yes: it is a generally bad idea to use header_checks to whitelist anything. Thanks Bill. For the details on why, see the documentation in the header_checks man page and BUILTIN_FILTER_README. If you want *GOOD* filtering, use a milter or SMTP proxy filter. I thought header checks were carried out after all the other smtp restrictions had passed therefore I didn't see the harm in an 'OK' for a message header at this stage. That's why it's good to ask. I will the remove the white list and have thorough read to weigh up the cons and pros before deciding what to do next. The purpose of my white list was to avoid Postfix-users List-Id: (and other lists) being kicked out due to the sender using my domain in the from field, but it failed and my last message was rejected in any case. If there is a simple pre-queue filter to be had that could block forged message header From:, but allow when selected list IDs come knocking, I'd give it a try. I did try Amavis and Spamassassin, but they brought my limited resource VPS to its knees with 98% memory usage. Thanks again, Mick.
Re: spam from own email address
On 25/04/2019 00:21, Wietse Venema wrote: Mick: I thought header checks were carried out after all the other smtp restrictions had passed therefore I didn't see the harm in an 'OK' for a message header at this stage. Correct, but the OK action applies only to that header, not the message. Thanks Wietse, that makes sense now. I think you're saying : Regardless of whether the first file (white list) matched an OK from List-Id:, the second file (black list) would still be checked. As the 'OK' only applied the List-Id: header, if the second header checks file matches a reject pattern other than List-ID, message will be rejected. The Postfix 3.2 PASS action applies to the message, but remains unused when a REJECT pattern is matched earlier. PASS is something I shall look forward to in the next couple of years. For now I'm on 3.1.9 (Debian stable). I don't suppose there's a way to read the status List-Id (possibly matched and OK'd in the first pass - white list) while reading the From in the second pass (black list)? I think not, but asking just to rule it out. Thanks for your explanation as to how it works. Best wishes, Mick. Wietse
Re: Why no List-ID header in the postfix-users posts?
On 12/02/2017 00:53, Josh Good wrote: Hello. I'm trying to set up a new procmail recipe to automatically file this mailing list's traffic into its own folder - because my old procmail recipe (filtering by TO: postfix-users@postfix.org) has proven to be not 100% effective (somehow, some posts to the mailing list are addressed to postfix-us...@cloud9.net instead, and are landing directly into my Inbox, where I can miss them or directly delete them as they are not subject-tagged). Suggestion : When Sender is 'owner-postfix-us...@postfix.org' move message to 'Postfix' The above works for me every time. Best wishes, Mick.
