[pfx] Re: Log/Capture outbound messages?
On 1/26/2024 20:55:16, Viktor Dukhovni via Postfix-users wrote: On Fri, Jan 26, 2024 at 07:51:31PM -0500, Wietse Venema via Postfix-users wrote: joe a via Postfix-users: Postfix 3.5.9-5.9.2 Perhaps not a postfix question at all. Looking for a way to capture outbound email, for troubleshooting purposes. Is "smtp-sink" the way to do this? That could be, if you are interested in outbund SMTP deliveries. smtp-sink has a crude option to save messages to file. If you want to save am "extra" copy for investigation, consider using always_bcc, sender_bcc_maps or recipient_bcc_maps. Or just deliver the messages to a maildir. The OP rather failed to specify clearly what "capture" or "outbound mail" meant. Yes, not clearly expressed. The suggestions are appreciated and should suffice for now. Thanks. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Log/Capture outbound messages?
On 1/26/2024 19:51:31, Wietse Venema via Postfix-users wrote: joe a via Postfix-users: Postfix 3.5.9-5.9.2 Perhaps not a postfix question at all. Looking for a way to capture outbound email, for troubleshooting purposes. Is "smtp-sink" the way to do this? That could be, if you are interested in outbund SMTP deliveries. smtp-sink has a crude option to save messages to file. If you want to save am "extra" copy for investigation, consider using always_bcc, sender_bcc_maps or recipient_bcc_maps. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org Yes, outbound SMTP deliveries. Thanks for the suggestions. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Log/Capture outbound messages?
Postfix 3.5.9-5.9.2 Perhaps not a postfix question at all. Looking for a way to capture outbound email, for troubleshooting purposes. Is "smtp-sink" the way to do this? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: pattern matching in local tables
On 7/7/2023 5:12 PM, Wietse Venema via Postfix-users wrote: joe a via Postfix-users: On 7/7/2023 3:46 PM, joe a via Postfix-users wrote: One hesitates to post this. Found some oddness when changing a destination in transport_maps (transport_maps = lmdb:/etc/postfix/transport). Seems related to pattern matching. The file /etc/postfix/transport contains entries of this form: somename-xyz.com noauth:ipaddress_1 somename.xyz noauth:ipaddress_2 *relay:[someISP]:587 ipaddress_1 is a server of long standing. ipaddress_2 is a new box, to eventually replace the older box. Testing reveals that emails to the first case (translated to real) address yieldd proper results, as do those to the second case. However, when I change the first case from ipaddress_1 to ipaddress_2, after postmap /etc/posfix/transport, test email to the first case "u...@somename-xyz.com" seem to "fall through" to the relay, resulting in a bounce. Will I need to resort to a "reg-ex table" to, hopefully, resolve this? Perhaps meaningful, found that "grep somename.xyz /etc/postfix/*" for example resulted in a match for somename.xyz and somename-xyz.com with somename.xyz and somename-xyz colorized, indicating the "matched" text. Variations on the form of the search term found that "grep "somename\-" files", provided an exact match. That is enclosing the search term in double quotes with the escape character seemed to "fix" it. Or, is this just "expected behavior"? Oh, Nurse, is it time for meds yet? Apparently wrong again. postmap -q "stuff" /etc/postfix/transport seems to match as expected in each case. The need to use "stuff" in the "poatmap -q" command indicates that the query contained one or more whitespace characters. In the "postmap -q" command, a query that contains whitespace needs to be enclosed to prevent the shell (bash) from splitting it into multiple arguments. Also note this in the postmap manpage: INPUT FILE FORMAT The format of a lookup table input file is as follows: - A table entry has the form key whitespace value ... Whitespace in lookup keys is supported in Postfix 3.2 and later, by surrounding the key with double quote characters `"'. Within the double quotes, double quote `"' and backslash `\' characters can be included by quoting them with a preceding backslash. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org Thanks. It's been an illuminating day, even though I spent much of it following several White Rabbits down a hole (of my own digging). The ways one can mislead oneself are many. Resorting to actually following the reject messages and failed delivers, line by line rather than "speed skimming, because I can you know", and Googling the relevant term things, the solution was presented. Seems that some email bounced as it was contained a header "Delivered-To", which was causing one set of problems. Following this, resolved that one: # vim /etc/postfix/main.cf > header_checks = regexp:/etc/postfix/header_checks # vim /etc/postfix/header_checks > /^Delivered-To:.*/ IGNORE # postmap /etc/postfix/header_checks # service postfix restart # service postfix status The last two lines of course needed to be done "the modern way". The other issue was dovecot related, oddly enough with the same user. It appeared to be defined, yet, was not found. Thanks to all who commented and for the tolerance of my too often sketchy posts. Yeah. Sketchy, go with that one. joe a. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: pattern matching in local tables
On 7/7/2023 3:46 PM, joe a via Postfix-users wrote: One hesitates to post this. Found some oddness when changing a destination in transport_maps (transport_maps = lmdb:/etc/postfix/transport). Seems related to pattern matching. The file /etc/postfix/transport contains entries of this form: somename-xyz.com noauth:ipaddress_1 somename.xyz noauth:ipaddress_2 * relay:[someISP]:587 ipaddress_1 is a server of long standing. ipaddress_2 is a new box, to eventually replace the older box. Testing reveals that emails to the first case (translated to real) address yieldd proper results, as do those to the second case. However, when I change the first case from ipaddress_1 to ipaddress_2, after postmap /etc/posfix/transport, test email to the first case "u...@somename-xyz.com" seem to "fall through" to the relay, resulting in a bounce. Will I need to resort to a "reg-ex table" to, hopefully, resolve this? Perhaps meaningful, found that "grep somename.xyz /etc/postfix/*" for example resulted in a match for somename.xyz and somename-xyz.com with somename.xyz and somename-xyz colorized, indicating the "matched" text. Variations on the form of the search term found that "grep "somename\-" files", provided an exact match. That is enclosing the search term in double quotes with the escape character seemed to "fix" it. Or, is this just "expected behavior"? Oh, Nurse, is it time for meds yet? joe a. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org Apparently wrong again. postmap -q "stuff" /etc/postfix/transport seems to match as expected in each case. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] pattern matching in local tables
One hesitates to post this. Found some oddness when changing a destination in transport_maps (transport_maps = lmdb:/etc/postfix/transport). Seems related to pattern matching. The file /etc/postfix/transport contains entries of this form: somename-xyz.comnoauth:ipaddress_1 somename.xyznoauth:ipaddress_2 * relay:[someISP]:587 ipaddress_1 is a server of long standing. ipaddress_2 is a new box, to eventually replace the older box. Testing reveals that emails to the first case (translated to real) address yieldd proper results, as do those to the second case. However, when I change the first case from ipaddress_1 to ipaddress_2, after postmap /etc/posfix/transport, test email to the first case "u...@somename-xyz.com" seem to "fall through" to the relay, resulting in a bounce. Will I need to resort to a "reg-ex table" to, hopefully, resolve this? Perhaps meaningful, found that "grep somename.xyz /etc/postfix/*" for example resulted in a match for somename.xyz and somename-xyz.com with somename.xyz and somename-xyz colorized, indicating the "matched" text. Variations on the form of the search term found that "grep "somename\-" files", provided an exact match. That is enclosing the search term in double quotes with the escape character seemed to "fix" it. Or, is this just "expected behavior"? Oh, Nurse, is it time for meds yet? joe a. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Ongoing authentication issue, SASL support?
On 7/6/2023 5:12 PM, Noel Jones via Postfix-users wrote: On Jul 6, 2023, at 2:55 PM, joe a via Postfix-users wrote: On 7/6/2023 12:56 PM, joe a via Postfix-users wrote: On 7/6/2023 8:53 AM, Viktor Dukhovni via Postfix-users wrote: On Thu, Jul 06, 2023 at 08:32:42AM -0400, joe a via Postfix-users wrote: While chasing a postfix (version 3.5.9) to dovecot authentication issue, checked "compiled in" methods: postconf -a cyrus dovecot postconf -A cyrus As expected and documented. Dovecot is only available in the SMTP server as a verifier, it does not implement the client side of SASL authentication. There is no problem here. I'm grasping at straws at this point. Certainly more reading is in order, but AFAICT, I've followed the documentation at dovecot and postfix exactly (always problematic for me to some degree these days) yet still find that some users authenticate and some do not. I can connect without issue to all the dovecot mailboxes, using Thunderbird as the email client, but can only receive mail for a few, the rest being rejected. Those that do not are rejected as unknown user, by postfix side apparently. For the rejected users, on the dovecot end (while tailing logs) nothing is seen when attempting to send (to postfix from another box), while dialog is seen for the accepted users using the same means. Seems likely that to make progress, I will need to post the various configs, but hesitate to add clutter and annoy anyone. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org This particular hurdle appears to have been cleared. Apparently this needed to be added to /etc/postfix/main.cf local_recipient_maps = With that added test email is now accepted for all defined users. Gets delivered, also, which is a plus. Yet, I remain wary of unseen dangers in the night. This is the wrong solution. With this setting, postfix will accept mail to any user address, and you will eventually have a queue full of undeliverable bounces, plus get listed as a backscatter source. The correct solution is to give postfix a list of all valid users. The easiest way to do that is have all users be system users. — Noel Jones ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org Thanks for the reply. Clearly my knowledge of postfix is weak compared to others. But seems to me that having all possible mail recipients as system users is not practical on even systems of moderate user count. While someone like myself, a quasi dilettante at this stage, with a system of perhaps 10 user names, could manage that, it would soon become a nightmare. One might expect there must be another solution, which escapes ones notice. Only became aware of the "solution" after combing through the tall grass of the wild fields of the internet. In any event, in my case, the email system is not directly exposed to the internet to receive mail, it fetches mail from defined accounts so the mentioned issues do not apply. joe a. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Ongoing authentication issue, SASL support?
On 7/6/2023 12:56 PM, joe a via Postfix-users wrote: On 7/6/2023 8:53 AM, Viktor Dukhovni via Postfix-users wrote: On Thu, Jul 06, 2023 at 08:32:42AM -0400, joe a via Postfix-users wrote: While chasing a postfix (version 3.5.9) to dovecot authentication issue, checked "compiled in" methods: postconf -a cyrus dovecot postconf -A cyrus As expected and documented. Dovecot is only available in the SMTP server as a verifier, it does not implement the client side of SASL authentication. There is no problem here. I'm grasping at straws at this point. Certainly more reading is in order, but AFAICT, I've followed the documentation at dovecot and postfix exactly (always problematic for me to some degree these days) yet still find that some users authenticate and some do not. I can connect without issue to all the dovecot mailboxes, using Thunderbird as the email client, but can only receive mail for a few, the rest being rejected. Those that do not are rejected as unknown user, by postfix side apparently. For the rejected users, on the dovecot end (while tailing logs) nothing is seen when attempting to send (to postfix from another box), while dialog is seen for the accepted users using the same means. Seems likely that to make progress, I will need to post the various configs, but hesitate to add clutter and annoy anyone. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org This particular hurdle appears to have been cleared. Apparently this needed to be added to /etc/postfix/main.cf local_recipient_maps = With that added test email is now accepted for all defined users. Gets delivered, also, which is a plus. Yet, I remain wary of unseen dangers in the night. joe a. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Ongoing authentication issue, SASL support?
On 7/6/2023 8:53 AM, Viktor Dukhovni via Postfix-users wrote: On Thu, Jul 06, 2023 at 08:32:42AM -0400, joe a via Postfix-users wrote: While chasing a postfix (version 3.5.9) to dovecot authentication issue, checked "compiled in" methods: postconf -a cyrus dovecot postconf -A cyrus As expected and documented. Dovecot is only available in the SMTP server as a verifier, it does not implement the client side of SASL authentication. There is no problem here. I'm grasping at straws at this point. Certainly more reading is in order, but AFAICT, I've followed the documentation at dovecot and postfix exactly (always problematic for me to some degree these days) yet still find that some users authenticate and some do not. I can connect without issue to all the dovecot mailboxes, using Thunderbird as the email client, but can only receive mail for a few, the rest being rejected. Those that do not are rejected as unknown user, by postfix side apparently. For the rejected users, on the dovecot end (while tailing logs) nothing is seen when attempting to send (to postfix from another box), while dialog is seen for the accepted users using the same means. Seems likely that to make progress, I will need to post the various configs, but hesitate to add clutter and annoy anyone. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Ongoing authentication issue, SASL support?
While chasing a postfix (version 3.5.9) to dovecot authentication issue, checked "compiled in" methods: postconf -a cyrus dovecot postconf -A cyrus Does this mean the choices for configuring authentication are affected? Dovecot and Postfix were installed from packaged version supplied with OS. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mail relayed for new server rejected by SIP
On 7/4/2023 9:55 PM, joe a via Postfix-users wrote: I realize this is lacking information normally requested, but before sending such, was hoping for a bit of a sanity check, without seriously annoying those more knowledgeable than I. Have working version of postfix 3.5.9 which acts as a relay for a low volume in house system, authenticating to an ISP on port 587. This I will call server A. The postfix server is configured with "smtp_sasl_type = cyrus" and has been happily conversing for a year or more, acting as a relay for a legacy system, I will call server B. Recently added another (VM) server to run postfix and dovecot. Got that working, following several write ups and nudges here, with "smtp_sasl_type = dovecot". This I will call server C. Mail that is relayed from Server A via Server B is authenticated and accepted by the ISP as has been the case for a year or so. Mail that is relayed from Server C via Server B is rejected by the ISP with the message "Client host rejected: Access denied (in reply to RCPT TO command)". Given that Server B authenticates properly in the case of server A, one might believe it should also authenticate for Server C, since each specifically "authorized" to relay via Server B. Apparently, that belief is not well founded. Thanks for any enlightenment. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org I've often wished for a "retract" feature on some mail lists. This is one of those times. It was an authentication issue, related to content of/etc/postfix/sasl_passwd. Yes, it was all my own doing. Sorry for the noise. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] mail relayed for new server rejected by SIP
I realize this is lacking information normally requested, but before sending such, was hoping for a bit of a sanity check, without seriously annoying those more knowledgeable than I. Have working version of postfix 3.5.9 which acts as a relay for a low volume in house system, authenticating to an ISP on port 587. This I will call server A. The postfix server is configured with "smtp_sasl_type = cyrus" and has been happily conversing for a year or more, acting as a relay for a legacy system, I will call server B. Recently added another (VM) server to run postfix and dovecot. Got that working, following several write ups and nudges here, with "smtp_sasl_type = dovecot". This I will call server C. Mail that is relayed from Server A via Server B is authenticated and accepted by the ISP as has been the case for a year or so. Mail that is relayed from Server C via Server B is rejected by the ISP with the message "Client host rejected: Access denied (in reply to RCPT TO command)". Given that Server B authenticates properly in the case of server A, one might believe it should also authenticate for Server C, since each specifically "authorized" to relay via Server B. Apparently, that belief is not well founded. Thanks for any enlightenment. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix sending to undefined (?)
On 7/2/2023 7:07 PM, Viktor Dukhovni via Postfix-users wrote: On Sun, Jul 02, 2023 at 06:49:53PM -0400, joe a via Postfix-users wrote: > Viktor Dukhovni via Postfix-users Sun, 02 Jul 2023 14:21:52 -0700 > >On Sun, Jul 02, 2023 at 05:11:52PM -0400, joe a via Postfix-users >wrote: > >> When attempting to send an email to postfix on that box, for delivery >to >> the local dovecot (via lmtp), the message instead goes out to my ISP in >> the fashion of currently working email se[r]ver. > >https://www.postfix.org/BASIC_CONFIGURATION_README.html#mydestination >https://www.postfix.org/VIRTUAL_README.html#canonical >https://www.postfix.org/BASIC_CONFIGURATION_README.html#relayhost Delivery issue appears to have been to undefined relay_domains and relayhost. Seems unlikely, since you were expecting final delivery on the same machine, and that should never depend on DNS, relay_domains or relayhost. Well, I admit to being confused, befuddled and bewildered. That was my thinking originally, yet, I could not deny the results of the changes I made. However, I was wrong, yet again. Reverting my changes, I realized that I had also altered "mydestination" to include the domains being tested. Reverting the other changes, shows that "mydestination" seems to have resolved the problem. I now suspect the "wrong destination" was accounted for by a postfix DNS lookup to resolve that on it's own? No pun intended. No. If you're expecting final delivery via LMTP on the same machine, then the recipient address needs to ultimately resove to the "local" or "virtual mailbox" address class, and be delivered via local(8) (possibly handing off to mailbox_transport, ...) or via virtaul_transport (be it virtual(8) or "lmtp"). Yet, my still light experience with postfix, leads me to believe having "relay host" undefined allows delivery to "the internet" if other "targets" have not been defined or "computable". Per docs: relayhost =(default: direct delivery to Internet) So, since "mydestination" did not define any local domains, the next destination, in this case, would be "the internet". The only way this machine could have known where to deliver the mail was via MX record. I hope, anyway! Machine "ESP" would be very scary indeed. Anyway, not my intent to annoy or belabor, just to gain insight. Given how configurable postfix is, that may be a lifetime's work. Thanks for all your assistance. joe a. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix sending to undefined (?)
> Viktor Dukhovni via Postfix-users Sun, 02 Jul 2023 14:21:52 -0700 > >On Sun, Jul 02, 2023 at 05:11:52PM -0400, joe a via Postfix-users >wrote: > >> When attempting to send an email to postfix on that box, for delivery >to >> the local dovecot (via lmtp), the message instead goes out to my ISP >in >> the fashion of currently working email se[r]ver. > > >https://www.postfix.org >/BASIC_CONFIGURATION_README.html#mydestination >https://www.postfix.org/VIRTUAL_README.html#canonical >https://www.postfix.org/BASIC_CONFIGURATION_README.html#relayhost > >Viktor. > Thanks for the reminders. Delivery issue appears to have been to undefined relay_domains and relayhost I now suspect the "wrong destination" was accounted for by a postfix DNS lookup to resolve that on it's own? No pun intended. joe a. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Postfix sending to undefined (?) relay
Setup a test system with dovecot and postfix, version 3.5.9, intending to create an "imap server" for local use. When attempting to send an email to postfix on that box, for delivery to the local dovecot (via lmpt), the message instead goes out to my ISP in the fashion of currently working email sever. Both telnet port 25 on localhost or swaks to localhost, yield same result. ISP destination is not defined on the test box AFAICT so at the moment I am stumped. To (re)configure postfix for dovecot, I followed the examples provided at https://doc.dovecot.org/configuration_manual/howto/postfix_dovecot_lmtp/ Which does not mention any alterations to /etc/postfix/main.cf at all ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: Why would dovecot not be answering
> On Sun, Jan 23, 2022 at 12:33:57PM -0500, Bill Cole wrote:
>> On 2022-01-22 at 23:00:55 UTC-0500 (Sat, 22 Jan 2022 23:00:55 -0500)
>> Ruben Safir
>> is rumored to have said:
>>
>> >I am really lost as to why dovecot is not authenticating
>> >
>> >I have
>> >
>> >smtpd_sasl_type = dovecot
>> >
>> >in main.cf
>> >
>> >and
>> >
>> ># Postfix smtp-auth
>> >unix_listener /var/spool/postfix/private/auth {
>> > mode = 0666
>> > user = postfix
>> > group = postfix
>> >}
>> >in /etc/dovecot/conf.d/10-master.conf
>> >
>> >
>> >I want it to authenticate on submition only
>> >
>> >Everything I read says this should do it, but I am up against a
>> >wall. I
>> >have no debugging information or log at all to confirm what postfix is
>> >doing.
>>
>
>
> where is it logged?
You might look in
/var/log/postfix.log
/var/log/mail
For possible clues.
I'd not post those entire logs though, just what might be logged around the
time of you attempts
>> That's unfortunate, because what you've provided is inadequate to
>> dioagnose your problem.
>>
>> AS ALWAYS, 'postconf -nf' and 'postconf -Mf' output plus relevant
>> (non-verbose) log lines are critical to getting useful help here.
postconf -nf > somename (like postconf-main-log.txt)
postconf -Mf > someothername (like postconf-master-log.txt)
I probably won't be much help beyond that.
joe a.
Re: SASL questions
>> > On Sat, Jan 22, 2022 at 05:56:31PM -0500, Joe Acquisto-j4 wrote: > >> >> > noauth unix - - n - - smtp >> >> > -o smtp_sasl_enable=no >> >> > -o smtp_sender_dependent_authentication=no >> >> > -o smtp_sasl_password_maps= >> >> >> >> My initial attempts did not produce the desired result. Do I need to >> >> set all three options or just the first? >> > >> > Any one of the three is logically sufficient, but the smtp(8) delivery >> > agent will be unhappy with SASL enabled and no password map, so the last >> > alone won't work. >> > >> >> When I use all three log show invalid comment for smtp >> > >> > You need to as quickly as possible get out of the habit of >> > non-substantive problem reports. If you post no logs and/or >> > no associated configuration data (postconf -nf/postconf -Mf) >> > it didn't happen, and nobody can help you. >> >> Apologies. While I am remiss in not posting that particular error, I >> did post the configuration you mention back on 1/18/2022 1:27:39 PM >> in this same thread. I assumed you had seen them. Easy enough to >> miss from that far back. >> >> The error I mentioned happened when I attempted to set all three options > above >> with all three options set as shown. It is pasted here: >> >> Jan 22 17:07:18 aux postfix/smtp[32115]: fatal: specify a password table via > the `smtp_sasl_password_maps' configuration parameter > > That's because I typo'd the first parameter name, always check > postconf(5) and look at warnings, ... The right setting is: > > -o smtp_sasl_auth_enable=no And, just like that . . . the problem seems resolved. "To Grok inf fullness" may still be far off, but, we have learned . . . >> I can generate new config dumps if you like, or reference the previous >> ones, which except for the changes above are IIRC virtually unchanged. > > Yes, whenever you change your settings and observe a new issue, post the > new settings. > > -- > Viktor. I presume no logs will be needed at this point. Thanks. To all. joe a. - j4computers, llc Stone Ridge, NY 12484 845-687-3734 www.j4computers.com -
Re: SASL questions
> On Sat, Jan 22, 2022 at 05:11:02PM -0500, Joe Acquisto-j4 wrote: > >> > Therefore your master.cf file needs to have an least one additional >> > smtp-based transport, with either SASL disabled entirely, and/or >> > sender-dependent authentication disabled, or perhaps a variant >> > password table... Below all three are set to "discourage" use >> > of SASL: >> > >> > noauth unix - - n - - smtp >> > -o smtp_sasl_enable=no >> > -o smtp_sender_dependent_authentication=no >> > -o smtp_sasl_password_maps= >> >> My initial attempts did not produce the desired result. Do I need to >> set all three options or just the first? > > Any one of the three is logically sufficient, but the smtp(8) delivery > agent will be unhappy with SASL enabled and no password map, so the last > alone won't work. > >> When I use all three log show invalid comment for smtp > > You need to as quickly as possible get out of the habit of > non-substantive problem reports. If you post no logs and/or > no associated configuration data (postconf -nf/postconf -Mf) > it didn't happen, and nobody can help you. Apologies. While I am remiss in not posting that particular error, I did post the configuration you mention back on 1/18/2022 1:27:39 PM in this same thread. I assumed you had seen them. Easy enough to miss from that far back. The error I mentioned happened when I attempted to set all three options above with all three options set as shown. It is pasted here: Jan 22 17:07:18 aux postfix/smtp[32115]: fatal: specify a password table via the `smtp_sasl_password_maps' configuration parameter Jan 22 17:07:19 aux postfix/master[32097]: warning: process /usr/lib/postfix/bin//smtp pid 32115 exit status 1 Jan 22 17:07:19 aux postfix/master[32097]: warning: /usr/lib/postfix/bin//smtp: bad command startup -- throttling Jan 22 17:08:19 aux postfix/smtp[32129]: fatal: specify a password table via the `smtp_sasl_password_maps' configuration parameter Jan 22 17:08:20 aux postfix/master[32097]: warning: process /usr/lib/postfix/bin//smtp pid 32129 exit status 1 Jan 22 17:08:20 aux postfix/master[32097]: warning: /usr/lib/postfix/bin//smtp: bad command startup -- throttling Jan 22 17:09:10 aux postfix/postfix-script[32143]: stopping the Postfix mail system I can generate new config dumps if you like, or reference the previous ones, which except for the changes above are IIRC virtually unchanged. Thanks for your efforts/ joe a. - j4computers, llc Stone Ridge, NY 12484 845-687-3734 www.j4computers.com -
Re: SASL questions
> On Sat, Jan 22, 2022 at 02:03:29PM -0500, Joe Acquisto-j4 wrote: > >> > IIRC Wietse already suggested a work-around, by making the >> > sender-dependent authentication settings be transport-specific. >> > >> > In particular the internal nexthop that does not do SASL should be >> > handled by a transport in which sender-dependent authentication is >> > disabled. >> >> I do desire outgoing email, with the "next hop" being my ISP, to have >> sender dependent authentication. Incoming email, once processed by >> Postfix, SA, ClamAV, is sent to "the last hop" which does no >> authentication. > > Sure, which means that the (smtp) transport used for that nexthop should > have sender dependent authentication enabled. > >> I do get, I think, the point you illuminate in last your paragraph >> that in my case, a specific inbound transport must be defined for all >> incoming messages and this transport must not specify authentication. > > By not enabling sender dependent authentication for the (smtp) transport > used to reach the internal mailstore. > >> However, I get a bit fuzzy about any distinction between "sender >> dependent authentication" and "no authentication". Presumably that >> will require some what different configuration than Wietse described? Thanks for your continued efforts. > Postfix attempts to use SASL authentication when: > > * smtp_sasl_enable=yes > * and either > - smtp_sender_dependent_authentication = yes and > smtp_sasl_password_maps contains a match for the sender, OR > - smtp_sasl_password_maps contains a match for the nexthop or > just the underlying hostname extracted from the nexthop > [host]:port or the like. > Therefore your master.cf file needs to have an least one additional > smtp-based transport, with either SASL disabled entirely, and/or > sender-dependent authentication disabled, or perhaps a variant > password table... Below all three are set to "discourage" use > of SASL: > > noauth unix - - n - - smtp > -o smtp_sasl_enable=no > -o smtp_sender_dependent_authentication=no > -o smtp_sasl_password_maps= My initial attempts did not produce the desired result. Do I need to set all three options or just the first? When I use all three log show invalid comment for smtp > With this, just make sure that deliveries to the internal mailstore > use the "noauth" transport: > > internal.example noauth:[gateway.example] This I took to be an entry in /etc/postfix/transport. Is that correct? joe a. >> In any event I am nagged however by what causes Postfix to attempt > authentication, >> for this oddball email when others sent to the same user do not, with the > same >> configuration. > > See above. You enabled authentication by enabling sender-dependent > authentication and configuring a table with passwords specified for > the sender addresses in question. I still see a distinction but, let's just move on and see if it can be set to rights. joe a. - j4computers, llc Stone Ridge, NY 12484 845-687-3734 www.j4computers.com -
Re: SASL questions
> On Sat, Jan 22, 2022 at 08:01:27AM +1100, raf wrote: > >> > It is an issue with email that postfix has received, via fetchmail, and is >> > attempting to deliver to another system. Authentication is being >> > attempted, without it being required or requested, at least as far as I >> > can > tell. >> >> That doesn't sound right. Add that remote server to debug_peer_list >> to increase the debugging when sending mail to it. > > There's no need. The OP reported use of sender dependent > authentication, which causes any mail *from* some recipients > to expect to need to authenticate to the nexthop server. > > If the messages in question are not in fact routed to a nexthop that > requires authentication, then sender dependent authentication should > not be enabled for these users. > > IIRC Wietse already suggested a work-around, by making the > sender-dependent authentication settings be transport-specific. > > In particular the internal nexthop that does not do SASL should be > handled by a transport in which sender-dependent authentication is > disabled. > > -- > Viktor. Perhaps I am simply slow these last few days. Please bear with me. While it may already be clear, I'll recap. I do desire outgoing email, with the "next hop" being my ISP, to have sender dependent authentication. Incoming email, once processed by Postfix, SA, ClamAV, is sent to "the last hop" which does no authentication. I do get, I think, the point you illuminate in last your paragraph that in my case, a specific inbound transport must be defined for all incoming messages and this transport must not specify authentication. However, I get a bit fuzzy about any distinction between "sender dependent authentication" and "no authentication". Presumably that will require some what different configuration than Wietse described? While I am not expecting anyone to "do it for me", obviously I am not familiar with all the configuration items available in a product as complex and evolved as Postfix, but find it difficult, at times, to attempt to discover them on my own. Perhaps they are all documented and I have simply missed them? In any event I am nagged however by what causes Postfix to attempt authentication, for this oddball email when others sent to the same user do not, with the same configuration. Perhaps the answer is "it just does, you have a work around, now go away, you silly person", joe a. - j4computers, llc Stone Ridge, NY 12484 845-687-3734 www.j4computers.com -
Re: SASL questions
> On Tue, Jan 18, 2022 at 07:22:40PM -0500, Joe Acquisto-j4 > > wrote: > >> . . . >> > I would imagine that Postfix can only authenticate to >> > servers that have entries in /etc/postfix/sasl_passwd. >> > >> > smtp_sasl_password_maps (default: empty) >> > >> > Optional Postfix SMTP client lookup tables with one >> > username:password entry per sender, remote hostname >> > or next-hop domain. Per-sender lookup is done only >> > when sender-dependent authentication is enabled. If >> > no username:password entry is found, then the >> > Postfix SMTP client will not attempt to >> > authenticate to the remote host. >> > >> > But it seems unlikely that you'd have put an entry there >> > for a server of yours that doesn't authenticate. >> > >> > Perhaps you need to add that server to debug_peer_list >> > and see what the extra logs say. >> > >> > cheers, >> > raf >> >> I believe I have that correct, per examples (and it is working mostly as > expected) >> /etc/postfixsasl_passwd takes this form: >> >> j...@aaa.comjoea@AAA:ADADAD >> j...@aaad.comj...@aaad.com:ADADAD2 >> >> As said, this appears to work and does not interfer with incoming >> email that goes to a local host, unauthenticated, in all but one case. > > Yes, it has nothing to do with incoming connections. > It's used by the Postfix SMTP client when making > outgoing connections. > > Does this mean that the problem you are seeing is with > incoming connections? Sorry, but I was under the > impression that your problem was that Postfix's SMTP > client was trying to authenticate itself to a remote > server when delivering mail somewhere (presumably > because that remote server required it). If the problem > is that an incoming SMTP connection is coming from a > remote client, and your Postfix is insisting on that > connection authenticating itself, then that's a very > different thing. > >> joe a > > cheers, > raf Sorry for the confusion. I will refrain from any self-deprecating attempts at humor. It is an issue with email that postfix has received, via fetchmail, and is attempting to deliver to another system. Authentication is being attempted, without it being required or requested, at least as far as I can tell. Any "normal" mail that is fetched from that gmail account, or others, delivers with no apparent attempt to authenticate. All authentication should fail, in any case, as it is not configured on the target server. I have attempted to examine the subject email while in the deferred queue (postcat) and comparing it to other examples. Nothing jumped out at me. Did not find a way to route mail to the deferred queue so as to revert to smtp_sender_dependent_authentication = no and send a duplicate email, then compare the two. This may not be worth further effort as it is a rather problematic way for me to test and maybe should be abandoned. I've just got it in mind there is nothing "wrong" with it and it "should" work and wonder why. But, what do I know? Thanks for the follow up. joe a
Re: SASL per user or per host disable and, use of trace, strace
> Wietse Venema: >> Joe Acquisto-j4: >> > For version 3.7.4, is there a means of disabling for smtp per user, >> > per domain, per IP, when "smtp_sender_dependent_authentication = >> > yes"? >> >> Postfix will search smtp_sasl_password_maps by sender first, and >> if that is not found, then by destination. >> >> If you don't want Postfix to authenticate to a specific destination, >> then don't list that destination in smtp_sasl_password_maps. Ah, but that seem to be the case now. I do not have the destination for that user in "smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd" yet it attempts to deliver to the correct destination and attempts to authenticate. yet when "smtp_sender_dependent_authentication = no" it makes no attempt to authenticate to the very same target server. > > It is possible to separate the per-sender and other email streams, > but that is a bit more complicated, because most people don't have > your requireents. > > This uses sender_dependent_default_transport_maps, where all > per-sender default transports share a customized Postfix SMTP cient > with its own smtp_sasl_passwd_maps setting in master.cf, which has > all the per-sender entries. > > The other email streams use the 'normal' Postfix SMTP client with > only per-destination entries in smtp_sasl_passwd_maps. > > Wietse This does look a bit complicated and I hesitate to hack at it without further eyeballing. Not sure I see how this helps "coax" postfix to not authenticate on this one inbound user. Perhaps I just need to think about it more. joe a.
Re: SASL questions
. . . > I would imagine that Postfix can only authenticate to > servers that have entries in /etc/postfix/sasl_passwd. > > smtp_sasl_password_maps (default: empty) > > Optional Postfix SMTP client lookup tables with one > username:password entry per sender, remote hostname > or next-hop domain. Per-sender lookup is done only > when sender-dependent authentication is enabled. If > no username:password entry is found, then the > Postfix SMTP client will not attempt to > authenticate to the remote host. > > But it seems unlikely that you'd have put an entry there > for a server of yours that doesn't authenticate. > > Perhaps you need to add that server to debug_peer_list > and see what the extra logs say. > > cheers, > raf I believe I have that correct, per examples (and it is working mostly as expected) /etc/postfixsasl_passwd takes this form: j...@aaa.comjoea@AAA:ADADAD j...@aaad.comj...@aaad.com:ADADAD2 As said, this appears to work and does not interfer with incoming email that goes to a local host, unauthenticated, in all but one case. joe a
Re: SASL per user or per host disable and, use of trace, strace
> Wietse Venema: >> Joe Acquisto-j4: >> > For version 3.7.4, is there a means of disabling for smtp per user, >> > per domain, per IP, when "smtp_sender_dependent_authentication = >> > yes"? >> >> Postfix will search smtp_sasl_password_maps by sender first, and >> if that is not found, then by destination. >> >> If you don't want Postfix to authenticate to a specific destination, >> then don't list that destination in smtp_sasl_password_maps. > > It is possible to separate the per-sender and other email streams, > but that is a bit more complicated, because most people don't have > your requireents. > > This uses sender_dependent_default_transport_maps, where all > per-sender default transports share a customized Postfix SMTP cient > with its own smtp_sasl_passwd_maps setting in master.cf, which has > all the per-sender entries. > > The other email streams use the 'normal' Postfix SMTP client with > only per-destination entries in smtp_sasl_passwd_maps. > > Wietse Thanks much. I'll go searching for details/examples in a bit. joe a.
SASL per user or per host disable and, use of trace, strace
For version 3.7.4, is there a means of disabling for smtp per user, per domain, per IP, when "smtp_sender_dependent_authentication = yes"? Docs/supplements seem say some roughly analogous settings were available pre V 3.x, but are now deprecated. I've not found any current setting while flailing about in the deep ethereal seas. Essentially, looking for a means to tell postfix specifically (the little dickens) to not attempt to authenticate to a specific host, by user, or hostname/IP.. By domain would seem unlikely to help resolve an annoying oddity, described in another post. Any assistance in adding trace or strace. explicit or referral to recent (and reachable) docs would be appreciated. The two referenced programs are all that are natively available in this distribution. Thanks in advance. joe a
Re: SASL questions
ite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
-o smtp_fallback_relay=
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scacheunix - - n - 1 scache
spamassassin unix - nn - - pipe
flags=Rq user=spamfilter argv=/usr/local/bin/spamass.sh -e /usr/sbin/sendmail
-oi -f ${sender} -- ${recipient}
tlsmgrunix - - n 1000? 1 tlsmgr
postlog unix-dgram n - n - 1 postlogd
-- mechanisms on localhost --
-- end of saslfinger output --
I hope that is sufficient. Thanks for any and all assistance.
joe a
Re: SASL questions
> On 2022-01-17 at 20:09:55 UTC-0500 (Mon, 17 Jan 2022 20:09:55 -0500)
> Joe Acquisto-j4
> is rumored to have said:
>
>
>> Sorry for the garbled message. Looking for the config files, etc that
>> are normally requested.
>
>
> The non-default main.cf settings, formatted for human eyes:
> postconf -nf
>
> The master.cf settings, formatted for human eyes:
> postconf -Mf
>
>
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
OK, here goes -
Using version 3.4.7 packaged by Suse. I use "fetchmail" to retrieve email via
imap one of which is gmail. The fetched mail is all sent to a local "off box"
machine, via postfix, spamassassin and clamav, all on the same server. The off
box machine let's call it "fubar", runs a rather dated groupware product I used
to support.
I send mail to one upstream provider They require authentication. Seem to have
successfully setup per user SASL authentication, with one "problem" remaining.
Since I would sometimes forget to check the gmail account, added that account
to fetchmail. It would deliver to fubar via the means described above, with a
unique fubar user, via the means mentioned above. It became convenient to
occasionally use the gmail account to test changes I might make to my local
system. That worked well, till now.
Now when I set "smtp_sender_dependent_authentication = yes" any email I send to
the gmail account from fubar, upon being "fetched", fails to deliver to "fubar"
with postfix reporting "501 Authentication failed" and the mail is deferred. If
I set "smtp_sender_dependent_authentication = no" and restart postfix, the
deferred mail is delivered. Any mail that arrives at the gmail account by any
other means delivers normally regardless of the value of
"smtp_sender_dependent_authentication".
Ultimately, I determined the attempt to authenticate to fubar happens with any
mail I send to the gmail account, where the "from" address is any valid user on
the fubar system. That includes test emails sent using swaks, via the same
upstream provider.
On the receiving end I can see logged information that shows fubar is
attempting to authenticate, which it does not attempt to do when sender
dependent authentication is not enabled. At least, not in any visible way or
even any configured way, While from the point of view of the professionals this
may "not be a real problem" perhaps for myriad uttered reasons including "WFT
dude"?, it still seems odd at the least. Probably it will be due to "something
you did and should have known better".
Below is output from postconf -Mf:
smtp inet n - n - - smtpd
-o content_filter=spamassassin
pickup fifo n - n 60 1 pickup
cleanupunix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
rewriteunix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
-o smtp_fallback_relay=
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discardunix - - n - - discard
local unix - n n - - local
virtualunix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
spamassassin unix - n n - - pipe flags=Rq
user=spamfilter argv=/usr/local/bin/spamass.sh -e /usr/sbin/sendmail -oi -f
${sender} -- ${recipient}
tlsmgr unix - - n 1000? 1 tlsmgr
postlogunix-dgram n - n - 1 postlogd
Below is output from postconf -Mf: (obfuscated)
alias_maps = hash:/etc/aliases
biff = no
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
compatibility_level = 2
content_filter =
daemon_dir
Re: SASL questions
>>> >> > > One addition: > >The swaks command line you'll need to test properly will be something like >>>> this: >>>> >>>> swaks -tls -t tar...@example.com --auth-user joea --server >>>> mail.example.com:587 >>>> >>> >>> Thanks, that got me over that hump. Test email went through, >>> >>> Now to translate this effort into fixing my postfix configuration. >>> >>> joe a >> >> The old adage "read logs and be enlightened" (OK I made that up) seems to >> hold. >> >> Eventually I emerged from my fog and found the bounce messages were via the >> provider >> IP port 25. I thought that odd, since TLS seemed established. >> >> Looking at /etc/postfix/transport(.db) found I had not used the form >> [some.host.com]:port. Fixed that >> and all seems to work. >> >> Thanks again. > > I have per user SASL authentication working, with one rather odd exception > for which I do not see a cause. It's a bit convoluted to explain before > post that, please just remind me what those are. I did make an concerted > effort to find them, but came up short. > > Thanks. > > joe a. Sorry for the garbled message. Looking for the config files, etc that are normally requested. Time to take a rest, joe a.
Re: SASL questions
>> > One addition: >>> The swaks command line you'll need to test properly will be something like >>> this: >>> >>> swaks -tls -t tar...@example.com --auth-user joea --server >>> mail.example.com:587 >>> >> >> Thanks, that got me over that hump. Test email went through, >> >> Now to translate this effort into fixing my postfix configuration. >> >> joe a > > The old adage "read logs and be enlightened" (OK I made that up) seems to > hold. > > Eventually I emerged from my fog and found the bounce messages were via the > provider > IP port 25. I thought that odd, since TLS seemed established. > > Looking at /etc/postfix/transport(.db) found I had not used the form > [some.host.com]:port. Fixed that > and all seems to work. > > Thanks again. I have per user SASL authentication working, with one rather odd exception for which I do not see a cause. It's a bit convoluted to explain before post that, please just remind me what those are. I did make an concerted effort to find them, but came up short. Thanks. joe a.
Re: SASL questions
>> One addition: >> >> The swaks command line you'll need to test properly will be something like >> this: >> >> swaks -tls -t tar...@example.com --auth-user joea --server >> mail.example.com:587 >> > > Thanks, that got me over that hump. Test email went through, > > Now to translate this effort into fixing my postfix configuration. > > joe a The old adage "read logs and be enlightened" (OK I made that up) seems to hold. Eventually I emerged from my fog and found the bounce messages were via the provider IP port 25. I thought that odd, since TLS seemed established. Looking at /etc/postfix/transport(.db) found I had not used the form [some.host.com]:port. Fixed that and all seems to work. Thanks again.
Re: SASL questions
> One addition: > > The swaks command line you'll need to test properly will be something like > this: > > swaks -tls -t tar...@example.com --auth-user joea --server > mail.example.com:587 > Thanks, that got me over that hump. Test email went through, Now to translate this effort into fixing my postfix configuration. joe a
Re: SASL questions
> On 2022-01-13 at 20:26:53 UTC-0500 (Thu, 13 Jan 2022 20:26:53 -0500) > Joe Acquisto-j4 > is rumored to have said: > > [...] >> Would it be valid to presume that an SMTP server that can be connected >> to, >> securely, via Outlook, Thunderbird and the other common clients, can >> be >> connected to via the postfix SASL stuff? > > No. There are authentication mechanisms supported by interactive clients > that are not supported by Cyrus. The most important ones are OAUTHBEARER > and XOAUTH2, which require an out-of-band (web) interaction following > the OAuth2 protocol, typically to support 2FA methods that require a > live human interaction. > >> Or is SASL/Cyrus an equine of >> a different hue? > > SASL is a broad framework used by many application protocols (SMTP, > IMAP, etc.) for authentication and each implementation is unique, but > hopefully they are interoperable when needed. As long as the relay isn't > requiring an authentication mechanism that is designed to exclude bots > (such as the those mentioned above) it should be possible to get Postfix > (using Cyrus) to authenticate to it. > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire I guess this is going a bit astray, for some viewers anyway, but after repeated authentication failures, resorted to (or availed myself of) SWAKS and still get authentication failures. I did set swaks to echo the credentials in plaintext, to the screen and know they are correct. I am unsure why they are "broken up" with "->" and <-" and wonder if that should provide a clue? Below is what is echoed to the screen. ~ # swaks === Trying mail.somehost.com:587... === Connected to mail.somehost.com. <- 220 mail.somehost.com ESMTP Postfix -> EHLO auxilary <- 250-forwardx.somehost.com <- 250-PIPELINING <- 250-SIZE 56789012 <- 250-VRFY <- 250-ETRN <- 250-STARTTLS <- 250-AUTH PLAIN LOGIN <- 250-AUTH=PLAIN LOGIN <- 250-ENHANCEDSTATUSCODES <- 250-8BITMIME <- 250 DSN -> AUTH LOGIN <- 334 bla- -> blah-user <- 334 bla -> blah-password <** 535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6 *** No authentication type succeeded -> QUIT <- 221 2.0.0 Bye === Connection closed with remote host. joe a.
Re: SASL questions
> On 2022-01-13 at 13:09:45 UTC-0500 (Thu, 13 Jan 2022 13:09:45 -0500) > Joe Acquisto-j4 > is rumored to have said: > >> While reading the Postfix SASL doc, > (http://www.postfix.org/SASL_README.html#client_sasl), >> I puzzled over a few things. >> >> - "The smtp_tls_security_level setting ensures that the connection to the > remote smtp server will be encrypted, and smtp_sasl_tls_security_options > removes the prohibition on plaintext passwords." >> >> Is that incorrect? Surely one would not want to send passwords in plaintext > as this seems to state? > > But only sending plaintext passwords *over an encrypted channel.* > > SASL has a bunch of mechanisms that provide safe authentication over a > non-secure channel. It also has a few which are essentially plaintext, only > armoring auth credentials with Base64 encoding. Mechanisms that never send > the password unencrypted/unhashed over an unencrypted channel have the > weakness that they require both sides to store the password in a recoverable > form, whereas plaintext mechanisms allow the server to only store a 1-way > hash > of the password. Having the whole channel protected from sniffing and not > having the password in a recoverable form on the server is a better choice > than allowing in-the-clear transport and using a complex mechanism to just > protect credential in transit while storing leakable passwords on the server. > >> - "With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP > client to send username and password information to the mail gateway server. > As discussed in the next section, the Postfix SMTP client supports multiple > ISP accounts. For this reason the username and password are stored in a table > that contains one username/password combination for each mail gateway > server." >> >> Figured I would ask before reading further. Is it not possible to > authenticate to the same remote (receiver) with multiple sets of credentials? > > Yes. The smtp_sasl_password_maps table can have full sender addresses, > target MX hostnames, and next-hop domains as keys. For per-sender auth to > work, > you must also enable sender-dependent authentication. See the section on > "Configuring Sender-Dependent SASL authentication" in the SOHO readme > (http://www.postfix.org/SOHO_README.html#client_sasl_sender) > > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire Thanks. I am having some problems getting the SASL thing working. Not looking for any "fix" advice, but would like to establish something in my mind. Would it be valid to presume that an SMTP server that can be connected to, securely, via Outlook, Thunderbird and the other common clients, can be connected to via the postfix SASL stuff? Or is SASL/Cyrus an equine of a different hue? joe a.
SASL questions
While reading the Postfix SASL doc, (http://www.postfix.org/SASL_README.html#client_sasl), I puzzled over a few things. - "The smtp_tls_security_level setting ensures that the connection to the remote smtp server will be encrypted, and smtp_sasl_tls_security_options removes the prohibition on plaintext passwords." Is that incorrect? Surely one would not want to send passwords in plaintext as this seems to state? - "With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP client to send username and password information to the mail gateway server. As discussed in the next section, the Postfix SMTP client supports multiple ISP accounts. For this reason the username and password are stored in a table that contains one username/password combination for each mail gateway server." Figured I would ask before reading further. Is it not possible to authenticate to the same remote (receiver) with multiple sets of credentials? I ask as preliminary discussion with a potential provider seemed to indicate a "per user" authentication is required. Still waiting for clarification on that point. Thanks.
Re: Can i run postfix on my home IP
> Hello list, > > I have got a DSL from the ISP, having a static IP. > Can I run postfix with this IP for accepting email for my own domain? > > ありがとう > えりな Late to the party, but, certainly. Many here do. However, exposing your mail port "to the world" might entice much more "unfriendly traffic" than you might imagine. joe a
Re: https://www.postfix.org/ in trouble
> Date: Tuesday, January 11, 2022 19:38:05 +0100 >> From: "Claus R. Wickinghoff" >> Today I find only a directory listing at www.postfix.org or >>> www.postfix.com >> With http it's working. >> >> With https I get a certificate warning (issued for >> archive.science.uu.nl) and a directory listing. >> >> So might be a regional problem? >> > > See the list archive for a discussion of this earlier this month, > specifically: > ><https://marc.info/?l=postfix-users=164151969101894=2> > > Nothing is broken, https just isn't supported. Sorry for the noise, apparently I changed something in my browser to require https. Odd that. joe a.
Re: https://www.postfix.org/ in trouble
> raf wrote: >> Being flippant, it would protect against a >> man-in-the-middle-attack where someone tricks you into >> reading false online documentation. :-) > > Why bother? Most of us can misread the docs perfectly well all on our > own... > > -kgd Today I find only a directory listing at www.postfix.org or www.postfix.com joe a.
Re: local system mail
. . . > > I did not notice that adding non_smtpd_milters also caused off > box (smtpd) mail to be scanned twice, before and after > spamassassin. > > Apparently having both smtpd_milters and non_smtpd_milters > specified in main.cf causes that. > > Initially it appeared to me that milters had to be specified main.cf. > Delving somewhat deeper it now appears that to me milters can > alternately be specified in master.cf? Is that correct? > > joe a Re-reading http://www.postfix.org/FILTER_README.html#principles I think provides what I sought. Thanks for the comments, more insight is always useful. joe a.
Re: local system mail
> On 22 Feb 2021, at 18:40, Joe Acquisto-j4 wrote: > On 22 Feb 2021, at 17:27, Joe Acquisto-j4 wrote: >>> >>>> Post fix version 3.4.7. with Spamassassin. While adding virus >>>> scanning (clamav) noticed during testing >>>> that any mail send from the postfix host does not get processed by >>>> spamassassin. >>>> >>>> Postfix does accept it and passes it right thorough without any >>>> indication it was passed through >>>> spamd or clamd. >>> >>> Critical issue: what mechanisms are you using to integrate >>> SpamAssassin >>> and ClamAV? >>> >>>> Wondering how I can fix that. That is, cause local mail to be >>>> scanned. >>>> >>>> Quick look at master.cf and main.cf, nothing jumped out to bite me. >>> >>> If you are using Milters, you need to set non_smtpd_milters to get >>> locally-submitted mail to be shown to them. If that's not the >>> solution >>> in your case (i.e. you're using the SMTP proxy or content_filter >>> mechanisms) you need to explain your configuration. >>> >>> -- >>> Bill Cole >> >> Thanks. Sorry for the terse post. Figured it was such an obvious >> amateur error not much was needed. >> >> Setting non_smtpd_milters did the trick for testing the virus scanner. >> I >> should have guessed that on my own. >> >> The content filter (spamassassin) is not a hot item. but the relevant >> lines >> from master.cf are: >> . . . >> smtp inet n - n - - smtpd -o >> content_filter=spamassassin > > You need an analogous configuration for the pickup service to get local > mail piped through the spamassassin service. See > http://www.postfix.org/FILTER_README.html. > > -- > Bill Cole . . . I did not notice that adding non_smtpd_milters also caused off box (smtpd) mail to be scanned twice, before and after spamassassin. Apparently having both smtpd_milters and non_smtpd_milters specified in main.cf causes that. Initially it appeared to me that milters had to be specified main.cf. Delving somewhat deeper it now appears that to me milters can alternately be specified in master.cf? Is that correct? joe a
Re: ways to process HOLD queue
> On 24/02/21 11:47 am, Joe Acquisto-j4 wrote: >> Added Virus scanning to a SOHO stetup. clamav-milter is directing (?) > "infected" mail to postfix HOLD queue. > > Perhaps rather than having clamav-milter put the message on hold, it > might be possible to have clamav-milter simply flag the message (by > adding a header), and then it could still be delivered to the user, > optionally using sieve to put it into a different (e.g. Junk) folder? > > Nick. One would think so, that was one of my first thoughts. Seems there could be such an option, but I've not found it. Thought also occurred that postfix might have a "queue alert" notice option which I did not notice. Tend to think there must be some means but often the obvious is not. It's easy enough to make a have cron run a simple script that checks the queue and alert someone for disposition. joe a.
ways to process HOLD queue
Added Virus scanning to a SOHO stetup. clamav-milter is directing (?) "infected" mail to postfix HOLD queue. That's fine. First thought is to process the queue'd mail, alter the subject line, based on the added descriptive header line, and deliver it to the intended user(s). I don't consider that a great risk in this case. Is http://www.postfix.org/FILTER_README.html the proper place to be snooping about, a good place to start hacking at a solution? (Thanks to Bill Cole for the link, for a different reason). My "cybie sense" tells me this is not a unique goal and probably has "boiler plate" solutions, lurking every where. But my search skills are at odds with the SEO overlords these days. (ie, I can't find nothing, useful, no how, lately) Thanks for your tolerance. joe a.
Re: local system mail
> On 22 Feb 2021, at 17:27, Joe Acquisto-j4 wrote:
>
>> Post fix version 3.4.7. with Spamassassin. While adding virus
>> scanning (clamav) noticed during testing
>> that any mail send from the postfix host does not get processed by
>> spamassassin.
>>
>> Postfix does accept it and passes it right thorough without any
>> indication it was passed through
>> spamd or clamd.
>
> Critical issue: what mechanisms are you using to integrate SpamAssassin
> and ClamAV?
>
>> Wondering how I can fix that. That is, cause local mail to be
>> scanned.
>>
>> Quick look at master.cf and main.cf, nothing jumped out to bite me.
>
> If you are using Milters, you need to set non_smtpd_milters to get
> locally-submitted mail to be shown to them. If that's not the solution
> in your case (i.e. you're using the SMTP proxy or content_filter
> mechanisms) you need to explain your configuration.
>
> --
> Bill Cole
Thanks. Sorry for the terse post. Figured it was such an obvious
amateur error not much was needed.
Setting non_smtpd_milters did the trick for testing the virus scanner. I
should have guessed that on my own.
The content filter (spamassassin) is not a hot item. but the relevant lines
from master.cf are:
. . .
smtp inet n - n - - smtpd -o
content_filter=spamassassin
. . .
spamassassin unix - nn - - pipe
flags=Rq user=spamfilter argv=/usr/local/bin/spamass.sh -e /usr/sbin/sendmail
-oi -f ${sender} -- ${recipient}
. . .
Hopefully that is enough.
joe a.
local system mail
Post fix version 3.4.7. with Spamassassin. While adding virus scanning (clamav) noticed during testing that any mail send from the postfix host does not get processed by spamassassin. Postfix does accept it and passes it right thorough without any indication it was passed through spamd or clamd. Wondering how I can fix that. That is, cause local mail to be scanned. Quick look at master.cf and main.cf, nothing jumped out to bite me. joe a.
Re: blocking attachments. Sanity check and testing
> I'm revisiting blocking certain attachments. A multi part question: > Implementation, logging, testing. > > Seems the accepted way to do attachment blocking is something like this: > > in /etc/postfix/main.cf added, without quotes: "mime_header_checks = > regexp:/etc/postfix/block_attachments" > > in /etc/postfix/block_attachments added, without quotes: > "/name=[^>]*\.(1|2|3)/ DISCARD" > > I have read some discussions on DISCARD and, for my purpose, it suits. I > think. > > Is the action logged anywhere? I have not seen it. If not, can it be done? > > Finally, I hope (if only to avoid further exposing my ignorance), what is a > simple way to test the workings, preferably with > actual messages that have been received? Well, never mind on the logging and by inference, all but the "test immediately" thing. "discard" clearly shows in /var/log/mail. When one removes cranium from posterior that is.
blocking attachments. Sanity check and testing
I'm revisiting blocking certain attachments. A multi part question: Implementation, logging, testing. Seems the accepted way to do attachment blocking is something like this: in /etc/postfix/main.cf added, without quotes: "mime_header_checks = regexp:/etc/postfix/block_attachments" in /etc/postfix/block_attachments added, without quotes: "/name=[^>]*\.(1|2|3)/ DISCARD" I have read some discussions on DISCARD and, for my purpose, it suits. I think. Is the action logged anywhere? I have not seen it. If not, can it be done? Finally, I hope (if only to avoid further exposing my ignorance), what is a simple way to test the workings, preferably with actual messages that have been received?
Re: adding AV scanning to working Postfix/SA system
> michael Schumacher wrote: >> Joe, >> Due to some recent malware (in attachments, obvious stuff) wanted to add AV > scanning. I gather "Amavis-new" is the hot ticket these days, >>> I deal with Sophos products and would like to use their linux product to do > the scanning. Seems to be precious little on how to do that. >> >> I am using amavis with clamav. Sorry, no additional commercial virus > scanners, but I noticed that amavis.conf contains setups for a lot of > commercial virus scanners. May be worth a look. >> >> Michael >> >> > > FWIW, I was going to say my impression is amavis-new was the hot ticket > several years ago, but is losing market share to rspamd. > https://rspamd.com/doc/modules/external_services.html says rspamd has > been tested with Sophos (via SAVDI). My amavisd.conf says it works with > Sophie (unmaintained since 2004), Sophos SAVE via SAVI-Perl > (https://metacpan.org/release/SAVI-Perl from 2005), and as a last resort > Sophos sweep. I'll have a look, thanks. The links to those references on the amavis docs page seem to be out of date, as they lead to dead ends, far as I could tell. - j4computers, llc Stone Ridge, NY 12484 845-687-3734 www.j4computers.com -
adding AV scanning to working Postfix/SA system
Not to waste anyone's time, but I posted this on SA list and a Sophos site, but, came up with zip. Not even a "do-dah". Beyond "experiences" any leads to general "how to: guides that work in practice? >> SOHO system, on virtual machines. Fairly recent versions. Running openSUSE >> Leap 15.1. Due to some recent malware (in attachments, obvious stuff) wanted to add AV scanning. I gather "Amavis-new" is the hot ticket these days, I deal with Sophos products and would like to use their linux product to do the scanning. Seems to be precious little on how to do that. Any experiences? - j4computers, llc Stone Ridge, NY 12484 845-687-3734 www.j4computers.com -
Re: [External] command injection by crafted recipient address
>>>
> kris_h:
>> Hey Wietse,
>>
>> thank you for this clearification.
>>
>> What do you think about using the reject-recipient /\$\{/-rule?
>
> As a temporary rule, it may have made sense when the Exim bug was new.
>
> As a permanent 'deny' rule, it won't block new exploits.
>
> Wietse
Seems these exploits only a concern if Exim is installed? Or am I mistaken?
-
j4computers, llc
Stone Ridge, NY 12484
845-687-3734
www.j4computers.com
-
LMTP and virtual users confusion
Hi fair folks. After years of using OS X servers I'm back on FreeBSD and well... owls have sure aged since then. So I'm trying to do a virtual domain+virtual users setup with Dovecot where I'd have several virtual domains and several users. Each user is supposed to be authenticated via the simple username both for SMTP and IMAP, not a full email address and each will have several email aliases on different domains. Pretty simple so far. However, I've set up the virtual_transport to be lmtp and that transport relays the entire recipient's email address to Dovecot. main.cf: virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_mailbox_domains = aqq.is virtual_mailbox_maps = hash:/usr/local/etc/postfix/virtualmailboxes virtualmailboxes: t...@aqq.is testmail te...@aqq.istestmail And in the mail log: dovecot: lmtp(20405): Connect from local dovecot: auth-worker(20407): passwd(t...@aqq.is): unknown user I would expect Postfix to accept mail both for test and test2 and tell Dovecot via LMTP to deliver the mail to the user named testmail. But I cannot do that because Postfix doesn't relay "testmail" to Dovecot for user lookup. All other options that I've tried either make Postfix try to write to mailboxes by itself or make Dovecot indiscriminate and accept every incoming message, creating folders with different email addresses. So the question is, what am I doing wrong there? Is the configuration that I have in my mind even possible? And suppose if it's possible, second question is how do I make SMTP authentication work in such a scenario? -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
OT - smartmontools
Pardon the OT post, but looking for comments on smartmontools and GSmartControl, disk monitoring software. Off list only replies are fine with me.
SOT - Mimecast, blacklist
Sorry to post OT, but anyone having issues with mimecast? I normally send via my providers mail server (Specturm aka TimeWarner). Email to certain address never arrived, no bounce. Setup to send to their domain and/or IP via their published MX and immediately got "451 - IP temporarily blacklisted". So far no response to my support query to them.
Re: different "relay" for specific domain
>>>> Wietse Venema <wie...@porcupine.org> 10/20/16 1:56 PM >>> >Joe Acquisto-j4: >> Currently have postifx configured to relay mail via a "relay_host" >> (main.cf). There is a need to send mail to a certain domain via >> a different host. Google has suggested a few ways, transport >> hash, header filter. >> >> Since this special destination has a primary and a secondary IP, >> how might I specify more than one IP for this "custom" domain? > >With multiple address records in DNS or /etc/hosts. See also: >http://www.postfix.org/postconf.5.html#smtp_host_lookup > >Wietse /etc/hosts as it is a "private" domain. A VPN is used. I would need to "fall back" to the secondary, should the primary be unresponsive. joe a.
different "relay" for specific domain
Currently have postifx configured to relay mail via a "relay_host" (main.cf). There is a need to send mail to a certain domain via a different host. Google has suggested a few ways, transport hash, header filter. Since this special destination has a primary and a secondary IP, how might I specify more than one IP for this "custom" domain?
was - ? Re: alterMIME
Perhaps it's time to change the subject line?
Re: alterMIME
>>> On 8/23/2016 at 1:16 AM, in message <388d98f9-e63e-4d0a-865a-f32814510...@billmail.scconsult.com>, "Bill Cole" <postfixlists-070...@billmail.scconsult.com> wrote: > On 22 Aug 2016, at 16:14, Joe Acquisto-j4 wrote: > >> Any chance of assistance here with alterMIME? > > A slim chance, but it's worth a shot... > >> There is a need to add disclaimers to outgoing mail. > > Someone won't listen to reason, huh? That's unfortunate. Yes. Sad how common that is these days. > You might try pointing them at > http://apps.americanbar.org/litigation/committees/technology/articles/winter > 2013-0213-do-email-disclaimers-really-work.html > but only you can judge whether pushing back is a better or worse > strategy in your circumstance than just doing a small bit of useless > work. "You can lead a horse to water . . . " >> I have it configured (one supposes) to be complaint free on restart of >> postfix and can see from /var/log/mail that is does act on the >> specific email addresses (senders) that I intended. At least it was >> processed by "filter". I am a bit puzzled that "relay" shows as >> "filter" for all users. But mail does ultimately deliver via the >> normal route > > Evidence of what exactly this all means would help make it easier to > help. I'd bet that most people here don't use alterMIME, but that's not > entirely dooming: many of us use tools that modify mail as it passes > through Postfix and generally speaking that works in a limited number of > ways. The fact that you're trying to use alterMIME specifically is not > as important as how you have configured Postfix to use it, what your log > is actually saying about the handling of messages, and what the raw > input and output messages look like. > >> However, the received mail does not actually contain the disclaimer >> message. Google has not been my friend today with no results that >> seem to apply. > > Based on these being the top "how to" hits for altermime disclaimers: > > https://www.howtoforge.com/how-to-automatically-add-a-disclaimer-to-outgoing-emails-w > > ith-altermime-postfix-on-debian-squeeze > https://www.gypthecat.com/how-to-add-different-disclaimers-using-altermime-and-postf > > ix-based-on-domain Those were my "templates". I had to dig a bit deeper to get this far. > I'm guessing that you're using a similar setup: a script run as a pipe > transport due to a content_filter directive in the smtpd line in > master.cf, which runs altermime on messages selectively and reinjects > them with sendmail. That's a bit inflexible and inefficient, but I guess > it would be OK for very modest volume and not needing the disclaimer on > mail generated on the server itself. That approach pipes *all* mail > arriving by SMTP into the filter script, avoiding loops because local > 'sendmail' submission doesn't use SMTP. This would explain why your log > shows all mail going to "filter". > Assuming that guess is correct... It is. >I'd start by making sure that the > script that runs altermime is run by a user that can write to wherever > it tries to do its work. Once you confirm this isn't a permissions > problem (which I expect because that would likely cause no delivery at > all,) add diagnostic lines to the script so you can see what exactly it > is actually doing when it runs. > > And for what it's worth: if you really must do this, consider using a > better tool. One option: the MIMEDefang milter. MIMEDefang is maybe > overkill if this is just an outbound system and you don't need robust > filtering capabilities, but it is a mature, actively maintained, and > well-documented piece of software that can manipulate MIME messages > correctly, including adding silly disclaimers selectively without > damaging message structure. As a milter, it acts on a message as it > passes through a Postfix smtpd process rather than as a next hop > transport and Postfix can be configured to also use it for non-SMTP > injections. That may be best. I was put off by alterMIME, last touched in 2008 or so, but there was precious little else I could find. Overkill is OK as long as it stays dead. I was concerned about "volume" as there are occasional "blasts" of messages that forced me to tinker so mail flowed through faster. >There may be other milters available strictly for adding > disclaimers, but I'm not aware of any. I sure did not find any. Thanks for your thorough response. The MIMEDefang suggestion I will definitely follow up on. Well, off to the sulphur mines.
Re: alterMIME
>>> On 8/22/2016 at 7:31 PM, in message <6d14c5d6-a707-499e-854b-5287d47b8...@kreme.com>, "@lbutlr" <krem...@kreme.com> wrote: > On 22 Aug 2016, at 14:14, Joe Acquisto-j4 <j...@j4computers.com> wrote: >> There is a need to add disclaimers to outgoing mail. > > Just as a point of information, I consider mail with attached disclaimers to > be spam and classify them as such. > > I used to post all the “Warning, this email is confidential” emails to a > public web server. Thanks for sharing.
alterMIME
Any chance of assistance here with alterMIME?There is a need to add disclaimers to outgoing mail. I have it configured (one supposes) to be complaint free on restart of postfix and can see from /var/log/mail that is does act on the specific email addresses (senders) that I intended. At least it was processed by "filter". I am a bit puzzled that "relay" shows as "filter" for all users. But mail does ultimately deliver via the normal route However, the received mail does not actually contain the disclaimer message. Google has not been my friend today with no results that seem to apply.
Re: relay oddity. - NP
>Please provide concrete evidence as requested. > > Wietse Entirely my misinterpreting what I observed. Working as intended/expected. Sorry for the inconvenience and thanks for your gentle response.
Re: relay oddity.
First, thanks for the prompt response and please forgive the reply formatting. Web client is not helpful. I will attempt to provide info as per the links provided. I drew my conclusion simply from watching "tail -f /var/log/mail" as I altered main.cf and did "rcpostfix restart" Was that naive? HTH. >>>> Wietse Venema <wie...@porcupine.org> 08/18/16 10:10 AM >>> >Joe Acquisto-j4: >> Using postfix 2.5.6. >> >> In main.cf, changed "relayhost" from and IP address to a valid domain. > > - the "sender" changed from the original sender domain to the host > name and domain of the postfix server. What is the evidence that led you to to this conclusion? See http://www.postfix.org/DEBUG_README.html#mail for how to report Postfix logging. > - the mail was shown as "queued" instead of "delivered" What is the evidence that led you to to this conclusion? See http://www.postfix.org/DEBUG_README.html#mail for how to report Postfix logging. > What can I do to retain the senders actual email address? Why do you believe that POSTFIX changed the sender's email address? Wietse
relay oddity.
Using postfix 2.5.6. In main.cf, changed "relayhost" from and IP address to a valid domain. - the "sender" changed from the original sender domain to the host name and domain of the postfix server. - the mail was shown as "queued" instead of "delivered" What can I do to retain the senders actual email address?
Re: 452 4.3.1 Insufficient system storage
Turns out, the actual number of recipients is closer to 3500 addressees. That may be giving the server a belly full after all. Presume the simplest way to deal is to add a disk (VM is wonderful) and tell postfix to use that space to it's hearts content via spool definition in /etc/postifx/main.cf ? >>> "Joe Acquisto-j4" <j...@j4computers.com> 05/12/16 11:33 AM >>> Postfix version 2.5.6 being used as a relay for chatty internal processes. Suddenly, one of them is complaining of this error, in the midst of a 250 ish recipient email. With attachment of some size. ". . .postfix/smtpd[15953]: NOQUEUE: reject: MAIL from unknown[192.168.aa.bb]: 452 4.3.1 Insufficient system storage; proto=ESMTP helo=" Seems this may be telling me the machine was out of disk space or a Queue was limited in some way, but I have about 4GB of free space. I am attempting to determine the size of the mailing list from the sender, the attachment is 2MB or so. Simple issue, eluding me?
452 4.3.1 Insufficient system storage
Postfix version 2.5.6 being used as a relay for chatty internal processes. Suddenly, one of them is complaining of this error, in the midst of a 250 ish recipient email. With attachment of some size. ". . .postfix/smtpd[15953]: NOQUEUE: reject: MAIL from unknown[192.168.aa.bb]: 452 4.3.1 Insufficient system storage; proto=ESMTP helo=" Seems this may be telling me the machine was out of disk space or a Queue was limited in some way, but I have about 4GB of free space. I am attempting to determine the size of the mailing list from the sender, the attachment is 2MB or so. Simple issue, eluding me?
Re: postfix 3.0.0 errors out with a read-only config directory
Hello Viktor, I had to comment out these 3 lines to get it to work. With this change to lines 209-211, the script works fine. +# IFS= +# +# BACKUP_IFS=$IFS Did you per-chance lose the SPACETAB in IFS=SPACETABNEWLINE [ That is: IFS= ] Thanks, That is exactly what happened. My editor settings remove trailing spaces or tabs. The post-install from 3.1-20150330 worked fine without any issues. Thanks again, Joe signature.asc Description: Digital signature
postfix 3.0.0 errors out with a read-only config directory
Hello,
The post-install script always fails when the /etc/postfix (config
directory) is read-only.
* Starting postfix ...
* ERROR: postfix failed to start
mail.log has these false entries:
Mar 31 00:06:07 master postfix/postfix-script[11540]: fatal: unable to
create missing queue directories
Mar 31 00:06:07 master postfix/postfix-script[11541]: fatal: Postfix
integrity check failed!
The queue directories already exist. The message is shown when
post-install fails.
Any thoughts, please?
I am also attaching my local working version of post-install.
Thanks
Joe
--- post-install.original 2015-03-31 00:30:39.624259019 -0400
+++ post-install2015-03-31 00:37:40.369394797 -0400
@@ -206,9 +206,9 @@
PATH=/bin:/usr/bin:/usr/sbin:/usr/etc:/sbin:/etc:/usr/contrib/bin:/usr/gnu/bin:/usr/ucb:/usr/bsd
SHELL=/bin/sh
-IFS=
-
-BACKUP_IFS=$IFS
+# IFS=
+#
+# BACKUP_IFS=$IFS
debug=:
#debug=echo
MOST_PARAMETERS=command_directory daemon_directory data_directory
@@ -430,144 +430,144 @@
# Confine side effects from mail_version unexpansion within a subshell.
-(case $mail_version in
-) mail_version=`$POSTCONF -dhx mail_version` || exit 1
-esac
-
-for name in $MOST_PARAMETERS
-do
-eval junk=\$$name
-case $junk in
-*$mail_version*)
- case $pattern in
- ) pattern=`echo $mail_version | sed 's/\././g'` || exit 1
- esac
- val=`echo $junk | sed s/$pattern'$/${mail_version}/g'` || exit 1
- eval ${name}='$val'
-esac
-done
-
-override=
-for name in $MOST_PARAMETERS
-do
-eval test \\$$name\ = \`$POSTCONF -c $config_directory -h $name`\ || {
- override=1
- break
-}
-done
-
-test -n $override {
-$POSTCONF -c $config_directory -e \
- daemon_directory = $daemon_directory \
- command_directory = $command_directory \
- queue_directory = $queue_directory \
- data_directory = $data_directory \
- mail_owner = $mail_owner \
- setgid_group = $setgid_group \
- sendmail_path = $sendmail_path \
- mailq_path = $mailq_path \
- newaliases_path = $newaliases_path \
- html_directory = $html_directory \
- manpage_directory = $manpage_directory \
- sample_directory = $sample_directory \
- readme_directory = $readme_directory \
- shlib_directory = $shlib_directory \
- meta_directory = $meta_directory \
-|| exit 1
-} || exit 0) || exit 1
+# (case $mail_version in
+# ) mail_version=`$POSTCONF -dhx mail_version` || exit 1
+# esac
+
+# for name in $MOST_PARAMETERS
+# do
+# eval junk=\$$name
+# case $junk in
+# *$mail_version*)
+# case $pattern in
+# ) pattern=`echo $mail_version | sed 's/\././g'` || exit 1
+# esac
+# val=`echo $junk | sed s/$pattern'$/${mail_version}/g'` || exit 1
+# eval ${name}='$val'
+# esac
+# done
+
+# override=
+# for name in $MOST_PARAMETERS
+# do
+# eval test \\$$name\ = \`$POSTCONF -c $config_directory -h $name`\ ||
{
+# override=1
+# break
+# }
+# done
+
+# test -n $override {
+# $POSTCONF -c $config_directory -e \
+# daemon_directory = $daemon_directory \
+# command_directory = $command_directory \
+# queue_directory = $queue_directory \
+# data_directory = $data_directory \
+# mail_owner = $mail_owner \
+# setgid_group = $setgid_group \
+# sendmail_path = $sendmail_path \
+# mailq_path = $mailq_path \
+# newaliases_path = $newaliases_path \
+# html_directory = $html_directory \
+# manpage_directory = $manpage_directory \
+# sample_directory = $sample_directory \
+# readme_directory = $readme_directory \
+# shlib_directory = $shlib_directory \
+# meta_directory = $meta_directory \
+# || exit 1
+# } || exit 0) || exit 1
# Use file/directory status information in $meta_directory/postfix-files.
test -n $create {
postfix_files_d=$meta_directory/postfix-files.d
for postfix_file in $meta_directory/postfix-files \
Re: postfix 3.0.0 errors out with a read-only config directory
Hello Wietse, Thanks for the quick response. The post-install script always fails when the /etc/postfix (config directory) is read-only. I'll have to try that. Misleading error messages are undesirable. Thanks. I am also attaching my local working version of post-install. Looks like you're preventing it from updating main.cf. This was fixed days ago with postfix-3.1-20150329. Can you try the post-install file from that distribution? It should work with postfix-3.0.0. Just tested with the post-install from ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-3.1-20150330.tar.gz I had to comment out these 3 lines to get it to work. With this change to lines 209-211, the script works fine. +# IFS= +# +# BACKUP_IFS=$IFS It looks like the sub-shell processing for writing back to main.cf is working now. Thanks again, Joe signature.asc Description: Digital signature
Re: OT, where to turn?
On 1/21/2015 at 10:37 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Jan 21, 2015 at 09:08:19PM -0500, Joe Acquisto-j4 wrote: This appeared to work fine and does, for most messages. However, our org often sends an email to thousands of users with in our system. These messages fail to forward, bounced by o365 as header exceeds static size limit or to that effect. The people doing mass the mailings are email-incompetent. These MUST be done as Bcc. They MUST NOT attempt to list all recipients in the To: or Cc: lines. Such mass mailings, if delivered, cause mail-storms when someone is foolish enough to Reply-Al. And they do stress various email header limits. -- Viktor. Thanks. I appreciate the reminder. The methodology is long standing and should be altered. The users have only the tools offered to them. However, not trying to be argumentative at all - While I agree Bcc is correct, I am having difficulty accepting, logically, not in fact, that the forwarded message should fail. After all, it is actually addressed to only one person. By analogy, would UPS or FedEx be correct to refuse a shipment as overweight if it consisted of an envelope empty except for a sticky note that had 500 Lbs. written on it? If the answer is: RFC says, I would feel the same, but have to shut up and sit down. I should let it go, on this list at least. joe a.
Re: OT, where to turn?
Please excuse the top post. the web client . . . Thanks for expanding on this. I've hacked a means of getting around this for the time being, until we can change the addressing of the lists. A simple fix, technically but a cautious tradition exists. Thanks for all the comments. joe a. Viktor Dukhovni postfix-us...@dukhovni.org 01/22/15 9:59 AM On Thu, Jan 22, 2015 at 06:13:30AM -0500, Joe Acquisto-j4 wrote: While I agree Bcc is correct, I am having difficulty accepting, logically, not in fact, that the forwarded message should fail. After all, it is actually addressed to only one person. The SMTP envelope is one person, but many MTAs (including the venerable Sendmail) impose limits on the sizes of the message headers, whether such limits are byte counts or recipient counts, ... Postfix is more generous than many, and limits only the length of individual logical header lines truncating them to ~100K bytes each (Sendmail limits the entire set of headers to ~64K, perhaps 32K in some versions). By analogy, would UPS or FedEx be correct to refuse a shipment as overweight if it consisted of an envelope empty except for a sticky note that had 500 Lbs. written on it? Your analogies are irrelevant. MTAs process both the message envelope and the headers, and resource limits vary. The software doing the bulk mailings is broken, and that's the problem you need to focus on. Good luck. -- Viktor.
Re: OT, where to turn?
Daniel Miller dmil...@amfes.com 01/22/15 9:03 AM On 1/22/2015 3:13 AM, Joe Acquisto-j4 wrote: Thanks. I appreciate the reminder. The methodology is long standing and should be altered. The users have only the tools offered to them. However, not trying to be argumentative at all - While I agree Bcc is correct, I am having difficulty accepting, logically, not in fact, that the forwarded message should fail. After all, it is actually addressed to only one person. By analogy, would UPS or FedEx be correct to refuse a shipment as overweight if it consisted of an envelope empty except for a sticky note that had 500 Lbs. written on it? If the answer is: RFC says, I would feel the same, but have to shut up and sit down. I should let it go, on this list at least. joe a. Are you asking to have a single copy of all mail forwarded to the o365 account? You could perhaps make use of the sender_bcc_maps and recipient_bcc_maps to do it behind the scenes. Though if o365 is rejecting anything that has a header greater than a given size that wouldn't help. Perhaps you could define a transport map for o365, that passed the message through a simple script that stripped the CC BCC headers prior to sending it on. -- Daniel Anything one of the, say, 50 out of 5000, users get, should be forwarded to their o365 account. The lists used to create the various mass emailings unfortunately were created addressing the members as To: It's not the size apparently (as in bytes) despite the DSN message, it appears to be the number of addressees in the TO: of the original message. I say this as I was able to successfully forward one of the failing messages with the same recipient address in the Bcc, but with a blank To:. I just did that on a whim, not expecting a blank To: to be accepted, somewhere along the line. Sigh. There must be a number of work arounds, now that I have a clue. A better analogy perhaps: it's as if the Postal Service refused to deliver an envelope with one addressee because it contained another envelope with several addressees on it. Maybe it's just me. joe a.
OT, where to turn?
Hope some find this amusing and not annoying. Perhaps someone know how to approach this issue toward a resolution. We have an in house commercial email system. Due to a re-organization, a number of our users are now required to use an o365 account, yet must still receive internal messages. To that end, I helped create internal account specific rules to forward all internal messages to the individual o365 accounts. We chose flat forward instead of as attachment. This appeared to work fine and does, for most messages. However, our org often sends an email to thousands of users with in our system. These messages fail to forward, bounced by o365 as header exceeds static size limit or to that effect. I can see that there are individual messages sent out to each recipient, as expected, yet each is bounced. If I forward the same message, as an attachment, it is not rejected. The same flat forward, sent to non o365 systems, do not get rejected. The o365 team maintains this is to be expected as o365 has a limit on the number of recipients that can be addressed in a single email. 500. I believe. I maintain they got a bug as each email is addressed to only one specific person, and should be interpreted that way, regardless of how may persons were addressed in the original header. If that is the correct term. The message envelope shows as well below their size limit. Am I wrong? If not, what can I pull of a hat to prove it?
restrict or alter to address based on from address
I confess to not having researched this, mainly as I have no clue how to search the subject effectively. So, with great trepidation, I timidly squeak out this question: Using postfix, is it possible to force a re-addressing of an email based on the sender of the message? To expand a bit, we envision retiring an existing email system, migrating but a small portion of the existing message store to the cloud. Yet, there will still be a need to access the old stuff and, occasionally, to act upon it. So, I am looking for a way to allow such messages to be forwarded to the users new address (or to a surrogate, so to speak) and to no other. Even better (he dares, as his courage builds), have the messages sent to only one recipient, say gategu...@someplace.com and have a virtual lookup table (loose terminology perhaps) to re-address the mail based on the sender address. Simple? or simple minded?
Re: restrict or alter to address based on from address
On 11/18/2014 at 4:02 PM, Wietse Venema wie...@porcupine.org wrote: I mis-stated the situation. Allow me to attempt to restate. There will be no address translation involved at all. The email address both user and domain will remain the same. The current system will be retired to an off line status yet the message store will remain accessible for various reasons, without the ability to actually send email to the outside world. I was daydreaming about ways to get messages from the old system to the new one, as might be required. For a bit it seemed feasible to cobble up something to allow messages to be sent via SMTP from the old system to the new, in a controlled and highly restricted manner. Having had some time to breath the free air again, I'm not so sure I should be allowed out without my leash. joe a. Joe Acquisto-j4: I confess to not having researched this, mainly as I have no clue how to search the subject effectively. So, with great trepidation, I timidly squeak out this question: Using postfix, is it possible to force a re-addressing of an email based on the sender of the message? This was not planned for as something that people would use a lot. But let's first find if this would really solve your problem. To expand a bit, we envision retiring an existing email system, migrating but a small portion of the existing message store to the cloud. Yet, there will still be a need to access the old stuff and, occasionally, to act upon it. So, I am looking for a way to allow such messages to be forwarded to the users new address (or to a surrogate, so to speak) and to no other. My big question is why would this need to depend on the sender address? If the sender sends mail to us...@old.example.com or us...@old.example.com, would not it make more sense to forward the message to a destination that depends on the user1 and user2 parts of the recipient address? Even better (he dares, as his courage builds), have the messages sent to only one recipient, say gategu...@someplace.com and have a virtual lookup table (loose terminology perhaps) to re-address the mail based on the sender address. It's easy enough to forward mail for old addresses to a single graveyard email address: us...@old.example.com graveyard+us...@new.example.com us...@old.example.com graveyard+us...@new.example.com (this requires Postfix recipient_delimiter=+). You can list graveyard+user1, graveyard+user2, etc. in a virtual alias map, or you can process the addresses with procmail or with a script that is invoked from ~graveyard/.forward. Wietse
shellshock via SMTP?
Comments on the ZD net article that claims shellshock exploit via crafty SMTP headers? Just asking, that's all . . . I attached a link to it below, please excuse if that is improper behavior. http://www.zdnet.com/shellshock-attacks-mail-servers-735094/
Multiple relay?
New to list, been using postfix for a little while. I would like to point a postfix install to two outbound relay's (all outbound mail to go thru them) so that, should one be unavailable, it will attempt to send via the other. Not round robin but fail over. This is probably simple, but have not found a clear description of how to. Is it as simple as adding a second IP, comma separated? Thanks.
illegal address syntax
Some mail from local (mynetworks) machines are getting mail rejected with warning: Illegal address syntax from blah in MAIL command: a b c This is despite resolve_numeric_domain = yes in main.cf, which I read was supposed to fix bad from address from scripts, etc. Wrong? joe a.
Re: illegal address syntax
Well, I can tell you it is SuSe 10, postfix 2.5 (mumble). Beyond that, I cannot divulge much more without running afoul of local security concerns. The author of the reporting scripts is reluctant, but willing, to correct the known issues, but I was hoping for some simple change that would ignore any syntax problem in the from address of email, from local/trusted sources, as this is likely to surface again as time goes on. Thanks for any assistance you can provide. li...@rhsoft.net li...@rhsoft.net 08/21/14 1:45 PM Am 21.08.2014 um 19:32 schrieb Joe Acquisto-j4: Some mail from local (mynetworks) machines are getting mail rejected with warning: Illegal address syntax from blah in MAIL command: a b c This is despite resolve_numeric_domain = yes in main.cf, which I read was supposed to fix bad from address from scripts, etc. Wrong? who knows since you don't post real logs http://www.catb.org/esr/faqs/smart-questions.html#beprecise in general: i have not seen illegal address syntax over the last 11 years from any of my scripts or software used inhouse and would throw away any device not fixable
Re: illegal address syntax
Please excuse the top posting, if that offends, as I am forced to use a web client that cannot bottom post. Easily. Here it is, only a bit obfuscated: Aug 21 13:18:07 some_machine postfix/smtpd[23306]: warning: Illegal address syntax from somehost.domedomain[aa.bb.cc.dd] in MAIL command: A Web server Script That's all there is on that line. Thanks for the assistance. joe a. DTNX Postmaster postmas...@dtnx.net 08/21/14 1:52 PM On 21 Aug 2014, at 19:32, Joe Acquisto-j4 j...@j4computers.com wrote: Some mail from local (mynetworks) machines are getting mail rejected with warning: Illegal address syntax from blah in MAIL command: a b c This is despite resolve_numeric_domain = yes in main.cf, which I read was supposed to fix bad from address from scripts, etc. Wrong? Post your actual error message, please. Your reinterpretation of it strips too much information. Mvg, Joni
Re: illegal address syntax
Thanks. We understood that the white space was at least the largest part of the issue, but since this setup was a replacement mail router for different mail system, which tolerated the white space, we were looking to make this change over as transparent to end users, even programmers, as painless as possible. Since we inflicted this burden on the apps community we were attempting to be as fraternal as possible. Seems to require a certain masochism on our part. g As you say, tho, there are limits. joe a. Wietse Venema wie...@porcupine.org 08/21/14 2:36 PM Joe Acquisto-j4: Well, I can tell you it is SuSe 10, postfix 2.5 (mumble). Beyond that, I cannot divulge much more without running afoul of local security concerns. The author of the reporting scripts is reluctant, but willing, to correct the known issues, but I was hoping for some simple change that would ignore any syntax problem in the from address of email, from local/trusted sources, as this is likely to surface again as time goes on. Postfix tolerates many mistakes, but it won't parse an address with unquoted whitespace. There is a limit to what I consider reasonable. People who run Postfix 2.8 or later can use smtpd_command_filter (http://www.postfix.org/postconf.5.html#smtpd_command_filter) to make minor corrections before Postfix parses command input. The documentation shows some examples. Something like: /^RCPT\s+TO:([^[:space:]]+ .+)@([^[:space:]]+.*)/ RCPT TO:$1@$2 would deal with unquoted spaces in an address. One can make it more precise if needed; that's left as an exercise for the reader. Wietse
Re: How to block offering SASL auth to clients based on RBL
On Sun, 8 Jun 2014, Kai Krakow wrote: Noel Jones njo...@megan.vbhcs.org schrieb: But I want to (automatically) block the suspicious networks and not first block all then whitelist the known-good. Not sure I completely understand the issue, but is this something where you could use fail2ban to monitor your logs in real time and autoban via iptables any ip that had failed logins? You could whitelist your own ip range so they never get bannned regardless. -- Joe Laffey The Stable Visual Effects http://TheStable.tv/?e34523M/
Re: How to block offering SASL auth to clients based on RBL
On Sun, 8 Jun 2014, li...@rhsoft.net wrote: Am 08.06.2014 17:18, schrieb Joe Laffey: On Sun, 8 Jun 2014, Kai Krakow wrote: Noel Jones njo...@megan.vbhcs.org schrieb: But I want to (automatically) block the suspicious networks and not first block all then whitelist the known-good. Not sure I completely understand the issue, but is this something where you could use fail2ban to monitor your logs in real time and autoban via iptables any ip that had failed logins? You could whitelist your own ip range so they never get bannned regardless. the idea of using a RBL is that you can setup your own honeypot like i did last weekend, feed your own RBL and most likely get only real bad bots and *before* they ever touch your machine our honeypot ist using free public IP's and listens on every common port writing every connecting IP into a RBL within a week 4 client IP's and 15%-20% don't expire after the configured 7 days because they come alaways back you can assume no customer ever will touch the honeypot Could you possibly set up a honeypot that feeds its logs via syslogging to your main server... then use fail2ban to ban ips from that log as well? You could even used separate regexes that matched only logs from the honeypot and have a much greater ban time on those. I do see the speed advantage to an RBL, and we used to run one that was mainly manually set up (using djbdns's rbl). I have just fallen in love with the auto operation of tools like fail2ban. Either way, the honeypot is a good idea to catch some known spammers. Though are we talking about spammers trying to guess SASL passwords, or ones that already have account credentials, or open relays? Note that I believe fail2ban could be setup with custom regexps to be used as a rate limiting tool for sending mail with valid credentials. Perhaps not the best solution for that, as it completely blocks the ip, but it would be automatic. -- Joe Laffey The Stable Visual Effects http://TheStable.tv/?e34525M/
Re: How to block offering SASL auth to clients based on RBL
On Sun, 8 Jun 2014, li...@rhsoft.net wrote: but why setup fail2ban at all if you have no sshd on standard ports and already a hyperfast rbldnsd running which scales over more than one server without touch any configuration frankly you can even use your RBL with web application firewalls http://blog.modsecurity.org/2010/09/advanced-topic-of-the-week-real-time-blacklist-lookups.html Interesting... Certainly much more scalable if you need that level of flexibility. I would still use fail2ban or similar on sshd on non-standrd ports. However, I hardly ever get hits on the non-standard sshd ports I have been using for well over 15 years. But this is a topic for another mailing list. -- Joe Laffey The Stable Visual Effects http://TheStable.tv/?e34526M/
initial 220 greeting delay from hosts with no RDNS
Hello,
I am experiencing an issue where hosts that do not have reverse DNS see an
extended delay (45-60 seconds for ssl or non-ssl connections) before they get
the initial 220 greeting. Hosts that do have properly registered entries get in
immediately. I have downloaded the source, and the programs that perform the
lookups gethostbyaddr, etc... all seem to return quickly enough. DNS on the
machine is also snappy and returns the lack of RDNS quickly. Setting
smtpd_peername_lookup to no solves the issue, but has other ramifications. The
server in question is running postfix 2.9.6-1 on ubuntu 12.04. A different
server with the same configuration does not seem to have the issue. Setting the
debug_peer for the hosts show the same thing for the hosts that experience a
delay versus those that do not, basically a bunch of match_hostaddr and
match_hostname calls. Once the initial delay is out of the way, everything
proceeds as normal.
Here is the postconf -n output, any suggestions?
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
mailbox_command = procmail -a $EXTENSION
mailbox_size_limit = 0
message_size_limit = 52428800
milter_default_action = accept
milter_protocol = 2
mydestination = /etc/postfix/local-host-names duke.cs.duke.edu cs.duke.edu
myhostname = duke.cs.duke.edu
mynetworks = /etc/postfix/local-host-names 152.3.140.177 152.3.140.0/23
152.3.144.0/23 152.3.136.0/23 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = cs.duke.edu
non_smtpd_milters = inet:localhost:8891
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (feed me)
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_rbl_client r.mail-abuse.com, warn_if_reject reject_unauth_pipelining,
permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname,
reject_invalid_helo_hostname, permit
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/expired, permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unauth_destination,
reject_unknown_recipient_domain, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain =
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated,
check_recipient_access hash:/etc/postfix/access, reject_unknown_sender_domain,
permit
smtpd_tls_CAfile = /etc/ssl/cacert.pem
smtpd_tls_cert_file = /etc/ssl/server.crt
smtpd_tls_key_file = /etc/ssl/server.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
tls_random_source = dev:/dev/urandom
Thanks,
Joe
--
Joe Shamblinw...@cs.duke.edu
Senior IT Analyst Department of Computer Science
(919) 660-6582 Duke University
smime.p7s
Description: S/MIME cryptographic signature
Re: initial 220 greeting delay from hosts with no RDNS
On May 27, 2014, at 2:38 PM, Wietse Venema wie...@porcupine.org wrote: Joe Shamblin: I am experiencing an issue where hosts that do not have reverse DNS see an extended delay (45-60 seconds for ssl or non-ssl connections) before they get the initial 220 greeting. Hosts that do have properly registered entries get in immediately. I have downloaded the source, and the programs that perform the lookups gethostbyaddr, etc... all seem to return quickly enough. DNS on the machine is also snappy and returns the lack of RDNS quickly. Setting smtpd_peername_lookup to no solves the issue, but has other ramifications. The server in question is running postfix 2.9.6-1 on ubuntu 12.04. A different server with the same configuration does not seem to have the issue. Setting the debug_peer for the hosts show the same thing for the hosts that experience a delay versus those that do not, basically a bunch of match_hostaddr and match_hostname calls. Once the initial delay is out of the way, everything proceeds as normal. Please TURN OFF chroot in master.cf. The master.cf entry should look like this: smtp inet n - n - - smtpd Then do postfix reload. More information: http://www.postfix.org/DEBUG_README.html#no_chroot Yes that did the trick, thanks very much. Though it seems to break sasl authentication without making other changes. I had seen that in the documentation, and as the all caps imply should have payed closer attention, but I did verify that the chroot environment seemed correct as well. As I mentioned I have two hosts running basically the same configuration (except the local hostnames), and one seems to work fine and the other not. I assume that the chrooted environment is slightly preferred due to security. Is there an expedient way to track down where the problem might be with the chrooted environment, or a likely candidate from the information in the first post? Thanks again! Joe -- Joe Shamblinw...@cs.duke.edu Senior IT Analyst Department of Computer Science (919) 660-6582 Duke University smime.p7s Description: S/MIME cryptographic signature
Re: Monitoring
+1 for mailgraph and queuegraph! Joe On 07/17/2013 05:23 AM, José Luís Faria wrote: I'm using http://mailgraph.schweikert.ch/ Em 17-07-2013 13:14, Roman Gelfand escreveu: Is there open source web based postfix server monitoring software? I am looking to see if there is something to monitor queue size, etc... Thanks in advance
Re: Mail server, what else?
On 07/13/2013 02:35 PM, Peter wrote: On 07/13/2013 11:15 AM, J Gao wrote: http://vault.centos.org/6.4/os/Source/SPackages/postfix-2.6.6-2.2.el6_1.src.rpm And patched with quota patch. That's brilliant, now you can't get support for it anywhere. You don't need to patch postfix to get quotas, dovecot 2 has a policy daemon that plugs right into postfix for that now. Seriously, go to Dovecot and get a newer version of postfix. It is well worth it just to get postscreen support (which requires version 2.8 or higher), and you really don't need to be patching it. Fairly current postfix packages for RHEL are available from several sources - we've been using postfix 2.8.8 on RHEL 6 here. Joe
Re: Bulk Mailing Performance
On 06/12/2013 12:17 PM, fletch wrote: The postfix performance claims made via this thread are far-fetched to say the least. Most postfix users will only see outbound throughput in the range of ~250,000/hour per instance in a production setting. Yet, people on here are claiming 10 million/hour? I guess that would be possible if a sender were to run, say, 40 postfix instances which would be a complete management nightmare of course. Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow would not be able to make any sales if the benefits of commercial software products v. open source were not substantial. In our experience, postfix can blast out messages at rates which are orders of magnitude faster than the other end is willing to receive it. The substantial benefits you speak of are mainly along the lines of easier management tools and integration of same with various other email related components in one convenient interface. Joe
how to tell postfix not to bounce when A: host not found?
Is there a config to tell posfix , to retry a email under A: host not found condition? May 23 15:59:22 mysmtp postfix/smtp[7507]: 92B8BCC3DE: to= t...@nosuchdomain.com, relay=none, delay=0.01, delays=0.01/0/0/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=nosuchdomain.com type=A: Host not found) - Joe
Re: how to tell postfix not to bounce when A: host not found?
Sent from my iPad On 24 May, 2013, at 1:27, wie...@porcupine.org (Wietse Venema) wrote: Joe Wong: Afaik this is the default behaviour. Postfix retries until queue_lifetime is exceeded. Are you experiencing something else? Can you show the logs, when the mail with queueid 92B8BCC3DE got into the system? It bounced right after the first attempt. That is what should happen. The DNS server replied that the destination does not exist. Postfix will retry when the DNS server is unavailable. This of course, assumes that the DNS server is working properly. If it replies with DOES NOT EXIST for other errors then all bets are off. You can kludge around this with soft_bounce=yes but that creates other problems, such as people never finding out that their mail is stuck in the queue. Wietse Thx Wietse.
Re: Postfix make install. Do not support mysql and pcre
Install the missing dev packages - mysql-devel, pcre-devel etc which will provide the missing headers. On 07/10/2012 10:36 AM, Feel Zhou wrote: Thanks for Brian's answer* * 1 I add the missed,such as [root@mail postfix-2.9.3]# make -f Makefile.init makefiles CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include AUXLIBS=-L/usr/local/mysql/lib -lmysqlclient and still have the problem, sorry about long log [root@mail postfix-2.9.3]# make set -e; for i in src/util src/global src/dns src/tls src/xsasl src/milter src/master src/postfix src/fsstone src/smtpstone src/sendmail src/error src/pickup src/cleanup src/smtpd src/local src/trivial-rewrite src/qmgr src/oqmgr src/smtp src/bounce src/pipe src/showq src/postalias src/postcat src/postconf src/postdrop src/postkick src/postlock src/postlog src/postmap src/postqueue src/postsuper src/qmqpd src/spawn src/flush src/verify src/virtual src/proxymap src/anvil src/scache src/discard src/tlsmgr src/postmulti src/postscreen src/dnsblog src/tlsproxy; do \ (set -e; echo [$i]; cd $i; make 'CC=gcc -Wmissing-prototypes -Wformat -DHAS_MYSQL -I/usr/local/mysql/include' update MAKELEVEL=) || exit 1; \ done [src/util] for i in argv.h attr.h attr_clnt.h auto_clnt.h base64_code.h binhash.h chroot_uid.h cidr_match.h clean_env.h connect.h ctable.h dict.h dict_cdb.h dict_cidr.h dict_db.h dict_dbm.h dict_env.h dict_ht.h dict_ni.h dict_nis.h dict_nisplus.h dict_pcre.h dict_regexp.h dict_sdbm.h dict_static.h dict_tcp.h dict_unix.h dir_forest.h events.h exec_command.h find_inet.h fsspace.h fullname.h get_domainname.h get_hostname.h hex_code.h hex_quote.h host_port.h htable.h inet_addr_host.h inet_addr_list.h inet_addr_local.h inet_proto.h iostuff.h line_wrap.h listen.h lstat_as.h mac_expand.h mac_parse.h make_dirs.h mask_addr.h match_list.h msg.h msg_output.h msg_syslog.h msg_vstream.h mvect.h myaddrinfo.h myflock.h mymalloc.h myrand.h name_code.h name_mask.h netstring.h nvtable.h open_as.h open_lock.h percentm.h posix_signals.h readlline.h ring.h safe.h safe_open.h sane_accept.h sane_connect.h sane_fsops.h sane_socketpair.h sane_time.h scan_dir.h set_eugid.h set_ugid.h sigdelay.h sock_addr.h spawn_command.h split_at.h stat_as.h stringops.h sys_defs.h timed_connect.h timed_wait.h trigger.h username.h valid_hostname.h vbuf.h vbuf_print.h vstream.h vstring.h vstring_vstream.h watchdog.h format_tv.h load_file.h killme_after.h edit_file.h dict_cache.h dict_thash.h ip_match.h nbbio.h base32_code.h dict_fail.h warn_stat.h; \ do \ cmp -s $i ../../include/$i 2/dev/null || cp $i ../../include; \ done cd ../../include; chmod 644 argv.h attr.h attr_clnt.h auto_clnt.h base64_code.h binhash.h chroot_uid.h cidr_match.h clean_env.h connect.h ctable.h dict.h dict_cdb.h dict_cidr.h dict_db.h dict_dbm.h dict_env.h dict_ht.h dict_ni.h dict_nis.h dict_nisplus.h dict_pcre.h dict_regexp.h dict_sdbm.h dict_static.h dict_tcp.h dict_unix.h dir_forest.h events.h exec_command.h find_inet.h fsspace.h fullname.h get_domainname.h get_hostname.h hex_code.h hex_quote.h host_port.h htable.h inet_addr_host.h inet_addr_list.h inet_addr_local.h inet_proto.h iostuff.h line_wrap.h listen.h lstat_as.h mac_expand.h mac_parse.h make_dirs.h mask_addr.h match_list.h msg.h msg_output.h msg_syslog.h msg_vstream.h mvect.h myaddrinfo.h myflock.h mymalloc.h myrand.h name_code.h name_mask.h netstring.h nvtable.h open_as.h open_lock.h percentm.h posix_signals.h readlline.h ring.h safe.h safe_open.h sane_accept.h sane_connect.h sane_fsops.h sane_socketpair.h sane_time.h scan_dir.h set_eugid.h set_ugid.h sigdelay.h sock_addr.h spawn_command.h split_at.h stat_as.h stringops.h sys_defs.h timed_connect.h timed_wait.h trigger.h username.h valid_hostname.h vbuf.h vbuf_print.h vstream.h vstring.h vstring_vstream.h watchdog.h format_tv.h load_file.h killme_after.h edit_file.h dict_cache.h dict_thash.h ip_match.h nbbio.h base32_code.h dict_fail.h warn_stat.h [src/global] gcc -Wmissing-prototypes -Wformat -DHAS_MYSQL -I/usr/local/mysql/include -g -O -I. -I../../include -DLINUX2 -c dict_mysql.c dict_mysql.c:169:19: error: mysql.h: No such file or directory dict_mysql.c:199: error: expected specifier-qualifier-list before ‘MYSQL’ dict_mysql.c:245: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token dict_mysql.c: In function ‘dict_mysql_lookup’: dict_mysql.c:290: error: ‘MYSQL_RES’ undeclared (first use in this function) dict_mysql.c:290: error: (Each undeclared identifier is reported only once dict_mysql.c:290: error: for each function it appears in.) dict_mysql.c:290: error: ‘query_res’ undeclared (first use in this function) dict_mysql.c:291: error: ‘MYSQL_ROW’ undeclared (first use in this function) dict_mysql.c:291: error: expected ‘;’ before ‘row’ dict_mysql.c:369: error: ‘row’ undeclared (first use in this function) dict_mysql.c: In function ‘dict_mysql_check_stat’: dict_mysql.c:392: error: ‘HOST’ has
Re: sender_dependent_default_transport_maps
On 05/07/2012 08:15 PM, Viktor Dukhovni wrote: On Mon, May 07, 2012 at 10:04:21PM -0500, Noel Jones wrote: We have some fairly involved routing requirements, and have been using a script that creates a transport table from a number of source files. It's been working well for some years, but now we have a need for sender-dependent transport rules. We periodically creates the sender_dependent_default_transport_maps, which appeared to work perfectly, but then we discovered that the transport table overrides sender-dependent transport - exactly as documented. We have a requirement for sender-dependent transport rules that override everything else. I thought of setting up another postfix instance just to handle the sender-dependent transport before handing it off to either the current smtp server or one of the designated transports, but it seems like overkill. Is there any other way to make sender_dependent_default_transport_maps take priority over the transport table? The transport priority order is not configurable. I suppose you could use a check_sender_access map that returns FILTER transport:nexthop for the target senders. Note this solution is only useful with mail submitted via SMTP and is incompatible with an after-queue content_filter (unless you do some master.cf gyrations). It also breaks mail routing on any real MTA that needs to route different recipients to different destinations. The only real use-case for sender-dependent routing is on shared laptops and home machines where all of a user's initially submitted mail is relayed via that user's ISP, but then one just empties out the transport table and voila, the default transport wins. My advice to the OP would be to separate the sender-dependent traffic onto a separate MTA that does no (normal) recipient dependent routing. Thanks for the sage advice - After some consideration and a bit of testing I think we finally have a reason for going to a multi-instance postfix configuration. It's either that, or spin up a new server to handle sender-dependent transport, and our support organization charges by the server, so postmulti seems to be the best option. Joe
sender_dependent_default_transport_maps
Hello list - We have some fairly involved routing requirements, and have been using a script that creates a transport table from a number of source files. It's been working well for some years, but now we have a need for sender-dependent transport rules. We periodically creates the sender_dependent_default_transport_maps, which appeared to work perfectly, but then we discovered that the transport table overrides sender-dependent transport - exactly as documented. We have a requirement for sender-dependent transport rules that override everything else. I thought of setting up another postfix instance just to handle the sender-dependent transport before handing it off to either the current smtp server or one of the designated transports, but it seems like overkill. Is there any other way to make sender_dependent_default_transport_maps take priority over the transport table? Thanks for your input - Joe
Re: SMTP Authentication
Sent from my iPad On 26 Mar, 2012, at 4:29, Patrick Ben Koetter p...@state-of-mind.de wrote: * KingT mr.kingcas...@gmail.com: I have just read SMTP Authentication and known have much type of it. Such as mail Submission, Extended SMTP, SASL. And I want to setup an SMTP AUTH on my mail server. Which type I should choose to implement ? If you plan to use Dovecot, use Dovecot SASL to configure Submission on Postfix. If you don't plan to use Dovecot, use Cyrus SASL to configure Submission on Postfix. p@rick -- All technical questions asked privately will be automatically answered on the list and archived for public access unless privacy is explicitely required and justified. saslfinger (debugging SMTP AUTH): http://postfix.state-of-mind.de/patrick.koetter/saslfinger/
Re: selecting outbound IP
I read the details of the multiple instance support but it's not clear to me how I can use it to achieve my goal. Do anyone have similar setup and share your configuration here? Many Thanks, - Joe On Tue, Feb 7, 2012 at 11:01 PM, Joe Wong joewon...@gmail.com wrote: Thanks Reindl. On Tue, Feb 7, 2012 at 10:33 PM, Reindl Harald h.rei...@thelounge.net wrote: http://www.postfix.org/MULTI_INSTANCE_README.html but never used because no need smtp_bind_address is here only in use to make sure that outgoing mail is using the ip matching SPF Am 07.02.2012 15:19, schrieb Joe Wong: Thanks for the reference. How could this be used with some condition? I am looking for binding sender domain A with IP 1 and domain B go through IP 2, go to IP3 otherwise. - Joe On Tue, Feb 7, 2012 at 8:00 PM, Wietse Venema wie...@porcupine.org wrote: Reindl Harald: Am 07.02.2012 09:53, schrieb Joe Wong: Hello, Say my MTA has multiple IP addresses on it. Is there a way to configure Postfix (outbound) to use IP 1 when matching condition A and IP2 if matching condition B and IP3 and none of the conditions are matched? you can define smtp_bind_address for each outgoing process defined in master.cf cat /etc/postfix/master.cf | grep smtp_bind smtp unix - - n - 50 smtp -o smtp_bind_address=10.0.0.6 -o max_idle=300 -o max_use=500 relay unix - - n - - smtp -o smtp_bind_address=10.0.0.6 -o max_idle=300 -o max_use=500 -o smtp_fallback_relay= If you do this on a firewall, then be sure to read the Postfix manpage for smtp_bind_address and inet_interfaces, to avoid some common pitfalls with routing. http://www.postfix.org/postconf.5.html#smtp_bind_address http://www.postfix.org/postconf.5.html#inet_interfaces Wietse -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm
Re: selecting outbound IP
Hello Andy, Sorry I should state the details initially. I am hosting multiple domains say joe.com jay.net some other domains I would like to route email sent from user in joe.com through IP address 1, user in jay.net via IP address 2, the rest go through IP address 3. after looking into the multiple instance support, I am not sure how this will work with my setup. Appreciated your opinion here. Best regards, - Joe On Thu, Feb 9, 2012 at 1:43 AM, Andrew Beverley a...@andybev.com wrote: On Wed, 2012-02-08 at 16:46 +0800, Joe Wong wrote: I read the details of the multiple instance support but it's not clear to me how I can use it to achieve my goal. Do anyone have similar setup and share your configuration here? Please don't top post. You'll have to give some more details as to what condition A and condition B are that define which outgoing IP address should be used. Andy
Re: selecting outbound IP
Hello Noel, The IP I mentioned was not the remote IP, but the IP address in the oubound MTA machine. - Joe On Thu, Feb 9, 2012 at 10:27 AM, Noel Jones njo...@megan.vbhcs.org wrote: On 2/8/2012 7:21 PM, Joe Wong wrote: Hello Andy, Sorry I should state the details initially. I am hosting multiple domains say joe.com jay.net some other domains I would like to route email sent from user in joe.com through IP address 1, user in jay.net via IP address 2, the rest go through IP address 3. The sender_dependent_default_transport_maps feature is intended exactly for this. See: http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps and the mail list archives. -- Noel Jones
Re: selecting outbound IP
On Thu, Feb 9, 2012 at 11:41 AM, Noel Jones njo...@megan.vbhcs.org wrote: On 2/8/2012 9:24 PM, Joe Wong wrote: Hello Noel, The IP I mentioned was not the remote IP, but the IP address in the oubound MTA machine. - Joe [please don't top post] Indeed. Use sender_dependent_default_transport_maps to select a transport defined in master.cf that is bound to a specific IP with ... -o smtp_bind_address=0.1.2.3 a brief example (you can find other examples in the archives): # master.cf #(these are copies of the smtp...smtp default transport) out_joe unix - - n - - smtp -o smtp_bind_address=192.0.1.10 out_bob unix - - n - - smtp -o smtp_bind_address=192.0.1.20 # main.cf sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport # sender_transport @joe.example.com out_joe: @bob.example.com out_bob: -- Noel Jones Thanks Noel. That means it does not need the multiple instance support at all. And sorry for the top-post :) - Joe
selecting outbound IP
Hello, Say my MTA has multiple IP addresses on it. Is there a way to configure Postfix (outbound) to use IP 1 when matching condition A and IP2 if matching condition B and IP3 and none of the conditions are matched? Thanks, - joe
Re: selecting outbound IP
Thanks for the reference. How could this be used with some condition? I am looking for binding sender domain A with IP 1 and domain B go through IP 2, go to IP3 otherwise. - Joe On Tue, Feb 7, 2012 at 8:00 PM, Wietse Venema wie...@porcupine.org wrote: Reindl Harald: Am 07.02.2012 09:53, schrieb Joe Wong: Hello, Say my MTA has multiple IP addresses on it. Is there a way to configure Postfix (outbound) to use IP 1 when matching condition A and IP2 if matching condition B and IP3 and none of the conditions are matched? you can define smtp_bind_address for each outgoing process defined in master.cf cat /etc/postfix/master.cf | grep smtp_bind smtp unix - - n - 50 smtp -o smtp_bind_address=10.0.0.6 -o max_idle=300 -o max_use=500 relay unix - - n - - smtp -o smtp_bind_address=10.0.0.6 -o max_idle=300 -o max_use=500 -o smtp_fallback_relay= If you do this on a firewall, then be sure to read the Postfix manpage for smtp_bind_address and inet_interfaces, to avoid some common pitfalls with routing. http://www.postfix.org/postconf.5.html#smtp_bind_address http://www.postfix.org/postconf.5.html#inet_interfaces Wietse
Re: selecting outbound IP
Thanks Reindl. On Tue, Feb 7, 2012 at 10:33 PM, Reindl Harald h.rei...@thelounge.net wrote: http://www.postfix.org/MULTI_INSTANCE_README.html but never used because no need smtp_bind_address is here only in use to make sure that outgoing mail is using the ip matching SPF Am 07.02.2012 15:19, schrieb Joe Wong: Thanks for the reference. How could this be used with some condition? I am looking for binding sender domain A with IP 1 and domain B go through IP 2, go to IP3 otherwise. - Joe On Tue, Feb 7, 2012 at 8:00 PM, Wietse Venema wie...@porcupine.org wrote: Reindl Harald: Am 07.02.2012 09:53, schrieb Joe Wong: Hello, Say my MTA has multiple IP addresses on it. Is there a way to configure Postfix (outbound) to use IP 1 when matching condition A and IP2 if matching condition B and IP3 and none of the conditions are matched? you can define smtp_bind_address for each outgoing process defined in master.cf cat /etc/postfix/master.cf | grep smtp_bind smtp unix - - n - 50 smtp -o smtp_bind_address=10.0.0.6 -o max_idle=300 -o max_use=500 relay unix - - n - - smtp -o smtp_bind_address=10.0.0.6 -o max_idle=300 -o max_use=500 -o smtp_fallback_relay= If you do this on a firewall, then be sure to read the Postfix manpage for smtp_bind_address and inet_interfaces, to avoid some common pitfalls with routing. http://www.postfix.org/postconf.5.html#smtp_bind_address http://www.postfix.org/postconf.5.html#inet_interfaces Wietse -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm
reject email sending to certain MX
Hello, is it possible to configure postfix not to send email with recipient domains to certain MX host? - Joe
Re: reject email sending to certain MX
Hi, I tried, it works but not the way I would like to implement. Say sender sent a email to 3 recipients, one of them hit the rule. What I want is sender will not get any bounce but the offending recipient will simply dropped, while the other 2 will still get the email. Is this possible? - Joe On Thu, Dec 15, 2011 at 9:37 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 12/15/2011 5:44 AM, Joe Wong wrote: Hello, is it possible to configure postfix not to send email with recipient domains to certain MX host? - Joe http://www.postfix.org/postconf.5.html#check_recipient_mx_access
