Reporting redirects - API call similar to sendmail -bv
I suspect I know the answer - but it doesn't hurt to ask. I have a Postfix config set up which uses 4 mysql maps to create role based emails for a (large) set of clubs. The rules in the SQL aren't stunningly complex but they are non-trivial. I'd prefer not to implement them in several places, because I know they will get out of sync if that is done. They handle cases like there is a temporary redirect in place for the role, the club post isn't filled so send to the secretary, the new committee takes over so all the roles shuffled around because of year change. Several posts have multiple aliases. Some clubs haven't signed up to the system. You can imagine the sort of thing that apply if you've ever been in a club with a formal constitution. Two of the maps check addresses for validity of an address (e.g. role@domain are valid role and valid domain). There are two types of club, one map each. Two of the maps transfer us from virtual address to final delivery address (secretary@domain - sim...@zynet.net). Again the same division, two types of club, one map each. The main reason to keep these separate for types of club is simplicity of thinking, Postfix doesn't care, and indeed does slightly more work because there are 4 maps instead of 2. I now want to produce some reporting based on these mappings. The output I want initially is what sendmail -bv was invented for, the mapping from role email to actual email. I'm assuming from the sendmail -bv discussion in archives that Postfix doesn't allow me to make this query, in general, without simply feeding an email through the system? e.g.. sendmail -bv works in exactly that way, presumably for similar reasons? Or is there an exposed API somewhere that answers the same question? Otherwise I suspect either I should push the query logic into stored procedures in the database (rather than Postfix files), and call them directly when generating the report. Or possibly a setuid script to call postmap -q (yuck). Simon
Mismatch virtual_alias_maps
Hello list. This is not working: user1@host1 sends mail to userX@host2 Intention: userX@host2 incoming forwarding to user2@host1 host2 virtual_alias_maps: @host1 user1@host1 @host2 user2@host1 But user1@host1 receive back his eMail with origin userX@host2 This runs after a lot of trials: host2 virtual_alias_maps: @host2 user2@host1 postfix Version: 2.7.1-1+squeeze1 The logic of the virtual_alias_maps select with the sender the entry of the virtual_alias_maps, i assume. Any comments?
Re: Make install or upgrade for new install location
Le 30 avr. 2013 à 21:20, Larry Stone a écrit : [...] FWIW, I consider Lion (10.7) to be the last version of OS X for which the Apple provided Postfix is usable. Hello Larry, I'm going to be somewhat OT here... The postfix binaries coming with 10.8 are per se at least as capable as the ones that came with earlier versions of the OS; as usual, these binaries are identical on the client and server versions of the OS. For Mountain Lion (10.8), they changed a lot of the default directories No, unless you upgraded from a 10.7 client to a 10.8 server version; but then, such changes were to be expected (yet easily reversible). but also removed amavisd-new (compatability through OS upgrades apparently is not something Apple thinks has value). Amavis, SpamAssasin and consorts never came with the client version; perhaps did you install Amavis yourself? That said, as far as I can tell, the latest server version of 10.7 (resp. 10.8) comes with amavisd-new-2.6.6 (20110518) (resp. amavisd-new-2.8.0 (20120630)). Plus the pain of Apple provided updates deciding to make changes to main.cf for security (Apple considers having something listening 24/7 on port 25 to be a security issue). By default, on both the client and the server versions of the OS, the master process has always been launched with its -e option (since that option became available; before, the same effect was achieved through other means), as part of a scheme allowing to have Postfix running on demand for local needs only. In order to revert to a traditional behavior, it is just a matter of manually editing a plist on the client version of the OS; on the server, this is done indirectly with the admin tools. Just wanted to clarify some points that otherwise could have appeared as counterfactual. Axel (BTW, should you have the feeling I could be of some help, please do not hesitate to contact me off-list)
Restrictions after postscreen (was: Re: Postscreen DNSBL Sites)
On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote: On Wed, Apr 24, 2013 at 3:15 PM, /dev/rob0 r...@gmx.co.uk wrote: True, but for all we know they could be preceded by a check_policy_service or permit_dnswl_client restriction. Well, in this case they're not (yet?) preceded by any of those... but I'm learning more and more with every piece of this discussion, and now want to play around with putting permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3] somewhere in there. Again, can't say. I'd have the Zen higher, before most whitelisting, but yes, BRBL belongs down there at the end. Assuming I do want put them back in, and try out permit_dnswl_client entry (only for low, medium, and high), how high up my smtpd_recipient_restrictions food chain should the Zen and permit_dnswl_client entries be (realizing the Zen reject should be above the dnswl permit)? Here are my current entries: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, I don't put these permit_* in global restrictions; I only apply them to submission via -o smtpd_relay_restrictions=... in master.cf. And that brings up another point: if you're using 2.10 you now have smtpd_relay_restrictions for relay control. reject_invalid_hostname, Deprecated syntax for reject_invalid_helo_hostname. reject_unauth_destination, See above re: smtpd_relay_restrictions. warn_if_reject reject_non_fqdn_hostname, I consider this one quite safe. In fact, it's one of the CBL's listing criteria; when they see a host using a non-FQDN as HELO, it will be listed. Deprecated syntax again. warn_if_reject reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, These are safe, but mostly pointless here. You might want them on submission, in case a user has a misconfigured MUA. warn_if_reject reject_unknown_reverse_client_hostname, Safe, because many large receivers do this as well. warn_if_reject reject_non_fqdn_helo_hostname, This is the new syntax for reject_non_fqdn_hostname, you do the warning twice for the same thing. warn_if_reject reject_invalid_helo_hostname, Deja vu all over again! warn_if_reject reject_unknown_helo_hostname, This one is NOT safe. A lot of sites use HELOs which don't resolve. So I'd not take off the warn_if_reject. reject_unauth_pipelining, This could go higher. It's a cheap restriction. check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_helo_access hash:/etc/postfix/helo_access, check_sender_access hash:/etc/postfix/check_backscatterer, check_sender_access hash:/etc/postfix/access, access is not a descriptive name. I would name it either sender_access or whatever the general purpose of the lookup is. It could also be merged with the check_backscatterer lookup. reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org, permit My guess would be to either put them just after the reject_unknown_sender_domain or just before the check_reverse_client_hostname... but that's a total guess. The BRBL entry I'd stick back just in front of the reject_rhsbl_client entry. I wouldn't whitelist the check_*_access lookups, but you might choose to do that for your own reasons. I would put Zen just before the three DBL lookups. This way the DBL lookups might be avoided. I'd keep DBL before DNSWL. I doubt the DNSWL folks want to list any client sending for DBL-listed domains, so check DBL first. The low, medium, and high idea is good, although recently I have seen a case where BRBL listed a DNSWL none host (with legitimate mail, sigh.) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Solution for Store in Virtual then Transport
Tks for the reply! But in my case I have the same domain and 2 servers to store the same messages. There is no way to do that? Best Regards! Newton Pasqualini Filho newtonpasqual...@gmail.com Em 01/05/2013, às 00:59, Noel Jones njo...@megan.vbhcs.org escreveu: On 4/30/2013 7:20 PM, Newton Pasqualini Filho wrote: Dear List, I am facing some trouble to find a way to get a solution running. We have here two mail servers, one to serve PCs and another to serve Mobile devices. The first is the primary and setter as MX for the domain, the second in only a secondary store server, that will give mobile devices work. I am facing some difficult to get this running, I tried to make an entry into transport file, over the first server, like this: domain.com http://domain.com/: smtp:mobile.domain.com The desire is to postfix store the message into maildir then, transport that to the secondary server. Each recipient is delivered exactly once. For multiple deliveries, add more recipients. Add entries to virtual_alias_maps. # virtual_alias_maps us...@example.com us...@example.com us...@mobile.example.com us...@example.com us...@example.com us...@mobile.example.com ... new entry for each user ... -- Noel Jones But it is not transporting to secondary server, only store local, and I could not find another way to do that. Appreciate any help! Best regards! Newton Pasqualini Filho newtonpasqual...@gmail.com mailto:newtonpasqual...@gmail.com
Re: Solution for Store in Virtual then Transport
Use smtp_generic_maps to rewrite mobile.example.com to example.com during delivery to the second server. http://www.postfix.org/ADDRESS_REWRITING_README.html#generic On 5/1/2013 8:37 AM, Newton Pasqualini Filho wrote: Tks for the reply! But in my case I have the same domain and 2 servers to store the same messages. There is no way to do that? Best Regards! Newton Pasqualini Filho newtonpasqual...@gmail.com Em 01/05/2013, às 00:59, Noel Jones njo...@megan.vbhcs.org escreveu: On 4/30/2013 7:20 PM, Newton Pasqualini Filho wrote: Dear List, I am facing some trouble to find a way to get a solution running. We have here two mail servers, one to serve PCs and another to serve Mobile devices. The first is the primary and setter as MX for the domain, the second in only a secondary store server, that will give mobile devices work. I am facing some difficult to get this running, I tried to make an entry into transport file, over the first server, like this: domain.com http://domain.com/: smtp:mobile.domain.com The desire is to postfix store the message into maildir then, transport that to the secondary server. Each recipient is delivered exactly once. For multiple deliveries, add more recipients. Add entries to virtual_alias_maps. # virtual_alias_maps us...@example.com us...@example.com us...@mobile.example.com us...@example.com us...@example.com us...@mobile.example.com ... new entry for each user ... -- Noel Jones But it is not transporting to secondary server, only store local, and I could not find another way to do that. Appreciate any help! Best regards! Newton Pasqualini Filho newtonpasqual...@gmail.com mailto:newtonpasqual...@gmail.com
Re: Reporting redirects - API call similar to sendmail -bv
Simon Waters: doesn't allow me to make this query, in general, without simply feeding an email through the system? e.g.. sendmail -bv works in exactly that way, presumably for similar reasons? Or is there an exposed API somewhere that answers the same question? sendmail -bv is useful because it reproduces all the steps of address transformation of a real email message. The reason it can do this is that it actually sends an email message through Postfix. There is no alternate code path that does the same thing. It would be problematic to have two different things doing the exact same thing for 14 years. Is there any problem with using sendmail -bv? The output format (the second and thord part) is meant to be machine-readable. Wietse
Re: Reporting redirects - API call similar to sendmail -bv
On 01/05/13 15:31, Wietse Venema wrote: Is there any problem with using sendmail -bv? The output format (the second and thord part) is meant to be machine-readable. I want to report the value of 30 or 40 redirects in a single web page. I want to generate that report when someone requests that web page, since they'll do it immediately after updating someone's details to see if they got it right. I guess I could generate the sendmail -bv requests, and parse them, and dump the resulting mapping back in a database table along with the last updated showing when it was processed. But it all feels a bit unsynchronized and inelegant... Ah - also looks like sendmail -bv triggers address verification each time (which makes sense as that is part of how I decide to accept an email for delivery). Thus that approach is potentially going to generate too many address verification probes. Obviously sendmail -bv is potentially a better answer than calling the SQL query directly since Postfix knows more, but looks like calling the SQL it is. Secondary question - can I force the output of sendmail -bv to go to a specific email address - seems always to go to the invoker - e.g. can I easily send this to the end users email address (which I know). Since an option to get a delivery report might help keep them happy even if it is rarely used. Especially as it includes output from the verification probe. Simon
Re: Mismatch virtual_alias_maps
On 05/01/2013 11:17 AM, b...@systron.de wrote: Hello list. This is not working: user1@host1 sends mail to userX@host2 Intention: userX@host2 incoming forwarding to user2@host1 host2 virtual_alias_maps: @host1 user1@host1 @host2 user2@host1 Don't blindly use catch-alls; see below for why. But user1@host1 receive back his eMail with origin userX@host2 virtual_alias_maps is recursive; lookups are performed until the result no longer matches a lookup key, or the input is equal to the output. In your case: RCPT TO userX@host2 is rewritten by virtual_alias_maps to user2@host1. The new recipient is again matched and rewritten to user1@host1. At this point virtual_alias_maps stops expanding, since it will keep resolving to user1@host1; single-level loop detection is built in. This runs after a lot of trials: host2 virtual_alias_maps: @host2 user2@host1 Which begs the question why you have a host2 at all. postfix Version: 2.7.1-1+squeeze1 The logic of the virtual_alias_maps select with the sender the entry of the virtual_alias_maps, i assume. No, virtual_alias_maps does not affect nor act upon the SENDER address. Whatever problem you are trying to solve, it is much better served by judicious use of transport_maps and/or unfscking your MX setup. -- J.
attachments on bounce messages generated by postfix
Please can someone help me understand how to configure what is attached to bounce messages. The version is postfix 2.3.3. Originally it only attached the message headers of the failed email with Content-Description: Undelivered Message Headers Now it attaches the entire failed email with Content-Description: Undelivered Message I would like to revert to the previous behaviour where only the headers are attached to the bounce. Thanks Ben Williams
Re: attachments on bounce messages generated by postfix
On Thu, May 02, 2013 at 10:31:43AM +1200, Ben WIlliams wrote: Please can someone help me understand how to configure what is attached to bounce messages. The version is postfix 2.3.3. Originally it only attached the message headers of the failed email with Content-Description: Undelivered Message Headers Now it attaches the entire failed email with Content-Description: Undelivered Message I would like to revert to the previous behaviour where only the headers are attached to the bounce. This depends on the message size and the bounce size limit. http://www.postfix.org/postconf.5.html#bounce_size_limit If you set bounce_size_limit = 1 bounces will only include headers (no rfc822 message fits in a single byte). Postfix does not permit setting the limit to zero or less. -- Viktor.
Re: attachments on bounce messages generated by postfix
Thanks that fixed it. On Thu, May 2, 2013 at 11:56 AM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Thu, May 02, 2013 at 10:31:43AM +1200, Ben WIlliams wrote: Please can someone help me understand how to configure what is attached to bounce messages. The version is postfix 2.3.3. Originally it only attached the message headers of the failed email with Content-Description: Undelivered Message Headers Now it attaches the entire failed email with Content-Description: Undelivered Message I would like to revert to the previous behaviour where only the headers are attached to the bounce. This depends on the message size and the bounce size limit. http://www.postfix.org/postconf.5.html#bounce_size_limit If you set bounce_size_limit = 1 bounces will only include headers (no rfc822 message fits in a single byte). Postfix does not permit setting the limit to zero or less. -- Viktor.
