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.
Specific smtp_(body|header)_checks for different domains
Hi, I have defined two smtpd_restriction_classes for two different domains. I'm using these classes for integration with smtpd_recipient_restrictions. At this time, I'd like to define custom smtp_body_checks and smtp_header_checks for each of these domains (or classes), so any outgoing e-mail will go through a different header or body table depending on which domain it is. I didn't find any restriction to define inside smtpd_(client|sender|recipient)_restrictions that I could use to achieve it. Is it even possible to do this? Thanks. Nicolás
Re: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
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. -- P.V.Anthony smime.p7s Description: S/MIME Cryptographic Signature
Re: Specific smtp_(body|header)_checks for different domains
Nicol?s: > Hi, > > I have defined two smtpd_restriction_classes for two different domains. > I'm using these classes for integration with > smtpd_recipient_restrictions. At this time, I'd like to define custom > smtp_body_checks and smtp_header_checks for each of these domains (or > classes), so any outgoing e-mail will go through a different header or > body table depending on which domain it is. > > I didn't find any restriction to define inside > smtpd_(client|sender|recipient)_restrictions that I could use to achieve it. > > Is it even possible to do this? header/body_checks are not spam filters. To support per-domain spam filter policies use Amavisd. Domain-dependent header/body_checks require different IP addresses, so that you can configure different smtpd entries in master.cf with different cleanup_service_name entries. 1,2.3.4 ... smtpd -o cleanup_service_name=cleanup_1.2.3.4 1,2.3.5 ... smtpd -o cleanup_service_name=cleanup_1.2.3.5 cleanup_1.2.3.4 .. -o header_checks=/etc/postfix/header_checks_1.2.3.4 cleanup_1.2.3.5 .. -o header_checks=/etc/postfix/header_checks_1.2.3.5 See also http://www.postfix.org/BUILTIN_FILTER_README.html#mx_submission for similar examples. Wietse
on compiling: does turning on dynamic loading of database clients save on memory too?
Dynamic linking results in smaller binaries ( http://www.postfix.org/INSTALL.html#shared_enable), and memory savings, but what about dynamic loading of database clients? Does this work the same way, or is this something different from dynamic linking? It's not altogether clear to me. What does it mean to dynamically load a client? http://www.postfix.org/INSTALL.html#dynamicmaps_enable only mentions that 'Dynamic loading is useful when you distribute or install pre-compiled Postfix packages.' What if I'm not planning to distribute? Are there any other reasons (like as mentioned, saving on memory) I would want to enable dynamic loading of database clients when compiling? thanks, -jf -- He who settles on the idea of the intelligent man as a static entity only shows himself to be a fool. Mensan / Full-Stack Technical Polymath / System Administrator 12 years over the entire web stack: Performance, Sysadmin, Ruby and Frontend
Re: Exception for authenticated user when using reject_authenticated_sender_login_mismatch.
On Sat, Mar 07, 2015 at 05:59:23PM +0800, P.V.Anthony wrote:
> How to create an exception to reject_authenticated_sender_login_mismatch in
> main.cf.
Postfix 2.11 or later:
http://www.postfix.org/postconf.5.html#check_sasl_access
Presumably some SASL users need to be able to send from *any* email
address, or at least too many to enumerate.
> smtpd_sender_restrictions = reject_unknown_sender_domain,
> check_sender_access hash:/etc/postfix/allowed_user,
> reject_authenticated_sender_login_mismatch,
> check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf
> -- end -
>
> In the file /etc/postfix/allowed_user it is as follows.
>
> n...@example.com OK
>
> Is there some other check__access that checks the authenticated user?
With earlier releases, if this user can send from any email address,
EXCEPT email addresses reserved for other SASL users, then just:
http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps
indexed = ${default_database_type}:${config_directory}/
smtpd_sender_login_maps =
${indexed}sender_login, static:n...@example.com
Otherwise, Postfix >= 2.10, go with "socketmap" (superior to "tcp"
table alternative below):
http://www.postfix.org/socketmap_table.5.html
and for every sender address return:
,
For Postfix <= 2.9, use "tcp" tables.
http://www.postfix.org/tcp_table.5.html
--
Viktor.
Re: on compiling: does turning on dynamic loading of database clients save on memory too?
On Mon, Mar 09, 2015 at 03:36:42AM +0800, Jeffrey 'jf' Lim wrote: > Dynamic linking results in smaller binaries ( > http://www.postfix.org/INSTALL.html#shared_enable), and memory savings, but > what about dynamic loading of database clients? Does this work the same > way, or is this something different from dynamic linking? It's not > altogether clear to me. What does it mean to dynamically load a client? > > http://www.postfix.org/INSTALL.html#dynamicmaps_enable only mentions that > 'Dynamic loading is useful when you distribute or install pre-compiled > Postfix packages.' What if I'm not planning to distribute? Are there any > other reasons (like as mentioned, saving on memory) I would want to enable > dynamic loading of database clients when compiling? The memory savings are not generally significant, because the code (text segment) of each executable is only loaded once and shared by all instances of that running executable. So whether you're running one smtpd(8) process or five hundred, the memory consumed by the code is the same. Modern systems have ludicrous amounts of RAM the modest savings in memory footprint for a system running zero or more of each of: master pickup qmgr trivial-rewrite smtpd cleanup smtp local virtual are negligible. Yes with shared libraries there is more sharing going on, with the above executables smaller and some more code loaded just once, but this hardly matters. The benefit of dynamic loading of table drivers is simplified dependency management for O/S release engineers. They can ship a system with an MTA without having to bundle support for every database client library under the sun and the dependencies of those libraries, ... There is little to no benefit to users building their own Postfix from source. -- Viktor.
Re: on compiling: does turning on dynamic loading of database clients save on memory too?
On Mon, Mar 9, 2015 at 3:55 AM, Viktor Dukhovni wrote: > On Mon, Mar 09, 2015 at 03:36:42AM +0800, Jeffrey 'jf' Lim wrote: > > > Dynamic linking results in smaller binaries ( > > http://www.postfix.org/INSTALL.html#shared_enable), and memory savings, > but > > what about dynamic loading of database clients? Does this work the same > > way, or is this something different from dynamic linking? It's not > > altogether clear to me. What does it mean to dynamically load a client? > > > > http://www.postfix.org/INSTALL.html#dynamicmaps_enable only mentions > that > > 'Dynamic loading is useful when you distribute or install pre-compiled > > Postfix packages.' What if I'm not planning to distribute? Are there any > > other reasons (like as mentioned, saving on memory) I would want to > enable > > dynamic loading of database clients when compiling? > > The memory savings are not generally significant, because the code > (text segment) of each executable is only loaded once and shared > by all instances of that running executable. So whether you're > running one smtpd(8) process or five hundred, the memory consumed > by the code is the same. > > Modern systems have ludicrous amounts of RAM the modest savings in > memory footprint for a system running zero or more of each of: > > master > pickup > qmgr > trivial-rewrite > smtpd > cleanup > smtp > local > virtual > > are negligible. Yes with shared libraries there is more sharing > going on, with the above executables smaller and some more code > loaded just once, but this hardly matters. > > The benefit of dynamic loading of table drivers is simplified > dependency management for O/S release engineers. They can ship a > system with an MTA without having to bundle support for every > database client library under the sun and the dependencies of those > libraries, ... > > got it. Thanks! > There is little to no benefit to users building their own Postfix > from source. > > Yeah, I get it. Easier to use what's available if possible. My problem is that what's available is too old. But that's another story altogether. Thanks! -jf -- He who settles on the idea of the intelligent man as a static entity only shows himself to be a fool. Mensan / Full-Stack Technical Polymath / System Administrator 12 years over the entire web stack: Performance, Sysadmin, Ruby and Frontend
Re: on compiling: does turning on dynamic loading of database clients save on memory too?
On Mon, Mar 09, 2015 at 04:07:17AM +0800, Jeffrey 'jf' Lim wrote: > > The benefit of dynamic loading of table drivers is simplified > > dependency management for O/S release engineers. They can ship a > > system with an MTA without having to bundle support for every > > database client library under the sun and the dependencies of those > > libraries, ... > > got it. Thanks! > > > There is little to no benefit to users building their own Postfix > > from source. > > Yeah, I get it. Easier to use what's available if possible. My problem is > that what's available is too old. But that's another story altogether. > Thanks! Note, I was not saying there's no point in building your own Postfix, rather I was saying that when doing so, dynamicmaps offers little to no advantage. You decide what tables to compile-in. -- Viktor.
Reversing order when mail is local (not relayed)?
Currently my master.cf looks like this: 192.168.1.10:25 inet n - - - - smtpd -o myhostname=dns1.sebbe.eu -o smtpd_tls_cert_file=/etc/postfix/dns1.crt -o content_filter=smtp-downconvert:127.0.0.1:10025 192.168.1.10:26 inet n - - - - smtpd -o myhostname=dns2.sebbe.eu -o smtpd_tls_cert_file=/etc/postfix/dns2.crt -o content_filter=smtp-downconvert:127.0.0.1:10025 192.168.1.10:465 inet n - - - - smtpd -o myhostname=dns1.sebbe.eu -o smtpd_tls_cert_file=/etc/postfix/dns1.crt -o smtpd_tls_wrappermode=yes -o content_filter=smtp-downconvert:127.0.0.1:10025 192.168.1.10:466 inet n - - - - smtpd -o myhostname=dns2.sebbe.eu -o smtpd_tls_cert_file=/etc/postfix/dns2.crt -o smtpd_tls_wrappermode=yes -o content_filter=smtp-downconvert:127.0.0.1:10025 2001:470:28:1c:1:10:0:1:25 inet n - - - - smtpd -o myhostname=dns1.sebbe.eu -o smtpd_tls_cert_file=/etc/postfix/dns1.crt -o content_filter=smtp-downconvert:127.0.0.1:10025 2001:470:28:1c:1:10:0:2:25 inet n - - - - smtpd -o myhostname=dns2.sebbe.eu -o smtpd_tls_cert_file=/etc/postfix/dns2.crt -o content_filter=smtp-downconvert:127.0.0.1:10025 2001:470:28:1c:1:10:0:1:465 inet n - - - - smtpd -o myhostname=dns1.sebbe.eu -o smtpd_tls_cert_file=/etc/postfix/dns1.crt -o smtpd_tls_wrappermode=yes -o content_filter=smtp-downconvert:127.0.0.1:10025 2001:470:28:1c:1:10:0:2:465 inet n - - - - smtpd -o myhostname=dns2.sebbe.eu -o smtpd_tls_cert_file=/etc/postfix/dns2.crt -o smtpd_tls_wrappermode=yes -o content_filter=smtp-downconvert:127.0.0.1:10025 smtp-downconvert unix y - - - - smtp -o smtp_send_xforward_command=yes 127.0.0.1:10026 inet n - - - - smtpd -o smtpd_authorized_xforward_hosts=127.0.0.1 -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_relay_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_milters=inet:localhost:8991,inet:localhost:8891 -o non_smtpd_milters=inet:localhost:8991,inet:localhost:8891 Now I want to do this: When mail is *relayed* through any of the eigth servers (non-local mail) – I want to run as is, where the mail is run through 10025 first (djigzo S/MIME gateway) and then through 10026 and then through the milters 8991 and 8891. (so the djigzo gateway can modify content BEFORE mail is signed by the 8891 milter – because the DKIM signature will be made invalid if djigzo encrypts or signs a mail) When mail is NOT relayed, eg is targeted at any local users, I want to FIRST pass it through the 8891 milter, THEN pass it through 10025 –> 10026. (so the djigzo gateway can modify content AFTER the 8891 milter has verified the DKIM signature – because modification will invalidate the signature if the DKIM signature is verified after decryption or verification). The 8991 milter only does hashcash signing and has no effect on non-relayed mail anyways. How can this be accomplished? smime.p7s Description: S/MIME Cryptographic Signature
always_bcc
Does Always BCC bcc all incoming AND outgoing mail? Is there a way to have it BCC only incoming mail? -- It's against my programming to impersonate a deity.
Re: always_bcc
On Sun, Mar 08, 2015 at 08:09:51PM -0600, @lbutlr wrote: > Does Always BCC bcc all incoming AND outgoing mail? > > Is there a way to have it BCC only incoming mail? Postfix has no notion of "incoming mail". All mail comes in (to the queue) and then it goes out. To apply different rewriting rules and/or controls to mail from different sources set up separate Postfix instances to handle email from distinct sources or even separate MTA physical or virtual machines. -- Viktor.
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 $allowed[2]="..."; $allowed[3]="..."; and so on # Read data passed in by Postfix and grab sender and sasl_username $a=""; # This is only needed while / if you include the end of the sc
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.
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. 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. -- Viktor.
Re: Reversing order when mail is local (not relayed)?
On Mon, Mar 09, 2015 at 12:43:14AM +0100, Sebastian Nielsen wrote: > How can this be accomplished? Don't mix the relay and inbound services in the same Postfix. Setup one Postfix to receive inbound mail from outside. Setup another Postfix to handle outbound mail from inside. For extra brownie points, arrange for bounces from either (bounces follow the reverse path) to be relayed to the other, by adding transport entries that shunt inbound mail from the outbound MTA to the inbound MTA and the converse. This helps with DKIM signing and any other direction-dependent content processing. http://www.postfix.org/MULTI_INSTANCE_README.html (this also separates local submission on the MTA into a separate null-client instance, which is also a good idea if I do say so myself). -- Viktor.
Re: Reversing order when mail is local (not relayed)?
Solved it already. Did split up the OpenDKIM process into 2 instances, one running as verifier, placed before any content modification, and one running as signer, placed after any content modification. I also moved the SPF signature validator to the instance before content modification. That was not because SPF signatures has with content to do, rather it was because the old SPF signature validator I had, was a policy script checking against MAIL FROM. The new SPF signature validator checks against the "From:" MIME header, which raises security, but milters do not get access to the XFORWARD client IP, thus I had to move the milter to "the front" so it sees the real IP. -Ursprungligt meddelande- From: Viktor Dukhovni Sent: Monday, March 09, 2015 5:15 AM To: postfix-users@postfix.org Subject: Re: Reversing order when mail is local (not relayed)? On Mon, Mar 09, 2015 at 12:43:14AM +0100, Sebastian Nielsen wrote: How can this be accomplished? Don't mix the relay and inbound services in the same Postfix. Setup one Postfix to receive inbound mail from outside. Setup another Postfix to handle outbound mail from inside. For extra brownie points, arrange for bounces from either (bounces follow the reverse path) to be relayed to the other, by adding transport entries that shunt inbound mail from the outbound MTA to the inbound MTA and the converse. This helps with DKIM signing and any other direction-dependent content processing. http://www.postfix.org/MULTI_INSTANCE_README.html (this also separates local submission on the MTA into a separate null-client instance, which is also a good idea if I do say so myself). -- Viktor. smime.p7s Description: S/MIME Cryptographic Signature
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.
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. The server might easily have problems under load, especially if you limit concurrency too much. > 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). > >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. However upgrading to Postfix 2.11 which supports check_sasl_access is surely easier. -- Viktor.
Re: Reversing order when mail is local (not relayed)?
On Mon, Mar 09, 2015 at 05:27:21AM +0100, Sebastian Nielsen wrote: > Did split up the OpenDKIM process into 2 instances, one running as verifier, > placed before any content modification, and one running as signer, placed > after any content modification. > I also moved the SPF signature validator to the instance before content > modification. That was not because SPF signatures has with content to do, > rather it was because the old SPF signature validator I had, was a policy > script checking against MAIL FROM. The new SPF signature validator checks > against the "From:" MIME header, which raises security, but milters do not > get access to the XFORWARD client IP, thus I had to move the milter to "the > front" so it sees the real IP. SPF is not a signature protocol. SPF is *supposed* to check the envelope sender and NOT the author. Applying spf to message headers was SenderID which inteoperated with mailing lists by matching "Sender" when present. With rampant misuse of SPF records, I neither publish nor check SPF records. Good luck. -- Viktor.
Re: Reversing order when mail is local (not relayed)?
I understand. What I do with the SPF signature checker, is to unconditionally add a header that looks like this: X-SPF-Signature: none (dukhovni.org: No applicable sender policy available) receiver=server-desktop; identity=mailfrom; envelope-from="postfix-us...@dukhovni.org"; client-ip="2604:8d00:0:1::4" The idea behind this, is that the MUA, should be able to mark the email as guranteed genuine and safe to the end user, if a mail is: (SPF signed OR S/MIME Signed OR DKIM Signed), but if ANY is forged, then the whole mail is marked as forged. Thus, if a validly signed email, regardless of method (SPF, S/MIME or DKIM) comes from my bank, I know that I can safely visit any links and enter any personal data. I think you should really publish a SPF record. Especially if you have a certain reputation that would make you target for email forgeries. Then its up to email receivers how they want to use the record. So I dont reject any email based on any signature failures, rather I use the signatures in a positive fashion to mark the email as extra validated when they pass one signature method. -Ursprungligt meddelande- From: Viktor Dukhovni Sent: Monday, March 09, 2015 6:58 AM To: postfix-users@postfix.org Subject: Re: Reversing order when mail is local (not relayed)? On Mon, Mar 09, 2015 at 05:27:21AM +0100, Sebastian Nielsen wrote: Did split up the OpenDKIM process into 2 instances, one running as verifier, placed before any content modification, and one running as signer, placed after any content modification. I also moved the SPF signature validator to the instance before content modification. That was not because SPF signatures has with content to do, rather it was because the old SPF signature validator I had, was a policy script checking against MAIL FROM. The new SPF signature validator checks against the "From:" MIME header, which raises security, but milters do not get access to the XFORWARD client IP, thus I had to move the milter to "the front" so it sees the real IP. SPF is not a signature protocol. SPF is *supposed* to check the envelope sender and NOT the author. Applying spf to message headers was SenderID which inteoperated with mailing lists by matching "Sender" when present. With rampant misuse of SPF records, I neither publish nor check SPF records. Good luck. -- Viktor. smime.p7s Description: S/MIME Cryptographic Signature
Re: Reversing order when mail is local (not relayed)?
On Mon, Mar 09, 2015 at 07:16:59AM +0100, Sebastian Nielsen wrote: > I understand. What I do with the SPF signature checker, is to > unconditionally add a header that looks like this: > X-SPF-Signature: none (dukhovni.org: No applicable sender policy available) > receiver=server-desktop; identity=mailfrom; > envelope-from="postfix-us...@dukhovni.org"; client-ip="2604:8d00:0:1::4" In this case, since you got the email not from, but from the Postfix users list, the "envelope-from" is not my address. Rather it is: owner-postfix-us...@postfix.org > The idea behind this, is that the MUA, should be able to mark the email as > guranteed genuine and safe to the end user, if a mail is: > (SPF signed OR S/MIME Signed OR DKIM Signed), but if ANY is forged, then the > whole mail is marked as forged. Except that SPF does not "sign" email it just checks a list of authorized relays. This check fails when email is forwarded, and forwarding of mail is not forgery. When using SPF and DKIM, the recommended practice is to accept email as genuine if either DKIM or SPF pass, even if the other fails. > Thus, if a validly signed email, regardless of method (SPF, S/MIME or DKIM) > comes from my bank, I know that I can safely visit any links and enter any > personal data. Even better, never click on links in email and enter personal data. Don't get lulled into a false sense of security. Large corporations outsource email communications to all sorts of third parties, and list them in their SPF and DKIM records. -- Viktor.
