Expiration log messages
What log message should I look for when a message has been deferred and Postfix has decided it is undeliverable? (I'm parsing the log and need to know how to distinguish this from an actual bounce.) Will the log contain a 5xx message for that mail? This message was sent using IMP, the Internet Messaging Program.
recipient verification depending on relay (internal vs. external source)
We have an email gateway appliance at the network edge for spam/virus filtering. It relays mail to multiple postfix+imap servers behind the firewall. The back-end servers communicate directly with each other for internal mail accoss our VPN. The appliance will do smtp level recipient verification provided that our back-end services have it implemented. The problem is that we have some recipient addresses (linux /etc/alias entries as well as Active Directory distribution lists) that are intended for internal use only. We do not want these aliases to appear as valid recipients to the outside world. So, is there a way to configure postfix to report one set of valid recipients to our internal mail servers and clients and report a subset of valid recipients to the gateway appliance? I can easily break the recipient lists into separate maps, I just don't know how to apply them based on the address of the relay or client. The internal interface of the gateway appliance is on the same subnet as everything else, but does have a static IP address that could be used to identify it. # postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 inet_interfaces = $myhostname, localhost local_destination_concurrency_limit = 5 local_destination_recipient_limit = 300 local_recipient_maps = $alias_maps, ldap:/etc/postfix/ldap-users.cf, ldap:/etc/postfix/ldap-aliases.cf mail_owner = postfix mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mynetworks = 192.168.0.0/16, 127.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES sample_directory = /usr/share/doc/packages/postfix/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unverified_recipient transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 The ldap-alias.cf and ldap-users.cf are lookups for Active Directory distribution lists and real users. -- Jeff
What happens after 451 Temporary lookup failure
We recently enabled LDAP lookups (against Active Directory) for recipient verification. It's working great but I did get one "server error" message from the postfix daemon that had a session transcript that ended with: Out: 451 <[EMAIL PROTECTED]>: Temporary lookup failure In: RSET Out: 250 Ok In: QUIT Out: 221 Bye What is the end result of this? Does the sender see an immediate error? Does the sending MTA queue and retry? I have googled in vain for the answer. The LDAP lookup is configured for multiple domain controllers, but from the timestamp on the error, I am guessing that the error was generated just as the domain controller being queried was going down or coming up from a reboot. I don't suppose there is much else I can do about that. We did verify that lookups work when the first listed LDAP server is fully down, but apparently the openldap libs didn't handle this transient situation gracefully. Anyway, this is beside the point of my question. All I really want to know is if the message is lost after a 451. -- Jeff
Re: recipient verification depending on relay (internal vs. external source)
On Tue, Aug 12, 2008 at 3:23 PM, Noel Jones <[EMAIL PROTECTED]> wrote: > Jeff wrote: >> >> We have an email gateway appliance at the network edge for spam/virus >> filtering. It relays mail to multiple postfix+imap servers behind the >> firewall. The back-end servers communicate directly with each other >> for internal mail accoss our VPN. The appliance will do smtp level >> recipient verification provided that our back-end services have it >> implemented. The problem is that we have some recipient addresses >> (linux /etc/alias entries as well as Active Directory distribution >> lists) that are intended for internal use only. We do not want these >> aliases to appear as valid recipients to the outside world. >> >> So, is there a way to configure postfix to report one set of valid >> recipients to our internal mail servers and clients and report a >> subset of valid recipients to the gateway appliance? I can easily >> break the recipient lists into separate maps, I just don't know how to >> apply them based on the address of the relay or client. The internal >> interface of the gateway appliance is on the same subnet as everything >> else, but does have a static IP address that could be used to identify >> it. >> >> # postconf -n >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> command_directory = /usr/sbin >> config_directory = /etc/postfix >> daemon_directory = /usr/libexec/postfix >> debug_peer_level = 2 >> inet_interfaces = $myhostname, localhost >> local_destination_concurrency_limit = 5 >> local_destination_recipient_limit = 300 >> local_recipient_maps = $alias_maps, ldap:/etc/postfix/ldap-users.cf, >> ldap:/etc/postfix/ldap-aliases.cf >> mail_owner = postfix >> mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp >> mailq_path = /usr/bin/mailq.postfix >> manpage_directory = /usr/share/man >> mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain >> mynetworks = 192.168.0.0/16, 127.0.0.0/8 >> myorigin = $mydomain >> newaliases_path = /usr/bin/newaliases.postfix >> queue_directory = /var/spool/postfix >> readme_directory = /usr/share/doc/packages/postfix/README_FILES >> sample_directory = /usr/share/doc/packages/postfix/samples >> sendmail_path = /usr/sbin/sendmail.postfix >> setgid_group = postdrop >> smtpd_recipient_restrictions = permit_mynetworks, >> reject_unauth_destination, reject_unverified_recipient >> transport_maps = hash:/etc/postfix/transport >> unknown_local_recipient_reject_code = 550 >> >> The ldap-alias.cf and ldap-users.cf are lookups for Active Directory >> distribution lists and real users. >> > > > If all your internal clients are listed in mynetworks you can just create a > recipient blacklist and reject mail to those addresses when it arrives from > outside. > > # main.cf > smtpd_recipient_restrictions = > permit_mynetworks > reject_unauth_destination > check_recipient_access >hash:/etc/postfix/recipients > reject_unverified_recipient > > # recipients > internal-example.com REJECT restricted recipient > > For this to work, you may need to remove your gateway appliance from > mynetworks: > # main.cf > mynetworks = !ip.of.gate.way 192.168.0.0/16 127.0.0.0/8 It took me a while before I could test this. The recommended solution succeeds at blocking the specified aliases when relayed through our gateway, but it does not do so at the SMTP level. It generates bounce notifications, which in the end will create back-scatter. The bounce message I got in testing gave an error code of 554. Some additional background: Our gateway appliance acts as a proxy for recipient verification. When the gateway wants to test for a valid recipient, it opens an SMTP connection to the appropriate back-end server and pretends to send a mail to the recipient from [EMAIL PROTECTED] If it get's a 550 from the back-end, it returns 550 to the sending MTA. So it seems that when it receives a 554 from the internal server as it did in this case, the gateway creates a bounce message instead of immediately notifying the external MTA of the failure. Can I tweak this so that the map in check_recipient_access returns 550 instead of 554? -- Jeff
Re: recipient verification depending on relay (internal vs. external source)
On Tue, Aug 19, 2008 at 11:38 AM, Wietse Venema <[EMAIL PROTECTED]> wrote: > Jeff: >> It took me a while before I could test this. The recommended solution >> succeeds at blocking the specified aliases when relayed through our >> gateway, but it does not do so at the SMTP level. It generates bounce >> notifications, which in the end will create back-scatter. The bounce >> message I got in testing gave an error code of 554. > > Sorry, reject_unverified_recipient does not generate backscatter. > If you believe this is not so, then you need to provide actual > evidence so that we can point out your mistake. > >Wietse Exactly! I can't figure out why I'm getting bounces instead of rejects. I did (moments after clicking "send") discover in "man -s 5 access" that I can put the reject code (550) directly in the map. However, I am still getting bounces when I send mail to the private address I am using for testing. Updated config on the back-end MTA... # postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 html_directory = no inet_interfaces = $myhostname, localhost local_destination_concurrency_limit = 5 local_destination_recipient_limit = 300 local_recipient_maps = $alias_maps, $virtual_alias_maps, ldap:/etc/postfix/ldap-users.cf mail_owner = postfix mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mynetworks = !192.168.1.65, 192.168.0.0/16, 127.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES sample_directory = /usr/share/doc/postfix-2.2.10/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/private-aliases, reject_unverified_recipient transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf # cat /etc/postfix/private-aliases [EMAIL PROTECTED] 550 User unknown Perhaps the way in which I added "check_recipient_access" has broken my standard recipient verification. Using telnet to port 25 from my gateway box (for which the special restrictions should apply) to the back-end MTA, I get: RCPT TO: [EMAIL PROTECTED] 550 <[EMAIL PROTECTED]>: Recipient address rejected: User unknown Which is appears correct. Yet, the gateway still sends a bounce. I don't know why. Again, maybe just not exactly what the gateway expects. Does not appear to be the fault of the back-end postfix. But for an actual non-existent user, I now get RCPT TO:[EMAIL PROTECTED] 450 <[EMAIL PROTECTED]>: Recipient address rejected: undeliverable address: host /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command) Here, the recipient lookup does not appear to be happening and postfix is attempting to deliver to cyrus-imap via lmtp, which fails. Previous to this attempted implementation (adding check_recipient_access as suggested), I was getting (correctly): RCPT TO:[EMAIL PROTECTED] 550 <[EMAIL PROTECTED]>: Recipient address rejected: User unknown in local recipient table The gateway treats this properly and relays the reject to the external MTA. So I guess I am back to the original question: What is the proper way to reject specific recipients from the gateway, yet allow them from internal MTAs? And, how can I do it in a fashion that appears to the gateway identical to the response for a truly non-existent user -- Jeff
Re: recipient verification depending on relay (internal vs. external source)
On Tue, Aug 19, 2008 at 1:43 PM, Wietse Venema <[EMAIL PROTECTED]> wrote: > Jeff: >> On Tue, Aug 19, 2008 at 11:38 AM, Wietse Venema <[EMAIL PROTECTED]> wrote: >> > Jeff: >> >> It took me a while before I could test this. The recommended solution >> >> succeeds at blocking the specified aliases when relayed through our >> >> gateway, but it does not do so at the SMTP level. It generates bounce >> >> notifications, which in the end will create back-scatter. The bounce >> >> message I got in testing gave an error code of 554. >> > >> > Sorry, reject_unverified_recipient does not generate backscatter. >> > If you believe this is not so, then you need to provide actual >> > evidence so that we can point out your mistake. >> > >> >Wietse >> >> Exactly! I can't figure out why I'm getting bounces instead of rejects. > > That's because your configuration does not work the way you describe it. > >> I did (moments after clicking "send") discover in "man -s 5 access" >> that I can put the reject code (550) directly in the map. However, I >> am still getting bounces when I send mail to the private address I am >> using for testing. >> >> Updated config on the back-end MTA... > > Of course, reject_unverified_recipient is meaningful only when > tun on the FRONT END MTA. > It IS turned on on the front end MTA. But the front end gateway depends on having recipient verification functioning on the back-end servers. The gateway has no knowledge of actual user accounts. The gateway acts as a proxy for recipient verification. When an external MTA is sending a message, the gateway contacts the back-end MTA to verify the recipient (using a dummy MAIL FROM and RCPT TO), then responds to the external MTA accordingly. I want the back-end to tell the front-end gateway 550 for [EMAIL PROTECTED], but I want it to tell my other internal MTAs OK, whilst not breaking regular recipient verification. -- Jeff
Re: recipient verification depending on relay (internal vs. external source)
On Tue, Aug 19, 2008 at 2:16 PM, Wietse Venema <[EMAIL PROTECTED]> wrote: > Jeff: >> I want the back-end to tell the front-end gateway 550 for >> [EMAIL PROTECTED], but I want it to tell my other internal MTAs OK, >> whilst not breaking regular recipient verification. > > Reject [EMAIL PROTECTED] on the FRONT_END host. > > smtpd_recipient_restrictions = >check_recipient_access hash:/etc/postfix/access >...stuff... >reject_unauth_destination >...stuff... >reject_unverified_recipient >...stuff... > > /etc/postfix/access >[EMAIL PROTECTED]reject > Except that the front end is a mail gateway APPLIANCE. It is linux/postfix based, but has many proprietary additions and it is not intended to be customized outside what is made available in it's web interface. I have asked the vendor for a new feature to do SMTP level rejects based on a blacklist, but they have not commented on it and currently offer only the aforementioned relay to back-end SMTP recipient verification or bounce notifications based on a front-end blacklist.We currently use the bounce option, but it is generating back-scatter to our postmaster address. My other option on the gateway is to just be a black-hole for these private addresses (accept, but neither deliver nor notify) but I see that as an ill-behaved way to run a mail service. Yes, the appliance has some imperfections, but generally does just what we need. Thus I am trying to solve this problem with back-end recipient verification. -- Jeff
[OT] Using [EMAIL PROTECTED] [was: best way for website sending emails]
On Mon, Aug 25, 2008 at 9:46 AM, Tony Holmes <[EMAIL PROTECTED]> wrote: >> I want the From address to be set to something like [EMAIL PROTECTED] >> A mail sent to this address will cause no error, but nobody will >> read those emails. > > That is a very very bad idea and the best way to have your server added to > many RBLs. > I'm afraid I don't see how sending mail with an unmonitored return address (i.e., accepted and delivered locally to /dev/null) will get you on an RBL. I get mail of that type from big companies all the time. They usually have something in the message that explains that you should not reply and that replies will not be read. Could someone expand on the RBL comment? We have reason to do this for messages that provide automated information but are not intended to start a dialogue with the customer. Why is this wrong? It seems to be a rather common practice. -- Jeff
recipient bcc maps
I have recipient_bcc_maps set up and configured correctly on a per-user basis: [EMAIL PROTECTED] [EMAIL PROTECTED] How would I do this for an entire domain? Would it be: [EMAIL PROTECTED] [EMAIL PROTECTED] Or would it be @domain.tld [EMAIL PROTECTED] Thanks!
Re: recipient bcc maps
> Jeff wrote: >> I have recipient_bcc_maps set up and configured correctly on a per-user >> basis: >> [EMAIL PROTECTED] [EMAIL PROTECTED] >> >> How would I do this for an entire domain? Would it be: >> [EMAIL PROTECTED] [EMAIL PROTECTED] >> >> Or would it be >> @domain.tld [EMAIL PROTECTED] >> >> Thanks! >> > > > http://www.postfix.org/postconf.5.html#recipient_bcc_maps > > I'm unclear on that (multiple original recipients, or multiple destination bcc's?). Does it mean that multiples can only be handled by using always_bcc then?
Return-Path and Errors-To not behaving as expected
I have a shell script that generates simple emails by piping text (with To, From and Subject headers) to 'sendmail -t' (the postfix version). All is well with that except when a message bounces. The failure notice comes back to the user that ran the script. The script is run from cron under an administrative account. I would prefer to redirect bounces to a customer service agent that can deal with it. So I tried inserting "Return-Path: [EMAIL PROTECTED]" in the headers, but they still bounced to the script user. Same deal with inserting "Errors-To: [EMAIL PROTECTED]". I have verified that [EMAIL PROTECTED] is deliverable. In the first case, my manual Return-Path header was replaced with the script user address. In the second case, I can see my Errors-To header, but a Return-Path header is also inserted (by postfix/sendmail?) with the script user address. What am I doing wrong? http://www.postfix.org/sendmail.1.html says that Errors-To overrides command line options to sendmail, so why is it not heeded when no return path command line options are used? If possible, I would like the bounce address to be something that is not normally displayed by common mail clients. -- Jeff
Implementing autoreply for all received mail (including internally forwarded)
Hi: I am hoping I can ask for suggestions or pointers to help solve this challenge. I am trying to implement an autoreply capability. I am putting together a script that will handle the messages. Many of the autoreply examples I've found suggest implementing this by: main.cf: always_bcc = autoreply local_alias_maps: autoreply '|/path/to/autoreply/script' effectively causing all mail sent to anyone to be bcc'ed to the script, which then determines if an autoreply needs to be sent. This also ensures that delivery to the intended recipient (in my case, they are all virtual mailboxes) will also happen. However, as I started to test this, I discovered a limitation that I am having difficulty finding a solution for. The scenario is that one user on one domain that I host sends mail to another user at another domain that I host. The recipient has autoreply "turned on" in my script. However, according to http://www.postfix.com/ADDRESS_REWRITING_README.html : "To avoid mailer loops, automatic BCC recipients are not generated for mail that Postfix forwards internally" and the actual behavior matches that statement. So my question: Is there another mechanism I can use to send the mail to the script without interfering with normal mail delivery in all cases , including this internally forwarded mail? Or, is there another way to handle autoreplies that anyone can suggest or point me to that avoids this issue? (I don't want all mail forwarded to the script, as I do not want to - and am not sufficiently proficient to - handle reinjection into postfix and the associated handling of SMTP/LMTP protocol) Thank you very much for any help or pointers you can offer!
Can recipient_bcc_maps be over-riden in master.cf?
Hi: I am having a problem with duplicate bcc's (from recipient_bcc_maps) and I suspect I know why - but I hope someone can point me to a solution. I have a content filter set up for dspam (content_filter = dspam:dspam in main.cf) set up as described in the "Advanced content filter example" section of http://www.postfix.com/FILTER_README.html - it works fine. Now I've added the ability for selected virtual mailbox addresses to trigger recipient_bcc_maps so that a bcc is generated to a specific address only when mail is sent to designated recipients. This is where the problem arises. When mail arrives, the bcc is generated and sent. Then when the mail is injected back into postfix after the content filter, another bcc is generated and sent. The secind bcc is, of course, undesireable. I tried adding: -o recipient_bcc_maps= to the overrides for localhost:10026 (where dspam reinjects the mail) but that did not change the behavior. It still generated the second bcc. I don't see this documented per se (am I missing something?), but can recipient_bcc_maps be over-riden this way? If not, is there another way to avoid the second bcc? Thank you for any help, pointers and/or advice you can offer!!
Finding the envelope-sender after always_bcc?
Hi: After reading http://www.irbs.net/internet/postfix/0703/1471.html and http://www.irbs.net/internet/postfix/0703/1519.html to help with my autoreply capability (and making sure i get it as close to "right" as possible!), I am trying to ensure that I can take all reasonable measures to get the autoreplies right (when they are sent). to this end, it's important that I capture the envelope-sender of each message in addition to the "From:" header, but I am having difficulty doing so. I have tried to send the message to my autoreply script via bcc: (via always_bcc or recipient_bcc_maps) to a local autoreply address which then has the transport autoreply: which calls the autoreply script via pipe or is a local alias that resolves to '|/path/to/autoreply/ script'. The transport mechanism has the ability to pass information from postfix, but doesn't seem to capture the envelope-sender correctly. I have tried using every single one of the macros listed in http://www.postfix.com/pipe.8.html to no avail. I have even used some macros that are not listed, but I've found in other examples as I've searched for solutions. This happens with mail sent to alias addresses as well as virtual mailboxes. Some e-mails from lists to which I subscribe include a "Sender: " header which looks like it contains the envelope-sender. Mail that shows up in my standard ISP account (not ever touching my postfix installation) seems to include the "Return-Path: " header which includes the envelope-sender. Leading me to two questions: 1) on-topic: How can I be sure I can find the envelope-sender for every message and pass that to my script? Or maybe I should ask it this way: How do I get postfix to keep the correct envelope-sender? 2) broader: Is the list of macros that can be used as arguments to a pipe command (as listed in http://www.postfix.com/pipe.8.html) complete? or are there others (like the ones I've found)? and where can I find a complete list? I would appreciate any help, direction or pointers that anyone can offer. It might help to know that messages entering my postfix server are then passed to a content_filter (Dspam, specifically, using content_filter=dspam:dspam), which then re-injects them back into postfix which then handles them and sends them to a delivery agent (mostly maildrop, sometimes virtual). If the order of this (and the passing through dpsam is affecting the envelope-sender, is there way to either get the message to the autoreply script before it goes to dspam (I don't want that, since I don't autoreply to spam messages) or a way to pass the envelope-sender through dpsam, or something else I haven't considered? Thank you!! and happy new year!!
Re: Finding the envelope-sender after always_bcc?
On Dec 31, 2008, at 6:11 PM, mouss wrote:
Jeff Weinberger a écrit :
Hi:
After reading http://www.irbs.net/internet/postfix/0703/1471.html and
http://www.irbs.net/internet/postfix/0703/1519.html to help with my
autoreply capability (and making sure i get it as close to "right" as
possible!), I am trying to ensure that I can take all reasonable
measures to get the autoreplies right (when they are sent). to this
end,
it's important that I capture the envelope-sender of each message in
addition to the "From:" header, but I am having difficulty doing so.
yes, don't reply to From: addresses. if you can't get the envelope
sender, don't autoreply.
I have tried to send the message to my autoreply script via bcc: (via
always_bcc or recipient_bcc_maps) to a local autoreply address which
then has the transport autoreply: which calls the autoreply script
via
pipe or is a local alias that resolves to '|/path/to/autoreply/
script'.
The transport mechanism has the ability to pass information from
postfix, but doesn't seem to capture the envelope-sender correctly.
The envelope sender should be found in the Retrun-Path header. when
using a pipe, make sure to put the 'R' flag in the "flags=..."
options.
you can also use -f ${sender} in your pipe and have your scrpit parse
command line args.
I have tried using every single one of the macros listed in
http://www.postfix.com/pipe.8.html to no avail. I have even used some
macros that are not listed, but I've found in other examples as I've
searched for solutions.
This happens with mail sent to alias addresses as well as virtual
mailboxes.
Some e-mails from lists to which I subscribe include a "Sender: "
header
which looks like it contains the envelope-sender. Mail that shows
up in
my standard ISP account (not ever touching my postfix installation)
seems to include the "Return-Path: " header which includes the
envelope-sender.
Leading me to two questions:
1) on-topic: How can I be sure I can find the envelope-sender for
every
message and pass that to my script? Or maybe I should ask it this
way:
How do I get postfix to keep the correct envelope-sender?
always_bcc does not change the envelope sender (it changes the
envelope
recipient). so you get the "correct" envelope sender.
2) broader: Is the list of macros that can be used as arguments to a
pipe command (as listed in http://www.postfix.com/pipe.8.html)
complete?
or are there others (like the ones I've found)? and where can I
find a
complete list?
I would appreciate any help, direction or pointers that anyone can
offer.
It might help to know that messages entering my postfix server are
then
passed to a content_filter (Dspam, specifically, using
content_filter=dspam:dspam), which then re-injects them back into
postfix which then handles them and sends them to a delivery agent
(mostly maildrop, sometimes virtual). If the order of this (and the
passing through dpsam is affecting the envelope-sender, is there
way to
either get the message to the autoreply script before it goes to
dspam
(I don't want that, since I don't autoreply to spam messages) or a
way
to pass the envelope-sender through dpsam, or something else I
haven't
considered?
check your logs to see if the envelope sender is present at delivery
time. if your content filters and other stuff reinjects mail using the
sendmail command, make sure to use -f to passe the (original)
envelope-sender.
Thank you!
I've verified that the "R" flag is there and I use -f ${sender} on the
command line (the script does parse the arguments)
I think the envelope-sender is missing before it enters the content
filter. This from my mail.log:
Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74:
from=, size=1505, nrcpt=1 (queue active)
Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]
Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO ONLY -
NOT AN ERROR): see sql.errors for more details
Dec 31 19:50:09 s postfix/smtpd[3348]: connect from localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
client=localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79: message-id=>
Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>,
size=2936, nrcpt=1 (queue active)
Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from
localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74: to=>, relay=dspam, delay=5.1, delays=3.4/0/0/1.7, dsn=2.0.0, status=sent
(delivered via dspam service)
(identifying information removed)
The "from=<>" in the third-to-last line I assume should be the
envelope-sender?
This happens whether I send from my ISP mail address, another locally-
hosted virtual mailbox or anywhere else.
Is this part of the problem?
If so, where can I start to look for a solution? or what information
would be helpful?
Thank you!
Re: Finding the envelope-sender after always_bcc?
mouss wrote:
Jeff Weinberger a écrit :
>
> I've verified that the "R" flag is there and I use -f ${sender} on
the
> command line (the script does parse the arguments)
>
> I think the envelope-sender is missing before it enters the content
> filter. This from my mail.log:
>
> Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=>,
> size=1505, nrcpt=1 (queue active)
> Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
> smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]
> Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO
ONLY -
> NOT AN ERROR): see sql.errors for more details
> Dec 31 19:50:09 s postfix/smtpd[3348]: connect from
localhost[1270.0.1]
> Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
> client=localhost[127.0.0.1]
> Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
> message-id=
> Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>,
size=2936,
> nrcpt=1 (queue active)
> Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from
localhost[127.0.0.1]
> Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
> to=, relay=dspam, delay=5.1,
> delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam
service)
>
> (identifying information removed)
>
> The "from=<>" in the third-to-last line I assume should be the
> envelope-sender?
>
yes. when mail is passed back to postfix, something loses the
envelope-sender. how do you pass mail from dspam to postfix?
From this log entry it looks like the envelope sender is empty before
the mail is send to dspam - the "from=<>" three lines before the mail
is delivered to dspam makes me think this.
When I look at the log entries for the message when it comes back into
postfix from dspam the envelope sender is also empty (again "from=<>"
So isn't there something losing the envelope sender before it ever
gets to dspam?
but to answer your question directly, dspam re-injects the mail into
postfix using SMTP on an alternate port, the same way as is
illustrated in the CONTENT_FILTER_README for an after-queue content
filter.
Does that help? or point to anything?
Re: Finding the envelope-sender after always_bcc?
On Jan 1, 2009, at 9:31 AM, mouss wrote:
jeff_homeip a écrit :
--- In post...@yahoogroups.com, mouss wrote:
Jeff Weinberger a écrit :
I've verified that the "R" flag is there and I use -f ${sender}
on the
command line (the script does parse the arguments)
I think the envelope-sender is missing before it enters the content
filter. This from my mail.log:
Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=,
size=1505, nrcpt=1 (queue active)
look at the queue-id: A4C5E2943D74
Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]
postfix disconnects from 69.147.64.93.
Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO
ONLY -
NOT AN ERROR): see sql.errors for more details
dspam barks. so dspam got the message.
Dec 31 19:50:09 s postfix/smtpd[3348]: connect from
localhost[127.0.0.1]
dspam connects to postfix (after the filter smtpd).
Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
client=localhost[127.0.0.1]
this dspam connection has a queue-id of 646A62943D79
Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
message-id=
Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>,
size=2936,
nrcpt=1 (queue active)
the envelope sender is empty for queue-id 646A62943D79, which
corresponds to dspam re-injection. so dspam has reinjected the message
with an empty sender.
Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from
localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
to=, relay=dspam, delay=5.1,
delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam
service)
once dspam has delivered the message, postfix tells you that the
original transaction was delivered. this comes late because dspam does
not queue mail, so postfix can't know that delivery _will_ succeed.
[snip]
From this log entry it looks like the envelope sender is empty
before the mail is send to
dspam - the "from=<>" three lines before the mail is delivered to
dspam makes me think
this.
don't rely on the order of log lines. Instead, look at the queue-id:
A4C5E2943D74 is the queue-id when postfix received the message from
the
network. 646A62943D79 is the queue-id when postfix received the
message
from localhost, which should be dspam re-injection.
When I look at the log entries for the message when it comes back
into postfix from
dspam the envelope sender is also empty (again "from=<>"
see above. the log doesn't tell you "I am about to pass mail to
dspam".
it tells you "mail was delivered, and it was done via dspam". This
means
that dspam took the message and said "OK" to postfix, and since dspam
doesn't have a queue manager, this means that the message was already
filtered and passed to postfix/smtpd (the "after the filter" one).
So isn't there something losing the envelope sender before it ever
gets to dspam?
but to answer your question directly, dspam re-injects the mail
into postfix using SMTP on
an alternate port, the same way as is illustrated in the
CONTENT_FILTER_README for an
after-queue content filter.
so the problem is in dspam.
Does that help?
I asked just to make sure it was not passing the message to something
else that does the re-injection.
Thank you! That helps clarify what I was missing in this - so clearly
dspam is not passing the envelope sender back to postfix.
I suspect it doesn't know how via SMTP, but it can also use the
sendmail command to do this. I will experiment with this.
would the correct command be "/usr/sbin/sendmail -f" ?
thanks!
Re: Finding the envelope-sender after always_bcc?
On Jan 1, 2009, at 9:49 AM, mouss wrote: Jeff Weinberger a écrit : Thank you! That helps clarify what I was missing in this - so clearly dspam is not passing the envelope sender back to postfix. I suspect it doesn't know how via SMTP, but it can also use the sendmail command to do this. I will experiment with this. no, keep using smtp. just check your setup (and see why dspam barks about sql errors). ask on the dspam list. If you wnat to keep using dspam, you should follow the (recent) fork: http://www.dspam-community.org would the correct command be "/usr/sbin/sendmail -f" ? yes, but smtp is better. Thank you! I will ask on the dspam list about this. I've been reading the dspam docs this morning and the project owner states fairly strongly that sendmail is far preferable to SMTP re- injection (in the postfix setup docs), but doesn't say why. I don't know enough about the workings of dspam (yet) to know, but I'd tend to agree with you on the use of SMTP as more desirable. dspam has always had this mysql issue, which is related to its database of spam tokens, and I'll look into whether it might be related. Thank you for your help!
issue connecting to mysql after upgrade
Hello again: One more issue on which I would appreciate any help anyone can offer: Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and my MySQL installation from 5.0.51b to 5.0.75. Immediately after restarting everything (the whole computer), I started seeing these messages in my mail log: Jan 1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:35 s postfix/cleanup[13201]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:42 s postfix/trivial-rewrite[13205]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) As far as I can tell this has been consistent with smtpd, cleanup and trivial-rewrite, but nothing else. (there have been pre-existing issues, per my prior conversation with mouss, with dspam, but these have not changed at all - they existed before the upgrade and still exist) I use mysql for nearly all my tables in postfix. All of my aliases are working and forwarding fine, which means that postfix can access my mysql database (and yes, postconf -m shows mysql). virtual is finding the maildirs correctly for my virtual mailboxes. However, my sender_canonical_maps are no longer working after the upgrade (outbound addresses are not being rewritten at all as they were before the upgrade) As an example, my main.cf contains: sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf and mysql_canonical_maps.cf contains: user = postfixuser password = postfixpassword hosts = localhost, 127.0.0.1 dbname = postfixdatabase query = SELECT result FROM canonical WHERE address='%s' AND active='Y' (obvious information changed). This is unchanged before and after the upgrade. The query works on all the addresses (I tested it at the mysql command prompt). I also tested a local telnet to 127.0.0.1 on port 3306 which worked as expected and mysql responds perfectly. I also tested connection through the localhost socket with works as expected. Also several other parts of my mail system (e.g. courier_auth) connect through the socket and report success. And as noted, postfix is able to connect most of the time (aliases, virtual maildirs, etc.). Other software on my system, e.g. PHP, is also able to connect to mysql successfully. I tried all the steps in the MySQL documentation on dev.mysql.com suggested to diagnose this error, and all confirmed that the MySQL server is working correctly. So I find myself not knowing where to look next, and I hope someone here knows what might be happening or at least be able to point me in the right direction. One additional piece of information: I am running on Mac OS/X and as part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus needing to restart my computer). This upgrade is known to break postfix. So I reinstalled postfix and my main.cf and master.cf files after the upgrade and stopped and restarted postfix to be sure. (and mysql) What other information might be helpful in diagnosing this? Thank you for any help you can offer!
Re: issue connecting to mysql after upgrade
On Jan 1, 2009, at 1:55 PM, mouss wrote: Jeff Weinberger a écrit : Hello again: One more issue on which I would appreciate any help anyone can offer: Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and my MySQL installation from 5.0.51b to 5.0.75. Immediately after restarting everything (the whole computer), I started seeing these messages in my mail log: Jan 1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:35 s postfix/cleanup[13201]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:42 s postfix/trivial-rewrite[13205]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) As far as I can tell this has been consistent with smtpd, cleanup and trivial-rewrite, but nothing else. (there have been pre-existing issues, per my prior conversation with mouss, with dspam, but these have not changed at all - they existed before the upgrade and still exist) I use mysql for nearly all my tables in postfix. All of my aliases are working and forwarding fine, which means that postfix can access my mysql database (and yes, postconf -m shows mysql). virtual is finding the maildirs correctly for my virtual mailboxes. However, my sender_canonical_maps are no longer working after the upgrade (outbound addresses are not being rewritten at all as they were before the upgrade) As an example, my main.cf contains: sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf and mysql_canonical_maps.cf contains: user = postfixuser password = postfixpassword hosts = localhost, 127.0.0.1 dbname = postfixdatabase query = SELECT result FROM canonical WHERE address='%s' AND active='Y' (obvious information changed). This is unchanged before and after the upgrade. The query works on all the addresses (I tested it at the mysql command prompt). I also tested a local telnet to 127.0.0.1 on port 3306 which worked as expected and mysql responds perfectly. I also tested connection through the localhost socket with works as expected. Also several other parts of my mail system (e.g. courier_auth) connect through the socket and report success. And as noted, postfix is able to connect most of the time (aliases, virtual maildirs, etc.). Other software on my system, e.g. PHP, is also able to connect to mysql successfully. I tried all the steps in the MySQL documentation on dev.mysql.com suggested to diagnose this error, and all confirmed that the MySQL server is working correctly. So I find myself not knowing where to look next, and I hope someone here knows what might be happening or at least be able to point me in the right direction. One additional piece of information: I am running on Mac OS/X and as part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus needing to restart my computer). This upgrade is known to break postfix. So I reinstalled postfix and my main.cf and master.cf files after the upgrade and stopped and restarted postfix to be sure. (and mysql) What other information might be helpful in diagnosing this? - check whether any services are chrooted in master.cf (the 5th field must be set to 'n' and not to 'y' or '-')? All chroot flags are set to "n" - try using proxymap (foo_maps=proxy:mysql:/etc/). Tried this...no change :( - make sure the mysql socket is accessible by postfix (and not just by root). I checked looking at permissions and trying it as the postfix user and all works (I suspected it would, as many accesses work fine (aliases, etc. as I noted earlier) - try with "hosts = 127.0.0.1" (without "localhost") Tried this - no change. :( I tried each of the suggestions you made with alias, virtual and local addresses I noticed that when local complained about mysql access, it still did fine looking up the local alias and forwarding it correctly. I'm starting to wonder whether this is a "can't connect" or a delay in connecting - is it possible that it's taking too long to connect so a warning is reported, but the connection happens eventually? or that it works on a retry? The only thing I've found that doesn't work as expected is sender_canonical_maps which would invalidate this theory, but the local behavior makes me think it's a possibility? Alternatively, is it possible that something in the mysql capabilities of postfix compiled wrong? I am not that familiar with gcc and the build process (I use what I know works) - is there something I can look at in the ./configure or make output that would tell me? I did try rebuilding (./configure,. make, make in
Re: issue connecting to mysql after upgrade
On Jan 1, 2009, at 4:53 PM, mouss wrote: Jeff Weinberger a écrit : [snip] - try with "hosts = 127.0.0.1" (without "localhost") Tried this - no change. :( ahem. if you do this, you should not hear about a socket. it should use a TCP connection. can you show the errors? I would think so also. I'm at a loss here, but I think this is no longer a problem. i was able to turn on very verbose logging in mysql, and it turns out that all the queries are in fact being made. I also have to confess to a bit of stupidity about my own ability to hold enough configuration information in my head (making postfix much smarter than I am!). I have dspam set to filter all mail both inbound and outbound (this has to change, but served the purpose when I initially set it up. And to stop multiply always_bcc results, specified "-o receive_override_options=no_address_mappings" in the master.cf entry for re-injection. the pipe to dspam is case-folding and then the sender_canonical_maps are being ignored. I didn't event think to look at this as a reason canonical was failing. I apologize sincerely for taking so much time and effort to get here and for leading you down this path. But still I appreciate the help. This will help me clean up this set of configuration issues. As to the warnings, I still don't know. Everything seems to be working, but issuing warnings. Here are a bunch of the errors - from more reading I think the key is in the (38) which I think(??) is a postfix error code...is it? do you know what it means?: Jan 1 17:00:33 s postfix/smtpd[21502]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:00:33 s postfix/cleanup[21517]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:06:33 s postfix/trivial-rewrite[21546]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:06:34 s postfix/smtpd[21544]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:06:34 s postfix/cleanup[21547]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:42 s postfix/trivial-rewrite[21582]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:09:42 s postfix/smtpd[21581]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:42 s postfix/cleanup[21583]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:45 s postfix/local[21587]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:58 s postfix/trivial-rewrite[21592]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:11:50 s postfix/trivial-rewrite[21624]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:11:50 s postfix/smtpd[21623]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:11:50 s postfix/cleanup[21625]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:15:46 s postfix/trivial-rewrite[21648]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:15:49 s postfix/smtpd[21646]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:15:49 s postfix/cleanup[21649]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:19:10 s postfix/trivial-rewrite[21675]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) [snip] why do use sender_canonical instead of canonical? rewrite should be consistent, and "your sender is the recipient's recipient"... This is mostly because I use maildrop as the virtual delivery agent for many of the virtual mailboxes. I'm really just testing this, and may end up using canonical instead. But here's my thinking: I have one user who wants a minor change - sounds silly, but gives me a good chance to experimen
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 1, 2009, at 12:58 PM, mouss wrote:
Jeff Weinberger a écrit :
I've been reading the dspam docs this morning and the project owner
states fairly strongly that sendmail is far preferable to SMTP
re-injection (in the postfix setup docs), but doesn't say why.
if he doesn't say why, then we don't know whether there was a
problem at
the time or if there is another reason. People have been using smtp
mode
without problems.
I don't
know enough about the workings of dspam (yet) to know, but I'd tend
to
agree with you on the use of SMTP as more desirable.
dspam has always had this mysql issue, which is related to its
database
of spam tokens, and I'll look into whether it might be related.
I don't think it is related, but check it though...
First let me thank mouss for all his generous help on this - as it
turned out, I was able to solve it with the information in this thread
and http://www.pubbs.net/postfix/200811/3719/ from Victor but it
required some trickery to get the envelope-sender past dspam.
I'm posting my solution here in the hope that it might help someone
else.
I used a pcre: table for smtpd_sender_restrictions and the PREPEND
action as follows:
main.cf:
smtpd_sender_restrictions = check_sender_access pcre:/etc/
postfix/smtpd_sender_restrictions.pcre
smtpd_sender_restrictions.pcre
/^(.*)/ PREPEND X-Envelope-Sender: ${1}
this will insert into every message a header "X-Envelope-Sender: "
followed by the envelope sender value. It won't pass the envelope-
sender as SMTP MAIL FROM (dspam wasn't designed to do that, and until
I take the step to a better before-queue filter or something that
does, this will work, since all I needed was to capture the envelope-
sender).
Limited testing shows this to work. There might be cases beyond what I
tested that will behave differently than I expect or very oddly.
Thanks again!
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 2:30 AM, mouss wrote:
Jeff Weinberger a écrit :
I used a pcre: table for smtpd_sender_restrictions and the PREPEND
action as follows:
main.cf:
smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/smtpd_sender_restrictions.pcre
smtpd_sender_restrictions.pcre
/^(.*)/ PREPEND X-Envelope-Sender: ${1}
this will insert into every message a header "X-Envelope-Sender: "
followed by the envelope sender value. It won't pass the
envelope-sender as SMTP MAIL FROM (dspam wasn't designed to do that,
dspam gets it via LMTP MAIL FROM, and it will pass it back to postfix
with SMT MAIL FROM. I have used this in the past and I'm sure others
are
using it now (ping steve?). something in your setup prevents this from
working but I don' think it is a dspam limitation.
It's definitely my set up. I don't use LMTP to pass the message to
dspam, I use a transport called "dspam" that uses pipe. That means
there's no S/LMTP dialog, just the message itself passed as STDIN.
I have to move dspam to use LMTP and then move it to a before-queue
content filter so that this workaround becomes unnecessary, but until
I go to make those changes, this will suffice.
I'm not completely convinced that dspam will work seamlessly as a
before-queue content filter, so I'll have to do some testing to see
how well that works and whether it can do what I need and hand fully
formed messages with SMTP dialog information back to postfix.
Thank you!!
and
until I take the step to a better before-queue filter or something
that
does, this will work, since all I needed was to capture the
envelope-sender).
Limited testing shows this to work. There might be cases beyond
what I
tested that will behave differently than I expect or very oddly.
Thanks again!
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 9:20 AM, mouss wrote: Jeff Weinberger a écrit : It's definitely my set up. I don't use LMTP to pass the message to dspam, I use a transport called "dspam" that uses pipe. That means there's no S/LMTP dialog, just the message itself passed as STDIN. so _you_ are not passing the envelope sender to dspam. Consider running dspam in "relay mode": postfix --(LMTP)--> dspam --(SMTP)--> postfix I have to move dspam to use LMTP and then move it to a before-queue why do you want to run it in pre-queue mode? This is not needed and is not simple to setup. If I understand your diagram, then the content_filter would look like: content_filter=lmtp:unix:/path/to/dspam args and that might pass through the envelope information (I'm not convinced, but if dspam can do it, that would be how). But since dspam can speak LMTP and SMTP why would an smtpd proxy be hard to set up? It would certainly avoid the bcc issues, etc. that I" experiences by having the message run through postfix twice. After reading through SMTPD_PROXY_README, it seems like a bit of a challenge to make it work, but not that hard...what do you think might be difficult? Thanks for all your help - over the course of thi dialog I've learned a lot about postfix and have become more aware of and proficient with parts I knew little about. This has been very helpful. content filter so that this workaround becomes unnecessary, but until I go to make those changes, this will suffice. I'm not completely convinced that dspam will work seamlessly as a before-queue content filter, so I'll have to do some testing to see how well that works and whether it can do what I need and hand fully formed messages with SMTP dialog information back to postfix.
Re: Finding the envelope-sender after always_bcc? (SOLVED)
Wietse Venema wrote:
Jeff Weinberger:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Jan 2, 2009, at 2:30 AM, mouss wrote:
>
> > Jeff Weinberger a ?crit :
> >>
> >> I used a pcre: table for smtpd_sender_restrictions and the
PREPEND
> >> action as follows:
> >>
> >> main.cf:
> >> smtpd_sender_restrictions = check_sender_access
> >> pcre:/etc/postfix/smtpd_sender_restrictions.pcre
> >>
> >> smtpd_sender_restrictions.pcre
> >> /^(.*)/ PREPEND X-Envelope-Sender: ${1}
> >>
> >> this will insert into every message a header "X-Envelope-
Sender: "
> >> followed by the envelope sender value. It won't pass the
> >> envelope-sender as SMTP MAIL FROM (dspam wasn't designed to do
that,
> >
> > dspam gets it via LMTP MAIL FROM, and it will pass it back to
postfix
> > with SMT MAIL FROM. I have used this in the past and I'm sure
others
> > are
> > using it now (ping steve?). something in your setup prevents
this from
> > working but I don' think it is a dspam limitation.
>
> It's definitely my set up. I don't use LMTP to pass the message to
> dspam, I use a transport called "dspam" that uses pipe. That means
> there's no S/LMTP dialog, just the message itself passed as STDIN.
If you can show what you've configured to pass mail into dspam,
then perhaps someone can tell you how to get that envelope sender
address into dspam, too.
Wietse
I thought I had a while back, but I"m not sure it matters. Right now I
am passing mail to dspam via pipe, which means dspam does not know how
to handle the envelope-sender as a command-line argument. I need to
change this to passing mail to dspam via LMTP.
I don't know how exactly, but I hope with some help, I can make it work!
That said, here's the current configuration:
content_filter=dspam:dspam
and in master.cf:
dspam unix - n n - 10 pipe
flags=Ru user=_dspam argv=/usr/local/bin/dspam --
deliver=innocent --user ${recipient} -i - f $sender -- $recipient
dspam is running as a daemon .and re-injects the mail as SMTP to an
alternate port.
I assume the LMTP setup should look something like:
main.cf:
content_filter=lmtp:unix:/path/to/dspam --deliver=innocent --
user ${recipient} -i - f $sender -- $recipient
and the transport in master.cf becomes unnecessary.
I don't know how to handle the command line arguments (or even if I
have to), so suggestions, help and especially examples would be most
helpful.
Thank you!
--
Jeff Weinberger
http://disruptivemarketing.jeffweinberger.com
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 2:17 PM, mouss wrote: Jeff Weinberger a écrit : On Jan 2, 2009, at 9:20 AM, mouss wrote: Jeff Weinberger a écrit : It's definitely my set up. I don't use LMTP to pass the message to dspam, I use a transport called "dspam" that uses pipe. That means there's no S/LMTP dialog, just the message itself passed as STDIN. so _you_ are not passing the envelope sender to dspam. Consider running dspam in "relay mode": postfix --(LMTP)--> dspam --(SMTP)--> postfix I have to move dspam to use LMTP and then move it to a before-queue why do you want to run it in pre-queue mode? This is not needed and is not simple to setup. Is there a reason why you keep adding yahoo groups after I remove them fro CC? This is starting to annoy me... Sorry!! I was having problems with my messages not posting. I will stop adding :) and by the way, disable the X-DSPAM-Factors header. dspam doesn't encode it, which results in things like: X-DSPAM-Factors: 27, ... a+écrit, 0.01000, and this is not a valid header. OK thanks! If I understand your diagram, then the content_filter would look like: content_filter=lmtp:unix:/path/to/dspam args No. content_filter=lmtp:inet:127.0.0.1:10024 where the 10024 is the same port used in dspam.conf: ServerPort10024 of course, dspam must be running in daemon mode. dspam is running in daemon mode. This makes sense as a setup. The example in the dspam docs for postfix shows content_filter=lmtp:unix:/path/to/dspam.sock which is why I thought unix: instead of inet: is there any difference, other than performance? On a related question (if more broad): some content_filter examples I see use content_filter in main.cf and some as "-o content_filter=..." in master.cf. I understand from prior conversations here that you can't override content filters, they are global. (yes?) So is there an advantage/disadvantage to specifying the content filter in main.cf vs. master.cf? and that might pass through the envelope information (I'm not convinced, but if dspam can do it, that would be how). LMTP is similar to SMTP, and dspam can run as an LMTP server (this is configured in dspam.conf). But since dspam can speak LMTP and SMTP dspam has a server and a client. so which speaks what? if we are talking about the server part: $ cd dspam-3.8.0/src $ cat daemon.c .. input = daemon_expect(TTX, "LHLO"); if (input == NULL) goto CLOSE; .. it wants LHLO (which is for LMTP), not HELO or EHLO. so no smtp there. why would an smtpd proxy be hard to set up? It would certainly avoid the bcc issues, etc. I don't understand why you mix pre-queue and bcc. maybe you confuse pre-queue with a "not simple content filter"? I am new to pre-queue filtering and am clearly still confused :) you had asked: why do you want to run it in pre-queue mode? This is not needed and is not simple to setu so I thought it might be hard. It's not important for now...getting dspam working as LMTP will be fine (assuming it passes along all the right information once it works) Thank you!! that I" experiences by having the message run through postfix twice. After reading through SMTPD_PROXY_README, it seems like a bit of a challenge to make it work, but not that hard...what do you think might be difficult? Thanks for all your help - over the course of thi dialog I've learned a lot about postfix and have become more aware of and proficient with parts I knew little about. This has been very helpful. content filter so that this workaround becomes unnecessary, but until I go to make those changes, this will suffice. I'm not completely convinced that dspam will work seamlessly as a before-queue content filter, so I'll have to do some testing to see how well that works and whether it can do what I need and hand fully formed messages with SMTP dialog information back to postfix.
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 3:20 PM, mouss wrote: Jeff Weinberger a écrit : content_filter=lmtp:unix:/path/to/dspam args No. content_filter=lmtp:inet:127.0.0.1:10024 where the 10024 is the same port used in dspam.conf: ServerPort10024 of course, dspam must be running in daemon mode. dspam is running in daemon mode. This makes sense as a setup. The example in the dspam docs for postfix shows content_filter=lmtp:unix:/path/to/dspam.sock which is why I thought unix: instead of inet: it's ok to use a unix socket, but it's a socket, not the dspam binary with args. OK, thanks. I will set up dspam to listen on port 10024 - seems to make the most sense. I don't need a localhost:10024 entry in master.cf then? right? is there any difference, other than performance? I wouldn't put performances into the equation without measurements (one should tune where the bottleneck is, not in every small piece). if you use a unix socket, you'll have to make sure it is accessible. In particular, if someday you decide to chroot postfix, you'll need to put the unix socket in the chroot jail. exactly. Thanks On a related question (if more broad): some content_filter examples I see use content_filter in main.cf and some as "-o content_filter=..." in master.cf. I understand from prior conversations here that you can't override content filters, they are global. (yes?) no, they are not global. each smtpd may have its own content_filter. (don't confuse with: "one message, one filter". The latter simply means that postfix won't split a single message into one message per recipient before passing it to the content filter). That makes sense. thank you. So is there an advantage/disadvantage to specifying the content filter in main.cf vs. master.cf? I guess an example is better than literature, no? here is a "not uncommon setup": - port 25 is used for "MX" mail (aka inbound mail). it uses the content_filter defined in main.cf right, as I do right now. - port 587 is used for "submission" (authenticated, ...). such mail is scanned for viruses but not for spam (there's not much things a bayesian filter could do here, except in simple setups with a site-wide bayes). so -o is used to set the filter for this service I need to set this up also - seems easy, but is there an example of the localhost:587 master.cf entry somewhere I could start with? - sendmail mail is not filtered, because we "trust" the box (there's no user, ... etc) and we don't want anything blocking such mail. or we use sendmail to reinject mail after filtering, so we don't want to create a loop. for this, we set "-o content_filter=". do you mean the re-injection into postfix? I have "-o content_filter=" there already. I'm re-injecting mail via SMTP, not sendmail... I am new to pre-queue filtering and am clearly still confused :) - content_filter refers to after-the-queue filtering. This means postfix saves the mail on disk, says "ok" to the client, and sometimes after that, postfix passes the message to the filter - proxy_filter refers to pre-queue: postfix keeps the client connected, passed the message to the filter and waits for the filter response before responding to the client. This assumes SMTP, because the message was received via SMTP, so the client wants a single response for the whole message, and not one response per recipient. the pipe method that you were using is an example of a content_filter, and is referred to as a "simple filter" in postfix docs. but a content_filter need not be a pipe. you had asked: why do you want to run it in pre-queue mode? This is not needed and is not simple to setu so I thought it might be hard. and it is. reread what I said about dspam and lmtp... Thank you! It's not important for now...getting dspam working as LMTP will be fine (assuming it passes along all the right information once it works)
Re: issue connecting to mysql after upgrade (issue not postfix)
On Jan 1, 2009, at 4:53 PM, mouss wrote: Jeff Weinberger a écrit : [snip] - try with "hosts = 127.0.0.1" (without "localhost") Tried this - no change. :( ahem. if you do this, you should not hear about a socket. it should use a TCP connection. can you show the errors? OK, now I've taken out the localhost again and there's no more complaining. (not sure why It continued complaining last time...) This is not a postfix issue. This is clearly a MySQL socket issue. I'm pursuing this on the MySQL lists. Thank you! [snip] why do use sender_canonical instead of canonical? rewrite should be consistent, and "your sender is the recipient's recipient"... This is mostly because I use maildrop as the virtual delivery agent for many of the virtual mailboxes. I'm really just testing this, and may end up using canonical instead. But here's my thinking: I have one user who wants a minor change - sounds silly, but gives me a good chance to experiment/learn. I'm rewriting the one address to a specific capitalization. I know I'll be doing more with more users soon. I want to rewrite when mail goes to someone outside my postfix install. canonical_maps would also rewrite inbound mail to that address, which is not bad, but not the desired behavior. So I am trying sender_canonical_maps to get the behavior I want. Then you may want to use smtp_generic_maps instead of canonical.
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 4:03 PM, mouss wrote: Jeff Weinberger a écrit : OK, thanks. I will set up dspam to listen on port 10024 - seems to make the most sense. I don't need a localhost:10024 entry in master.cf then? right? no, 10024 will be used by dspam. your postfix should have a 127.0.0.1:10025 to get mail back. perfect thanks! So is there an advantage/disadvantage to specifying the content filter in main.cf vs. master.cf? I guess an example is better than literature, no? here is a "not uncommon setup": - port 25 is used for "MX" mail (aka inbound mail). it uses the content_filter defined in main.cf right, as I do right now. - port 587 is used for "submission" (authenticated, ...). such mail is scanned for viruses but not for spam (there's not much things a bayesian filter could do here, except in simple setups with a site-wide bayes). so -o is used to set the filter for this service I need to set this up also - seems easy, but is there an example of the localhost:587 master.cf entry somewhere I could start with? your master.cf should already contain a "submission" service (it's commented out by default). you can add -o conten_filter and other parameters. it didn't - but that's probably because apple modified the example file and took out the submission entry. I found it in the distribution. I'm guessing I should leave my port 25 (smtp) entry to allow submission on that port with authentication (leaving "smtpd_client_restrictions=permit_sasl_authenticated...") - is there any harm in that? - sendmail mail is not filtered, because we "trust" the box (there's no user, ... etc) and we don't want anything blocking such mail. or we use sendmail to reinject mail after filtering, so we don't want to create a loop. for this, we set "-o content_filter=". do you mean the re-injection into postfix? I have "-o content_filter=" there already. I'm re-injecting mail via SMTP, not sendmail... so you already had an example that overrides the content_filter in master.cf ;-) I see that I did... oops ;)
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 5:32 PM, mouss wrote: Jeff Weinberger a écrit : I'm guessing I should leave my port 25 (smtp) entry to allow submission on that port with authentication (leaving "smtpd_client_restrictions=permit_sasl_authenticated...") - is there any harm in that? no. but separating roles makes configuration easier. so encourage users to use 587. ok, thanks - that makes sense and it seems to be working fine for me. dspam isn't working fine accepting messages via LMTP, so I'm taking that over to the dspam list Thank you for your help!
Getting reject_sender_login_mismatch/smtpd_sender_login_maps and mysql to work together
Hi: I would very much appreciate any help, advice, pointers, etc. to resolve an issue I am encountering. I am having a challenge trying to use a mysql table for smtpd_sender_login_maps. Right now I have: In main.cf: smtpd_sender_login_maps=mysql:/path/to/map.cf smtpd_sender_restrictions=reject_sender_login_mismatch, My virtual mailbox table contains the username for authentication (which is also the e-mail address), the password and I am using a text (VARCHAR) field to hold the list of e-mail addresses that each user is allowed to send from. For example, my e-mail is jeff (at) jweinberger.homeip.net. I can send as that e-mail, but I also want to allow sending from someothername (at) jweinberger.homeip.net and from jeff (at) some-other-domain-I- own.tld. so the table row looks like: field username: jeff (at) jweinberger.homeip.net field password: (password) field valid_from: jeff (at) jweinberger.homeip.net, someothername (at) jweinberger.homeip.net, jeff (at) some-other-domain-I-own.tld The select statement in the maps.cf file is "select username from virtual_mailbox_table where (INSTR(valid_from, "%s") > 0)" which successfully (tested outside postfix) looks up the sender address and returns the login name (field: username). I run into problems when more than one login name is permitted to send from a given address. For example, say i include one of my valid addresses as postmaster (at) jweinberger.homeip.net (so I can send from it - mail to it goes into a postmaster mailbox as required). I also want someone else to be able to send from postmaster (at) jweinberger.homeip.net. So the virtual mailbox table would contain: Row 1: field username: jeff (at) jweinberger.homeip.net field password: (password) field valid_from: jeff (at) jweinberger.homeip.net, someothername (at) jweinberger.homeip.net, jeff (at) some-other-domain-I-own.tld, postmaster (at) jweinberger.homeip.net Row 2: field username: someoneelse (at) jweinberger.homeip.net field password: (password) field valid_from: someoneelse (at) jweinberger.homeip.net, yetanothername (at) jweinberger.homeip.net, postmaster (at) jweinberger.homeip.net And when I try to send mail authenticated at jeff (at) jweinberger.homeip.net from postmaster (at) jweinberger.homeip.net it fails with this log entry: postfix/smtpd[83245]: NOQUEUE: reject: RCPT from unknown[10.0.1.1]: 553 5.7.1 : Sender address rejected: not owned by user jeff (at) jweinberger.homeip.net from= to=<--edited--> proto=ESMTP helo=<[10.0.1.7]> The query in this case would return two rows, as both users are allowed to send from that address. According to the description of smtpd_sender_login_maps in http://www.postfix.com/postconf.5.html : "In all cases the result of table lookup must be either "not found" or a list of SASL login names separated by comma and/or whitespace" I conclude that the mysql query is not returning the list in the right form. Since I don't know how mysql calls are implemented in postfix, I don't know what to do to correct this, if it's possible. So my questions: 1) Is my analysis and conclusion (that mysql is not returning the result in the required form) correct? 2) Is there anything I can do to make the result come back in the form postfix needs it? I would like to be able to do this in this way, as I think it makes sense to track which addresses are authorized for each user, rather than the other way around. If there is no direct way to do this, I can build a reverse lookup table that will return the list postfix expects. And of course, if there is any additional information that would help in diagnosing or resolving this, I'd be happy to provide it. Any help, direction, pointers, etc. are much appreciated! Thanks, --Jeff
Re: Getting reject_sender_login_mismatch/smtpd_sender_login_maps and mysql to work together
gle result. All were rejected (as noted in the log entry I posted previously) with the reason that the from address was not authorized for that sasl user (not postfix's words, my paraphrase). I then changed the query to produce a multiple row result (rather than a comma-separated list) and ran the same tests. Same result - all messages were rejected. So, I am at a loss as to how to make this work with a mysql query. Thus my questions: - Does postfix expect mysql to return a multiple-row result or a text string with a comma-(or whitespace-)separated list of valid sasl users for that from address? - I am correct in my reading that the lookup key is the from (MAIL FROM) address? - I don't know what to ask about the queries that produced a single result - these are failing, but other than the log entry showing the failure, I don't know why. So, while I am not quite an expert in database design, I understand and will take your suggestions when I build the live database. Right now, I want to make sure I can get this to work, and it's not working as I'd expect. I'm reasonable sure I'm missing something, but I don't know what. Please let me know if there is further information that would point to a solution. Thank you so much for taking the time to help! --Jeff
Re: Getting reject_sender_login_mismatch/smtpd_sender_login_maps and mysql to work together
On Jan 6, 2009, at 5:59 PM, Wietse Venema wrote: Jeff Weinberger: I then added the line: smtpd_sender_login_maps=hash:/path/to/map to my main.cf and send a few messages. Postfix correctly allowed and rejected all of the test messaages, and the logs showed the correct reason for the rejection, and no log entries showing a successful match. I then, again just to test, added a field to my virtual users table to hold authorized addresses, and wrote the query noted above into a mysql_sender_login_maps.cf file. I used postmap -q to verify that the results of the query were correct and were exactly the same as the results received when I used postmap - q on the hash: file. They all were identical for the same lookup keys. smtpd does the same lookups as "postmap -q". If the result is different than when you run "postmap -q" by hand, then it is almost certain that you are using a different search key than Postfix uses. Postfix does the lookups as documented in the postconf(5) manual page: smtpd_sender_login_maps (default: empty) Optional lookup table with the SASL login names that own sender (MAIL FROM) addresses. Specify zero or more "type:table" lookup tables. With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, the following search operations are done with a sender address of u...@domain: 1) u...@domain This table lookup is always done and has the highest precedence. 2) user This table lookup is done only when the domain part of the sender address matches $myorigin, $mydestination, $inet_inter- faces or $proxy_interfaces. 3) @domain This table lookup is done last and has the lowest precedence. You can see what lookups Postfix does by setting the debug_peer_list parameter in main.cf. For example: # postconf -e debug_peer_list=static:all # postfix reload Wietse Wietse Thank you very much for your help. I just responded to Viktor as well, and plead stupid. I just re-ran all the same tests (by hand this time) and everything worked. All postmap-q commands gave the correct results, and all messages were accepted or rejected as expected. I checked the scripts I used earlier for logical errors and typos, but found none. so I have no idea why I was getting odd results. Never-the-less, all works now. I thank you and Victor for your generous help. --Jeff
how to specify an over-ride in master.cf that contains whitespace
Hi: Yet another question I hope I can impose upon your help for... I am testing sender restrictions and have defined an alternate submission entry in master.cf for this purpose (and not to disrupt other users while I test). I want to test the check_sender_access which requires the form "check_sender_access type:table" which includes whitespace, which is not permitted in master.cf According to the master(5) documentation: do not specify whitespace around the "=". In parameter values, either avoid whitespace altogether, use commas instead of spaces, or consider overrides like "-o name=$override_parameter" with $over- ride_parameter set in main.cf. So will this work: main.cf: $my_test_sender_restrictions=check_sender_access pcre:/path/to/ file.pcre master.cf -o smtpd_sender_restrictions= $my_test_sender_restrictions,reject_sender_login_mismatch,. or am I missing something? Thank you! --Jeff
"forcing" authenticated users to use port 587?
Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? Thank you for any help and/or advice! --Jeff
Re: "forcing" authenticated users to use port 587?
On Jan 8, 2009, at 5:49 AM, Jorey Bump wrote: Jeff Weinberger wrote, at 01/08/2009 12:10 AM: Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? Yes, you can simply set smtpd_sasl_auth_enable = no (which is the default, so you could also remove the line, but being explicit might be more helpful in this case). You can also remove permit_sasl_authenticated from smtpd_*_restrictions, but it might be wise to leave it in place for the time being (it shouldn't cause any problems). Your submission service in master.cf should already have -o smtpd_sasl_auth_enable=yes in it. Keep in mind, however, that some users will still be able to use port 25 to send messages to domains that the server accepts mail for. To them, it may seem that relaying works inconsistently. 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? The decision to restrict mail submission to port 587 depends on your needs. I manage some environments where this is enforced. I actually like the separation, but it sometimes requires additional support for legacy clients (achieved in various ways). In other environments with a more diverse and general population, I continue to allow submission on port 25, but only with mechanisms that are considered secure. You'll probably want to begin with this arrangement, as you are suggesting. It's kinder to your users, if you're not in any rush. The important thing is that you're opening port 587 (with sane settings) to support road warriors and users whose ISPs block outgoing connections to port 25. This move benefits them as much (if not more) as you. Thank you for your help and insight.!! I'm glad to hear that this is a fairly common option and one that can be supported, even if with some hoop-jumping. As far as how to make it happen... Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Thanks! --Jeff
Re: "forcing" authenticated users to use port 587?
On Thu, 08 Jan 2009 09:53:45 -0500, Jorey Bump wrote: > Jeff Weinberger wrote, at 01/08/2009 09:27 AM: > >> Setting smtpd_sasl_auth_enable = no would mean that no authentication is >> required on port 25, but if I understand it correctly, it wouldn't >> actually stop an authenticated user from sending mail through port 25. >> If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = >> no, would postfix refuse the connection? > > Actually, smtpd_sasl_auth_enable = no means that authentication is not > enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/EHLO. > Attempts to authenticate will generate an error. Most modern clients are > intelligent enough to detect the absence of AUTH and will not attempt to > authenticate. Good ones will abort and notify the user. Bad ones might > attempt to continue, in case the server will still accept the message. > If the domain is a destination your server handles, it will probably > accept the message, otherwise it will reject it. > >> In the final step of my scenario, that's the behavior I want to achieve. >> Will that simple step work? > > Yes. You can completely disable submission on port 25 and prevent > relaying to destinations you don't accept by hosts outside of mynetworks. Jory: Thanks again! So it looks like it's as simple as smtpd_sasl_auth_enable = no for port 25, and then making sure everything else is set so that mail coming in on port 25 has to be for one of my domains or it's rejected. Thanks! I appreciate the help!
Re: "forcing" authenticated users to use port 587?
On Jan 8, 2009, at 6:53 AM, Jorey Bump wrote: Jeff Weinberger wrote, at 01/08/2009 09:27 AM: Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? Actually, smtpd_sasl_auth_enable = no means that authentication is not enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/ EHLO. Attempts to authenticate will generate an error. Most modern clients are intelligent enough to detect the absence of AUTH and will not attempt to authenticate. Good ones will abort and notify the user. Bad ones might attempt to continue, in case the server will still accept the message. If the domain is a destination your server handles, it will probably accept the message, otherwise it will reject it. In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Thank you an thank you to Chris for your help on this! I just have two, maybe obvious questionsif I may; I noticed that on several occasions, and in the default master.cf: -o milter_macro_daemon_name=ORIGINATING is suggested for the submission service. I'm not familiar with Milters and can't find information on what this is or what this does (at least in my search of the docs). Can you offer any pointers to where I can learn more specifics about milter macro daemons and this specific one? Also you noted: In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Does smtpd_sasl_auth_enable = no completely disable submission and prevent relaying for hosts I don't accept? or is there more I have to make sure I do? thank you again! --Jeff
Question about reject_unauthenticated_sender_login_mism atch
Hi: This question is just a request for information on this... I currently use reject_sender_login_mismatch in my smtpd_sender_restrictions as an added precaution against someone sending undesirable mail. I see that I can also use reject_unauthenticated_sender_login_mismatch, but I don't understand how this would work. reject_sender_login_mismatch checks the from address against smtpd_sender_login_maps to be sure that the MAIL FROM address is owned by the SASL-authenticated sender. But with reject_unauthenticated_sender_login_mismatch, there is no SASL-authenticated sender. http://www.postfix.com/postconf.5.html says that reject_unauthenticated_sender_login_mismatch "Enforces the reject_sender_login_mismatch restriction for unauthenticated clients only" (and nothing more) All of that to get to my question: What does reject_unauthenticated_sender_login_mismatch check the MAIL FROM address against? Or does it just check the smtpd_sender_login_maps for a valid MAIL FROM address (regardless of ownership)? (yes, I'm trying to figure out if using this in my smtpd_sender_restrictions would help and how it might do so) Thank you!! --Jeff
Re: Question about reject_unauthenticated_sender_login_mismatch
Viktor Duchovni wrote: On Mon, Jan 12, 2009 at 01:25:38PM -0800, Jeff Weinberger wrote: reject_sender_login_mismatch checks the from address against smtpd_sender_login_maps to be sure that the MAIL FROM address is owned by the SASL-authenticated sender. But with reject_unauthenticated_sender_login_mismatch, there is no SASL-authenticated sender. This subsumes the functionality of both: reject_authenticated_sender_login_mismatch, reject_unauthenticated_sender_login_mismatch OK, I missed the first one in the doc, so it makes sense. if the session is authenticated the first test is applied, otherwise the second test is applied. http://www.postfix.com/postconf.5.html says that reject_unauthenticated_sender_login_mismatch "Enforces the reject_sender_login_mismatch restriction for unauthenticated clients only" (and nothing more) All of that to get to my question: What does reject_unauthenticated_sender_login_mismatch check the MAIL FROM address against? The smtpd_sender_login_maps table. Sorry, I mis-asked the question. When reject_authenticated_sender_login_mismatch is specified, postfix takes the MAIL FROM address, looks it up in the smtpd_sender_login_maps table, and checks to make sure the authenticated sender is in there and the MAIL FROM address is owned by the authenticated sender. So Or does it just check the smtpd_sender_login_maps for a valid MAIL FROM address (regardless of ownership)? s/valid// If an address is found in the table, and the sender is not authenticated, the message is rejected. When a sender is not authenticated, and reject_unauthenticated_sender_login_mismatch is specified, postfix takes the MAIL FROM address, looks it up in smtpd_sender_login_maps and if it's found, the message is rejected? Essentially the lookup is just for the existence of the MAIL FROM address in the smtpd_sender_login_maps table? Am I then correct in concluding that with: smtpd_sender_restrictions = permit_sasl_authenticated, reject_authenticated_sender_login_mismatch, reject that the permit_sasl_autheticated obviates the need for reject_unauthenticated_sender_login_mismatch? (as there would never be an unauthenticated sender permitted...) And am I also correct in concluding that is unauthenticated senders were allowed (as they would have to be for smtpd to accept messages from the internet), that reject_unauthenticated_sender_login_mismatch would prevent any non-authenticated sender from sending a message from (with MAIL FROM) any address listed in my smtpd_sender_login_maps? (yes, I'm trying to figure out if using this in my smtpd_sender_restrictions would help and how it might do so) If you are already using the combined restriction, there is no point in adding either of the constituent building-block restrictions. That makes perfect sense. If you want to restrict your policy to either the authenticated, or the unauthenticatd case, then replace the combined restriction with the appropriate more specific restriction. As you see, I'm more interested in whether reject_unauthenticated_sender_login_mismatch makes sense at all for my setup and if so, in which context. If my two conclusions above are correct, it makes sense on the general access service, but not on the submission service. Thank you so much for your help!! -- Viktor.
holding messages for one address or one domain in the queue?
This may seem like an odd question, but I need to find a way to suspend delivery of mail to one account or one domain for a short period of time to allow me to do a bit of maintenance. As it stands now, I use maildrop as my delivery transport for virtual mailboxes. Is there a way to tell postfix to hold the mail in its queue until I tell it I'm ready? Is this as simple as having maildrop return a temporary failure code? and if that happens, postfix will retry at certain intervals (or on postqueue -f) right? And if that is a good way to do it, what return code should maildrop return? Or is there a better way? Thank you!
Re: holding messages for one address or one domain in the queue?
On Jan 14, 2009, at 3:53 PM, Roderick A. Anderson wrote: Jeff Weinberger wrote: This may seem like an odd question, but I need to find a way to suspend delivery of mail to one account or one domain for a short period of time to allow me to do a bit of maintenance. As it stands now, I use maildrop as my delivery transport for virtual mailboxes. Is there a way to tell postfix to hold the mail in its queue until I tell it I'm ready? I've used a pretty simple trick of putting the domain in the header_checks.regexp file. header_checks.regexp /^To: @example.com/HOLD Rod nice trick! - thanks! -- Is this as simple as having maildrop return a temporary failure code? and if that happens, postfix will retry at certain intervals (or on postqueue -f) right? And if that is a good way to do it, what return code should maildrop return? Or is there a better way? Thank you!
Re: Multiple SMTP relays based on sender's domain
On Jan 15, 2009, at 11:25 AM, Gilles Albusac wrote: Is it possible to set up Postfix to choose an SMTP relayhost when routing outbound mail based on the domain name of the sender ? try using transport map http://www.postfix.org/ADDRESS_REWRITING_README.html#transport # TRANSPORT MAP # # See the discussion in the ADDRESS_REWRITING_README document. #transport_maps = hash:/etc/postfix/transport #transport_maps = ldap:/etc/postfix/ldaptransport #transport_maps = hash:/etc/postfix/transport
Re: Question about reject_unauthenticated_sender_login_mismatch (additional information)
Viktor Wrote:
On Thu, Jan 15, 2009 at 10:01:51PM +0100, mouss wrote:
> jeff_homeip a ?crit :
> > [snip]
> > When I added this back, all worked fine. If I remove this one
restriction
> > (check_sender_access), I can no longer send.
> >
> > is this check_sender_access, because it's not rejecting the
sender, allowing it somehow?
> >
>
> no. it's more probable that you have errors in your config.
>
I this it's absolutely certain that I had errors in my config. As you
noticed, I have been having a challenge trying to isolate and fix them.
> if you think you have a problem with one particular configuration,
then
> we need to see that configuration, so
>
> 1) configure postfix to reproduce the problem
> 2) restart postfix
> 3) from now, don't change any setting until the end of this
procedure
> 4) reproduce the problem (test...)
> 5) if you succeed, send us the
> -- contents of master.cf
> -- the output of 'postconf -n'
> -- the contents of main.cf (to see "custom" variables)
6) "postmap -q - " output for all relevant keys in all relevant
tables.
7) verbose logging from the smtpd(8) showing the events that lead
up to reject restriction. Configure via "debug_peer_list" or "-v"
entry in master.cf. It is enough to report just 10-20 lines of
logging above the "reject" event, that demonstrate which restrictions
is being processed and associated table lookup keys and results.
As I noted earlier, I restored my main.cf and master.cf from backup (a
known working version) and started over.
I ran these tests with that version and found no problems. I then
changed the configurations to the desired end-point and ran these (and
a few other) tests again. Again no problems.
So I was not able to reproduce this. I have to conclude that I took
interim steps on the way to the desired state, and one of those
resulted in the errors I observed. Since I did not document my steps,
only my goal, I cannot reproduce each one, and since I cannot find the
combination that produced the error, I have to conclude that I did
something seriously wrong at some point.
So I must apologize - I have asked you to help chase an issue that
seems to have been just an interim error. I appreciate your help and
effort, but I am sorry that it appears unnecessary. (of course, if it
recurs, I'll run these tests again, and if I can reproduce it, post
all the information here)
I now have it working, as far as I can tell, as I want. The goal was
to have a submission service that forces authentication and requires
that authenticated users only send from addresses they own.
So I now have:
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_sender_restrictions=
$
587_master_sender_restrictions
,reject_sender_login_mismatch,permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
with, in main.cf:
587_master_sender_restrictions=check_sender_access pcre:/etc/postfix/
smtpd_sender_restrictions.pcre
and
smtpd_sender_restrictions.pcre containing one line:
/^(.*)/ PREPEND X-Envelope-Sender: <${1}>
I was concerned that the "match" on PREPEND would obviate the further
sender_restrictions, but that appears not to be the case, in limited
testing so far.
The recipient_restrictions are solely meant to avoid the many checks
( e.g. RBL, unauth_pipelining, etc.) in my main.cf for my smtp service.
This appears to work. I am of course, open to any and all suggestions
on how this can be improved.
Again, sorry for dragging you down an dead-end path, but thank you for
your help - I've learned a lot along the way.
--Jeff
Re: Transport map problem
On Jan 16, 2009, at 10:10 AM, Rob Horton wrote: Hi, I'm having some problems with setting a regexp transport map. What I want is: 1) Mail for u...@domain.com is delivered locally via the Zimbra system. 2) Mail for u...@machine.domain.com should be delivered directly to that machine. 3) All other (i.e. external) mail should be relayed via relay.domain.com. What I've tried is setting: postfix_transport_maps=proxy:ldap:/opt/zimbra/conf/ldap-transport.cf lets see ldap-transport.cf you may not even need the regex. -j
Question on sendmail submission and master.cf -o overrides
Hi: I am hoping someone can offer help in determining this information about the specifics of how sendmail submits mail. I have three different services configured in master.cf to accept mail: 1) the regular smtpd service on port 25, 2) a submission service for authenticated clients, and 3) a reinjection service (localhost: 10026) to accept mail after an after-queue content filter (which is specified as an - o override on the port 25 service in master.cf, not in main.cf). I am about to add a different after-queue content filter to the submission service (also via an -o override in master.cf), and this content filter re-injects mail via the sendmail command. There is no content_filter specified in main.cf. In this configuration, when mail is submitted via the sendmail command, will the content filter specified on the port 25 service apply? or will postfix only pay attention to the settings in main.cf for the purposes of transferring that mail? I suppose the more general question is which set of configuration options is mail submitted via the sendmail command subject to? (yes, I read the sendmail(1) documentation and did not find this information. The architecture documentation indicates only that it is subject to pretty much anything that local submission is subject to, but it's not clear what that is). Any help or pointers are very much appreciated! Thanks, --Jeff
Re: Question on sendmail submission and master.cf -o overrides
Viktor Wrote: Date: Tue, 20 Jan 2009 22:26:23 -0500 From: Victor Duchovni Subject: Re: Question on sendmail submission and master.cf -o overrides On Tue, Jan 20, 2009 at 07:11:16PM -0800, Jeff Weinberger wrote: I am hoping someone can offer help in determining this information about the specifics of how sendmail submits mail. The postdrop(1) helper places the mail in the maildrop sub-directory of the Postfix queue. The pickup(8) daemon asynchronously injects mail into the "incoming" queue (via cleanup(8)) one message at a time There is no content_filter specified in main.cf. In this configuration, when mail is submitted via the sendmail command, will the content filter specified on the port 25 service apply? or will postfix only pay attention to the settings in main.cf for the purposes of transferring that mail? Local submission via sendmail(1) does not use SMTP, so the smtpd(8) service on port 25 never sees the mail. Ergo, settings there do not apply. I suppose the more general question is which set of configuration options is mail submitted via the sendmail command subject to? 1. "-o" options in the pickup(8) service master.cf(5) entry. 2. main.cf parameter settings Thank you . Make sense. If I wanted to change any of the pickup(8) options, I'd need to define an alternate pickup service (not likely to do this). (yes, I read the sendmail(1) documentation and did not find this information. The architecture documentation indicates only that it is subject to pretty much anything that local submission is subject to, but it's not clear what that is). Submission via sendmail(1) *is* "local submission". The latter is a term of art for the former. http://www.postfix.org/OVERVIEW.html#receiving o Local submissions are received with the Postfix sendmail(1) compatibility command, and are queued in the maildrop queue by the privileged postdrop(1) command. This arrangement even works while the Postfix mail system is not running. The local pickup(8) server picks up local submissions, enforces some sanity checks to protect Postfix, and gives the sender, recipients and message content to the cleanup(8) server. - -- Viktor. Thank you for your help - this is very clear.
Slow down in delivery
Greetings, not sure if what my problem is. delivery times are way up and the queue is pretty high. message come in, and take forever to deliver. command_directory = /usr/sbin config_directory = /etc/postfix content_filter = daemon_directory = /usr/libexec/postfix debug_peer_level = 2 enable_server_options = yes html_directory = no inet_interfaces = all local_recipient_maps = proxy:unix:passwd.byname $alias_maps luser_relay = mail_owner = postfix mailbox_size_limit = 0 mailbox_transport = cyrus mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man mydestination = $myhostname,localhost. $mydomain,localhost,beth.k12.pa.us,bethsd.org mydomain_fallback = localhost myhostname = imap3.beth.k12.pa.us mynetworks = 127.0.0.1/32,10.130.0.0/16 mynetworks_style = host newaliases_path = /usr/bin/newaliases queue_directory = /private/var/spool/postfix readme_directory = /usr/share/doc/postfix relayhost = smtp1.beth.k12.pa.us sample_directory = /usr/share/doc/postfix/examples sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_tls_key_file = unknown_local_recipient_reject_code = 550 I read the performance tuning http://www.postfix.org/TUNING_README.html osx doesn't have qshape. what can i check to get the delivery back up to speed. -j
Re: Slow down in delivery
On Jan 21, 2009, at 12:13 PM, Victor Duchovni wrote: On Wed, Jan 21, 2009 at 10:41:00AM -0500, jeff donovan wrote: I read the performance tuning http://www.postfix.org/TUNING_README.html osx doesn't have qshape. The "qshape" program is a small Perl script. Just download it and run (as root). great,.. what flags should I set >? what should I look for qshape.pl [ -s ] [ -p ] [ -m ] [ -l ] [ -b ] [ -t ] [ -w ] [ -c ] [ ... ] -j
Re: Slow down in delivery
On Jan 21, 2009, at 1:44 PM, Victor Duchovni wrote: On Wed, Jan 21, 2009 at 01:04:07PM -0500, jeff donovan wrote: On Jan 21, 2009, at 12:13 PM, Victor Duchovni wrote: On Wed, Jan 21, 2009 at 10:41:00AM -0500, jeff donovan wrote: I read the performance tuning http://www.postfix.org/TUNING_README.html osx doesn't have qshape. The "qshape" program is a small Perl script. Just download it and run (as root). great,.. what flags should I set >? what should I look for qshape.pl [ -s ] [ -p ] [ -m ] [ -l ] [ -b ] [ -t ] [ -w ] [ -c ] [ ... ] Typically no flags are required: http://www.postfix.org/QSHAPE_README.html#qshape just name the queues (default just incoming/active) you want to examine. Add the "deferred" queue if the problem is lots of deferred mail. qshape worked great I found a couple account names that had issues, and they were receiving many messages that would bog down the queue. I made the error of flushing the queue too many times. sending those offenders right back inline. ( tick tick tick,more mail would arrive. ) i rebuilt those accounts, and blammo. mail shot through just fine. everything working normal. thanks for your help -j
Re: Nigerian 419 spam
On Jan 22, 2009, at 10:28 AM, bharathan kailath wrote: hi how can i take some measures to stop this so called Nigerian 419 spam ;i've got two postfix relays with amavisd; but still i get some emails like Nigerian 419 spam help appreciated smtpd_client_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/access, hash:/etc/postfix/smtpdreject reject_rbl_client zen.spamhaus.org
User getting back scattered
Greetings i have a user who is getting a ton of postmaster bounces. who or what ever is spamming is using her address as the return reply, so all the bounces and postmaster warnings are coming back to her and filling up her account. how can I alleviate this? I can't seem to get a handle on where it's coming from. thanks for help -jeff
Re: User getting back scattered
On Feb 4, 2009, at 9:47 AM, Brian Evans - Postfix List wrote: jeff donovan wrote: here is a sample of the bounce: I have modified the real users name. Article rejected, un-authorized poster of realusern...@beth.k12.pa.us Received: from XDYHONJUP [189.22.134.132] by john23.com with ESMTP (SMTPD32-8.00) id A6C57D10052; Wed, 04 Feb 2009 08:23:17 -0500 Received: from 189.22.134.132 by mail2.beth.k12.pa.us; Wed, 4 Feb 2009 11:22:50 -0300 If this is to be believed, then: grkni...@mx1 ~ $ host 132.134.22.189.zen.spamhaus.org 132.134.22.189.zen.spamhaus.org has address 127.0.0.4 Zen wins again and this is spam accepted by your server and not BackScatter. Check logs to verify this is not forged. Brian thanks brian. I guess this is a a bad example. I picked one out of a hat. I have zen listed. i have placed these two lines in my config. Hopefully this will eliminate some of the bounce messages. header_check if /^Received:/ /^Received: +from +(beth\.k12\.pa\.us) +/ reject forged client name in Received: header: $1 /^Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)(beth\.k12\.pa \.us)\)/ reject forged client name in Received: header: $2 /^Received:.* +by +(beth\.k12\.pa\.us)\b/ reject forged mail server name in Received: header: $1 endif body check if /^[> ]*Received:/ /^[> ]*Received: +from +(beth\.k12\.pa\.us) / reject forged client name in Received: header: $1 /^[> ]*Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)(beth \.k12\.pa\.us)\)/ reject forged client name in Received: header: $2 /^[> ]*Received:.* +by +(beth\.k12\.pa\.us)\b/ reject forged mail server name in Received: header: $1 endif /^[> ]*Message-ID:.* /^[> ]*Message-ID:.*@(beth\.k12\.pa\.us)/ reject forged domain name in Message-ID: header: $1
Re: User getting back scattered
On Feb 4, 2009, at 8:59 AM, Matthias Andree wrote: Am 04.02.2009, 14:42 Uhr, schrieb jeff donovan : Greetings i have a user who is getting a ton of postmaster bounces. who or what ever is spamming is using her address as the return reply, so all the bounces and postmaster warnings are coming back to her and filling up her account. how can I alleviate this? I can't seem to get a handle on where it's coming from. Have you read BACKSCATTER_README yet? If not, I'd recommend it, it has some pointers on where to start. Run the command "postconf readme_directory" to find the directory that is supposed to contain said document on your system. -- Matthias Andree greetings and thanks for the reply. yes, I read the http://www.postfix.org/BACKSCATTER_README.html and it looks like this is just what I need. before I place a header or body check i want to make sure i'm blocking it correctly. are the sample body checks going to wrk in my case ? thanks -jeff here is a sample of the bounce: I have modified the real users name. Viewing Full Header - View message Return-Path: Received: from murder ([unix socket]) by imap1.beth.k12.pa.us (Cyrus v2.2.12-OS X 10.4.8) with LMTPA; Wed, 04 Feb 2009 08:21:51 -0500 X-Sieve: CMU Sieve 2.2 Received: from smtp2.beth.k12.pa.us (smtp2.beth.k12.pa.us [10.135.1.8]) by imap1.beth.k12.pa.us (Postfix) with ESMTP id 7C6C214F7845 for ; Wed, 4 Feb 2009 08:21:51 -0500 (EST) Received: from localhost (mx1.beth.k12.pa.us [10.135.1.6]) by smtp2.beth.k12.pa.us (Postfix) with ESMTP id 0D714F3AA34 for ; Wed, 4 Feb 2009 08:24:00 -0500 (EST) Received: from mx1.beth.k12.pa.us ([127.0.0.1]) by localhost (mx1.beth.k12.pa.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08743-07 for ; Wed, 4 Feb 2009 08:25:03 -0500 (EST) Received: from mail2.beth.k12.pa.us (mail2.beth.k12.pa.us [192.227.0.10]) by mx1.beth.k12.pa.us (Postfix) with ESMTP id 7065953ED5D4 for ; Wed, 4 Feb 2009 08:25:02 -0500 (EST) Received: from john23.com (john23.com [216.117.171.26]) by mail2.beth.k12.pa.us (Postfix) with ESMTP id 3BA40811002 for ; Wed, 4 Feb 2009 08:23:52 -0500 (EST) Date: Wed, 4 Feb 2009 08:23:51 -0500 Message-Id: <20090204082351236.aa72e1c...@john23.com> From: financecouncil-ow...@john23.com To: realusern...@beth.k12.pa.us Subject: Article rejected, un-authorized poster of realusern...@beth.k12.pa.us X-Spam-Status: No, hits=0.537 tagged_above=-999 required=5 tests=ADDRESS_IN_SUBJECT, BAYES_00, NO_REAL_NAME X-Spam-Level: Article rejected, un-authorized poster of realusern...@beth.k12.pa.us Received: from XDYHONJUP [189.22.134.132] by john23.com with ESMTP (SMTPD32-8.00) id A6C57D10052; Wed, 04 Feb 2009 08:23:17 -0500 Received: from 189.22.134.132 by mail2.beth.k12.pa.us; Wed, 4 Feb 2009 11:22:50 -0300 Date:Wed, 4 Feb 2009 11:22:50 -0300 From:"Leann Norris" <51dzoxaw0...@beth.k12.pa.us> X-Mailer: The Bat! (v3.5.25) Professional Reply-To: realusern...@beth.k12.pa.us X-Priority: 3 (Normal) Message-ID: <> To: dde...@john23.com Subject: Crazy sale prices hmf kqqpoaxd MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5EE5E1DDB4291CD2" 5EE5E1DDB4291CD2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit http://lineyakiq.cn Get beautiful women easily - Get the desired act duration - Get hard-on of one passing thought - Make your activity last more 5EE5E1DDB4291CD2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit http://lineyakiq.cn";> http://lineyakiq.cn Get beautiful women easilyfont> - Get the desired act duration - Get hard-on of one passing thought - Make your activity last more 5EE5E1DDB4291CD2--
Redirect all mail from one domain to the same u...@otherdomain?
Hi:
I would appreciate any advice anyone can offer on how best to achieve
this behavior:
I am trying to figure out the best way to map one domain to another
with the same users...precisely the behavior I am trying to achieve
is: when mail is sent (from outside, or from another user within my
postfix installation) to u...@domain1.tld I want it redirected to u...@domain2.tld
- in otherwords, the user is preserved, but the domain is translated/
rewritten. To be more specific:
us...@domain1.tld gets re-routed to us...@domain2.tld
us...@domain1.tld gets re-routed to us...@domain2.tld
and so on.
My initial guess is to use recipient_canonical_maps and use a pcre map:
/^(.*)@domain1.tld/ {$1)@domain2.tld
I don't see a way to achieve this with alias_maps and header_checks
(with action REDIRECT) would miss messages sent to u...@domain1.tld
where that is not the To: or Cc: address (such as list mail).
Really, I am just checking with experts more knowledgeable than I
whether I have chosen a good (or the best) way to achieve this, or if
there is a better way.
Any advice and help are much appreciated!
Thanks,
--Jeff
--
Jeff Weinberger
http://disruptivemarketing.jeffweinberger.com
Re: Redirect all mail from one domain to the same u...@otherdomain?
jeff_homeip a écrit :
[snip]
that creates some complications...and might be too difficult
a script and a Makefile... or sql as below:
but why not use wildcard virtual aliases? You noted below that they
break
recipient
validations. Do you mean that smtp_recipient_restrictions won't
work? at all
or parts?
no, it's not about smtpd restrictions. it's about rejecting mail to
invalid recipients.
Wildcard virtual aliases seems like the best waybut I want to
understand
the implications
on everything esle before I proceed.
Thanks!
The reason is that if you use
@example.com @example.org
then this breaks recipient validation: smtpd will accept
anything^example.com, then at delivery time, the user won't be
found and
a bounce will be generated. in short, you become a source of
backscatter
(you send bounces to innocents whose addresses were forged by
spammers)
Unless I don't bounce unknown addresses
and you'd do what with these? if you have a catchall, it's ok. but you
should not discard mail (people do mistype addresses some time, so
it's
not just spammers trying invalid addresses).
I use a catchall for some domains instead of rejecting unknown
recipients, for exactly that reason. I find about 2-3% of catchall mai
is user errors (like mis-spellings) rather than spam.
So in this case, I can use a wildcard catchall.
So an alias map of:
@domain1.tld @domain2.tld
will produce the expected result of anyuser @ domain1.tld being
redirected to the same user (anyuser) @ domain2.tld?
That would be by far the easiest to do in my setup.
you can generate the individual mappings with a script.
alternatively,
if you store users in sql, you can use sql statements to generate
these
"on the fly". examples have been posted multiple times to the list
(a
long time ago, that said, but you may be lucky...).
it would be something like:
if (%d=3D'domain1.com') then select %...@domain2..com from
virtual_alias else select alias
from virtual_alias where address=3D%s
(that's not quite right in the syntax, but you get the idea). This
wont' work, as I'd have to
write a special select clause for each domain I want to work this
way.
assuming you have a User table containing valid email addresses and a
AliasDomain table containing (alias, destination) domains:
select User.user from AliasDomain, User where
AliasDomain.alias =3D '%d'
AND
User.user =3D CONCAT('%u', '@', AliasDomain.destination)
you can avoid the CONCAT inside the "search" if you split your
emails in
(user, domain) columns like I do. in which case, the query becomes
select CONCAT(User.user, '@', User.domain) where
AliasDomain.alias =3D '%d'
AND
AliasDomain.destination =3D User.domain
AND
User.user =3D '%u'
of course, this works for "1 depth" alias domains (it doesn't work if
example.net is an alis for example.org which is in turn an alias of
example.com). but this should be enough in most cases.
This is helpful, but I still need the query to take all the other
alias domains into account. So, I need the IF condition, or a second
map.
Thank you for your help...it's informative as always!
if the wildcard alias will produce the result I need then this is
resolved.
--
Jeff Weinberger
http://disruptivemarketing.jeffweinberger.com
Re: Redirect all mail from one domain to the same u...@otherdomain?
Mouss wrote: Jeff Weinberger a �crit : > [snip] > > This is helpful, but I still need the query to take all the other > alias domains into account. So, I need the IF condition, or a second map. > I don't think so. I used this. I don't remember the details, but the idea is that you can often get rid of flow control (if, ...) using additional tables. Thanks - yes, additional tables, maps, etc. would make the sql coding far simpler. > Thank you for your help...it's informative as always! > > if the wildcard alias will produce the result I need then this is > resolved. > @example.org @example.com works, but smtpd will accept mail to anyth...@... (virtual_alias_maps are used for recipient validation during the smtp transaction). if all addresses are valid (catchall or whatver), this is ok. otherwise, it's bad. in any case, you must make sure that mail isn't bounced after it is accepted (queued). This is what happens by default (after virtual alias expansion, a delivery error occurs, and an NDR is generated). Thank you - this will work well. I'll use a catchall mailbox to make sure that I don't generate an NDR. thanks for your help!
user getting spoofed
Greetings I have a user whos name is being spoofed by the spammers of the world. and her mailbox is getting flooded by legitimate Mailer Delivery notices. Is there anything i can do for her besides change her account name ? I was thinking about a temporary regex to discard those notices. ( i know not the best but it may stem the tide ). any assistance is welcome -jeff
Re: user getting spoofed
On Feb 19, 2009, at 10:39 AM, Noel Jones wrote: jeff donovan wrote: Greetings I have a user whos name is being spoofed by the spammers of the world. and her mailbox is getting flooded by legitimate Mailer Delivery notices. Is there anything i can do for her besides change her account name ? I was thinking about a temporary regex to discard those notices. ( i know not the best but it may stem the tide ). any assistance is welcome -jeff thanks for the reply General suggestions for combating backscatter: http://www.postfix.org/BACKSCATTER_README.html got this. I have a header and body check setup. You can use the ips.backscatterer.org to reject bounces (*NOT* all mail) from known backscatter sources. Do this in smtpd_data_restrictions for compatibility with sender address verification. # main.cf smtpd_data_restrictions = check_sender_access hash:/etc/postfix/backscatterer # backscatterer <> reject_rbl_client ips.backscatterer.org so thats all I need to add in the hash file ? <> reject_rbl_client ips.backscatterer.org In this case you may also want to *temporarily* reject all NDNs addressed to that particular user. General instructions: http://www.postfix.org/RESTRICTION_CLASS_README.html more specific: # main.cf smtpd_restriction_classes = reject_ndn reject_ndn = check_sender_access hash:/etc/postfix/reject_ndn smtpd_sender_restrictions = check_recipient_access hash:/etc/postfix/backscatter_recipient # backscatter_recipient vic...@example.com reject_ndn # reject_ndn <> REJECT please don't send notices to forged sender i will give this a try also. thanks for the information. -- Noel Jones
Re: user getting spoofed
On Feb 19, 2009, at 10:39 AM, Noel Jones wrote: jeff donovan wrote: Greetings I have a user whos name is being spoofed by the spammers of the world. and her mailbox is getting flooded by legitimate Mailer Delivery notices. Is there anything i can do for her besides change her account name ? I was thinking about a temporary regex to discard those notices. ( i know not the best but it may stem the tide ). any assistance is welcome -jeff General suggestions for combating backscatter: http://www.postfix.org/BACKSCATTER_README.html You can use the ips.backscatterer.org to reject bounces (*NOT* all mail) from known backscatter sources. Do this in smtpd_data_restrictions for compatibility with sender address verification. # main.cf smtpd_data_restrictions = check_sender_access hash:/etc/postfix/backscatterer # backscatterer <> reject_rbl_client ips.backscatterer.org In this case you may also want to *temporarily* reject all NDNs addressed to that particular user. General instructions: http://www.postfix.org/RESTRICTION_CLASS_README.html more specific: # main.cf smtpd_restriction_classes = reject_ndn reject_ndn = check_sender_access hash:/etc/postfix/reject_ndn smtpd_sender_restrictions = check_recipient_access hash:/etc/postfix/backscatter_recipient # backscatter_recipient vic...@example.com reject_ndn # reject_ndn <> REJECT please don't send notices to forged sender -- Noel Jones Greetings, I have added the data restrictions, the restrictions class, and the sender restrictions. is there an error number or something I can grep in my logs to check how these new restrictions are functioning? or if they are even having an effect?
Re: user getting spoofed
On Feb 20, 2009, at 9:56 AM, J.P. Trosclair wrote: jeff donovan wrote: # reject_ndn <> REJECT please don't send notices to forged sender -- Noel Jones Greetings, I have added the data restrictions, the restrictions class, and the sender restrictions. is there an error number or something I can grep in my logs to check how these new restrictions are functioning? or if they are even having an effect? You should see the REJECT please... from Noel's example in the logs. J.P. ah yes,.. got it thanks
Re: user getting spoofed :; update ::
On Feb 20, 2009, at 9:56 AM, J.P. Trosclair wrote: jeff donovan wrote: # reject_ndn <> REJECT please don't send notices to forged sender -- Noel Jones Greetings, I have added the data restrictions, the restrictions class, and the sender restrictions. is there an error number or something I can grep in my logs to check how these new restrictions are functioning? or if they are even having an effect? You should see the REJECT please... from Noel's example in the logs. J.P. okay,.. no errors in logs I am now the proud recipient of a million of these. all from different domains. Transcript of session follows. Out: 220 mail2.beth.k12.pa.us ESMTP Postfix In: EHLO svma15-2.kanden.ne.jp Out: 250-my.mx.server Out: 250-PIPELINING Out: 250-SIZE 10485760 Out: 250-VRFY Out: 250-ETRN Out: 250-AUTH LOGIN PLAIN Out: 250 8BITMIME In: MAIL FROM:<> SIZE=5783 BODY=8BITMIME Out: 250 Ok In: RCPT TO: Out: 250 Ok In: DATA Out: 451 Server configuration error In: RSET Out: 250 Ok In: QUIT Out: 221 Bye
Re: user getting spoofed
On Feb 20, 2009, at 9:56 AM, J.P. Trosclair wrote: You should see the REJECT please... from Noel's example in the logs. J.P. got it working. Feb 20 11:07:51 mail2 postfix/smtpd[28710]: NOQUEUE: reject: RCPT from mailrelay1.msp.eschelon.com[209.150.200.11]: 557 <>: Sender address rejected: please don't send notices to forged sender; from=<> to= proto=ESMTP helo=
Re: user getting spoofed :; update ::
On Feb 20, 2009, at 11:51 AM, Noel Jones wrote: jeff donovan wrote: okay,.. no errors in logs I beg to differ... Just not the errors you've looked for. I am now the proud recipient of a million of these. all from different domains. Transcript of session follows. Out: 220 mail2.beth.k12.pa.us ESMTP Postfix In: EHLO svma15-2.kanden.ne.jp Out: 250-my.mx.server Out: 250-PIPELINING Out: 250-SIZE 10485760 Out: 250-VRFY Out: 250-ETRN Out: 250-AUTH LOGIN PLAIN Out: 250 8BITMIME In: MAIL FROM:<> SIZE=5783 BODY=8BITMIME Out: 250 Ok In: RCPT TO: Out: 250 Ok In: DATA Out: 451 Server configuration error In: RSET Out: 250 Ok In: QUIT Out: 221 Bye Good, apparently you aren't receiving (some of) them any more. Bad, you goofed somewhere in the setup so postfix is tempfailing the messages rather than rejecting them. yeah typos, i fixed them. More information is in the postfix log. Grep for "Server configuration error" and look at that line and other nearby lines for clues to the problem. -- Noel Jones
Re: user getting spoofed
On Feb 20, 2009, at 12:18 PM, Noel Jones wrote: jeff donovan wrote: On Feb 20, 2009, at 9:56 AM, J.P. Trosclair wrote: You should see the REJECT please... from Noel's example in the logs. J.P. got it working. You can also # grep 'reject: .*backscatterer' /var/log/maillog to see how your RBL is working. Feb 20 11:07:51 mail2 postfix/smtpd[28710]: NOQUEUE: reject: RCPT from mailrelay1.msp.eschelon.com[209.150.200.11]: 557 <>: Sender address rejected: please don't send notices to forged sender; from=<> to= proto=ESMTP helo= Why are you using a reject code "557"? Please don't make up your own reject codes, the default is correct and sufficient. I had individual numbers so I could tell which access list was doing what. #unknown_local_recipient_reject_code = 550 #unknown_address_reject_code = 554 #unknown_hostname_reject_code = 555 #unknown_client_reject_code = 556 #access_map_reject_code = 557 #maps_rbl_reject_code = 558 i commented them out. Remove any *reject_code entries from your main.cf and let postfix use the defaults. done. -- Noel Jones
Mail forwarding
Can I use Postfix as a host for email forwarding? The scenario I envision is an Alum or Faculty member authenticates to a web portal, then tells the system where to forward their email. All email destined for Staff would go to our current email system. Any thoughts are welcome. Regards, Jeff "It does not require many words to speak the truth." - Chief Joseph, Great Nez Perce Indian Chief
Re: Mail forwarding
Thank you Viktor for your reply. We already have an anti-spam/anti-virus system sitting in front of our mail system. Would this then work if Postfix were positioned similarly? >>> Victor Duchovni 3/11/2009 1:48 PM >>> On Wed, Mar 11, 2009 at 01:35:26PM -0400, Jeff Bernier wrote: > Can I use Postfix as a host for email forwarding? > > The scenario I envision is an Alum or Faculty member authenticates to > a web portal, then tells the system where to forward their email. All > email destined for Staff would go to our current email system. > You *can* do this, but probably should not. The problem is that your forwarder will be saturated with spam that you will be poorly positioned to process. Receiving systems will soon blacklist your forwarder, and it becomes useless. Quaranine is not an option, and tagging will not be acceptable to receiving sites. Your only choice is to have a very effective filter to reject spam during SMTP, not easy to do. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the "Reply-To" header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: <mailto:majord...@postfix.org?body=unsubscribe%20postfix-users> If my response solves your problem, the best way to thank me is to not send an "it worked, thanks" follow-up. If you must respond, please put "It worked, thanks" in the "Subject" so I can delete these quickly.
Good Reading
I'm looking for a good one-stop guide for Postfix. I'm a newbie. Any suggested reading?
How to index maildir
Hi,my mailserver is postfix and the mailbox is set to /Maildir. But I found if there are too many email in maildir,the imap is very slow. Can we set the Maildir indexing?So we can accelerate to read/find the email from Maildir. Thank you. Jeff Huang 2009-03-22
Re: Re: How to index maildir
OK,Thanks. I'll try cyrus imap. Now I use Courier-imap as my imap/pop3 server. Jeff Huang 2009-03-22 发件人： vg...@hotmail.com 发送时间： 2009-03-22 10:33:00 收件人： jbhu...@scut.edu.cn; postfix-users 抄送： 主题： Re: How to index maildir -- From: "Jeff Huang" Sent: Saturday, March 21, 2009 9:58 PM To: "postfix-users" Subject: How to index maildir > Hi,my mailserver is postfix and the mailbox is set to /Maildir. > > But I found if there are too many email in maildir,the imap is very slow. > > Can we set the Maildir indexing?So we can accelerate to read/find the > email from Maildir. > that's a job of imap server, not mta (postfix). cyrus does it, dovecot too. dovecot is more flexible - it cat keep those indexes on different partition (ram disk maybe? ). or - you can get a very fast filesystem - in my tests ext3 with default setting won't work with 1000+ messages in one directory - 10-20 clients can make it crawl. that's why we (where I work) still use NetApp filer. cheers vadim > Thank you. > > > > > Jeff Huang > 2009-03-22 >
virtual_transport from mysql table
Hello, I'd like to get my postfix system to pull the virtual transport from a table, so that I can have some domains use procmail and others use Dovecot's deliver while I test this out. I'm adding this to a system that is already up and running using mysql for lookups of users, passwords, etc. So the other parts are all working, and procmail/deliver work if I set them in virtual_transport. I'm not sure exactly how to do this. I have a table containing the fields 'domain' and 'transport'. In 'transport', I've listed the transport as it appears in master.cf: either dovecot or procmail. Am I on the right track? How then do I get postfix to use this? Jeff
Plus Addressing
I have set up "recipient_delimiter = +" so I could put a folder name in an e-mail address and have it automatically filtered for me. I am using "mailbox_command = /usr/local/libexec/dovecot/deliver -n -m "$EXTENSION"" as my mailbox_command. When the mail gets passed to deliver, the extension is lower case even if it originally started as uppercase. I asked on the Dovecot mailing list how I can convert it to uppercase for Deliver. Timo stated that Deliver does not do any case changing and that Postfix must be passing the variable in lower case. Is there a way for me to not have Postfix change the case? My folder names all start with a capital letter. Deliver cannot find the mailbox because "folder" does not equal "Folder". Thanks, Jeff
Re: Plus Addressing
On 4/16/2009 10:44 PM, Victor Duchovni wrote: On Thu, Apr 16, 2009 at 08:24:54PM -0700, Jeff Grossman wrote: I have set up "recipient_delimiter = +" so I could put a folder name in an e-mail address and have it automatically filtered for me. I am using "mailbox_command = /usr/local/libexec/dovecot/deliver -n -m "$EXTENSION"" as my mailbox_command. When the mail gets passed to deliver, the extension is lower case even if it originally started as uppercase. I asked on the Dovecot mailing list how I can convert it to uppercase for Deliver. Timo stated that Deliver does not do any case changing and that Postfix must be passing the variable in lower case. Is there a way for me to not have Postfix change the case? My folder names all start with a capital letter. Deliver cannot find the mailbox because "folder" does not equal "Folder". Don't use mailbox_command, use mailbox_transport (assuming that in your case deliver can work acceptably running as a fixed pipe(8) user rather than as the recipient). The recipient extension in local(8) deliveries is converted to lower-case (the entire local-part is converted to lower-case, before the extension is extracted). Thanks for the information. The problem I have with that is all of my users are local system users. I don't think I can use mailbox_transport with local users only virtual users. It appears the only way I can do what I want is to switch to virtual users. Jeff
Re: Plus Addressing
On 4/17/2009 6:54 AM, Jeff Grossman wrote: On 4/16/2009 10:44 PM, Victor Duchovni wrote: On Thu, Apr 16, 2009 at 08:24:54PM -0700, Jeff Grossman wrote: I have set up "recipient_delimiter = +" so I could put a folder name in an e-mail address and have it automatically filtered for me. I am using "mailbox_command = /usr/local/libexec/dovecot/deliver -n -m "$EXTENSION"" as my mailbox_command. When the mail gets passed to deliver, the extension is lower case even if it originally started as uppercase. I asked on the Dovecot mailing list how I can convert it to uppercase for Deliver. Timo stated that Deliver does not do any case changing and that Postfix must be passing the variable in lower case. Is there a way for me to not have Postfix change the case? My folder names all start with a capital letter. Deliver cannot find the mailbox because "folder" does not equal "Folder". Don't use mailbox_command, use mailbox_transport (assuming that in your case deliver can work acceptably running as a fixed pipe(8) user rather than as the recipient). The recipient extension in local(8) deliveries is converted to lower-case (the entire local-part is converted to lower-case, before the extension is extracted). Thanks for the information. The problem I have with that is all of my users are local system users. I don't think I can use mailbox_transport with local users only virtual users. It appears the only way I can do what I want is to switch to virtual users. Jeff One more thing I noticed today also. All messages which have the "+" in the e-mail are sent to Dovecot's Deliver twice. So, I receive the message twice in the folder. All other messages are only sent to Deliver once. Any idea what I have configured wrong for the message to be sent twice?
Re: Plus Addressing
On 4/17/2009 7:11 AM, Brian Evans - Postfix List wrote: Jeff Grossman wrote: On 4/16/2009 10:44 PM, Victor Duchovni wrote: On Thu, Apr 16, 2009 at 08:24:54PM -0700, Jeff Grossman wrote: I have set up "recipient_delimiter = +" so I could put a folder name in an e-mail address and have it automatically filtered for me. I am using "mailbox_command = /usr/local/libexec/dovecot/deliver -n -m "$EXTENSION"" as my mailbox_command. When the mail gets passed to deliver, the extension is lower case even if it originally started as uppercase. I asked on the Dovecot mailing list how I can convert it to uppercase for Deliver. Timo stated that Deliver does not do any case changing and that Postfix must be passing the variable in lower case. Is there a way for me to not have Postfix change the case? My folder names all start with a capital letter. Deliver cannot find the mailbox because "folder" does not equal "Folder". Don't use mailbox_command, use mailbox_transport (assuming that in your case deliver can work acceptably running as a fixed pipe(8) user rather than as the recipient). The recipient extension in local(8) deliveries is converted to lower-case (the entire local-part is converted to lower-case, before the extension is extracted). Thanks for the information. The problem I have with that is all of my users are local system users. I don't think I can use mailbox_transport with local users only virtual users. It appears the only way I can do what I want is to switch to virtual users. You are confusing mailbox_transport and virtual_transport. See: http://www.postfix.org/postconf.5.html#mailbox_transport Brian Thanks for the help and information. I am going to see if I can figure out how to configure Dovecot to use mailbox_transport with system users. Jeff
Re: Plus Addressing
On 4/17/2009 9:08 AM, Mark Martinec wrote: Jeff, One more thing I noticed today also. All messages which have the "+" in the e-mail are sent to Dovecot's Deliver twice. So, I receive the message twice in the folder. All other messages are only sent to Deliver once. Any idea what I have configured wrong for the message to be sent twice? It probably has to do with where you implemented recipient_bcc_maps, along with a post-queue content filter which sends a checked message back to Postfix for delivery - so recipient_bcc_maps could be invoked twice. Mark Aw, that makes sense. I have Amavis configured. I must have done something wrong with that. Here is a copy of my master.cf file. Would you be able to tell me what I have set wrong? # # Postfix master process configuration file. For details on the format # of the file, see the master(5) manual page (command: "man 5 master"). # # Do not forget to execute "postfix reload" after editing this file. # # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # == smtp inet n - n - - smtpd -o receive_override_options=no_address_mappings submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING #628 inet n - n - - qmqpd pickupfifo n - n 60 1 pickup -o content_filter= -o receive_override_options=no_header_body_checks cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr #qmgr fifo n - n 300 1 oqmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verifyunix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - n - - smtp -o smtp_fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 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 smtp-amavis unix- - n - 4 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 -o smtp_tls_note_starttls_offer=no 127.0.0.1:10025 inet n- n - - smtpd -o content_filter= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters -o local_header_rewrite_clients=
Re: Plus Addressing
On 4/22/2009 12:17 PM, Mark Martinec wrote: Jeff, One more thing I noticed today also. All messages which have the "+" in the e-mail are sent to Dovecot's Deliver twice. So, I receive the message twice in the folder. All other messages are only sent to Deliver once. Any idea what I have configured wrong for the message to be sent twice? It probably has to do with where you implemented recipient_bcc_maps, along with a post-queue content filter which sends a checked message back to Postfix for delivery - so recipient_bcc_maps could be invoked twice. Aw, that makes sense. I have Amavis configured. I must have done something wrong with that. Here is a copy of my master.cf file. Would you be able to tell me what I have set wrong? 127.0.0.1:10025 inet n- n - - smtpd -o content_filter= [...] -o receive_override_options=no_header_body_checks, no_unknown_recipient_checks,no_milters You can add 'no_address_mappings' to the list in receive_override_options. It turns off automatic BCC, among other things. See: http://www.postfix.org/postconf.5.html#receive_override_options It this option is too strong (e.g. you don't want recipient_bcc_maps on port 10025, yet you do want canonical or virtual alias map expansion after a content filter), then you need to use a more complicated solution with two cleanup services (or two Postfix instances). See: http://www.ijs.si/software/amavisd/README.postfix.html -> Multiple cleanup service architecture I did some research and added the following line to main.cf and removed the "-o receive_override_options=no_address_mappings" from the smtp section of the master.cf file. receive_override_options = no_address_mappings Everything seems to be working ok. I am no longer getting duplicate messages when I forward mail via recipient_bcc. Am I hurting myself at all doing the receive_override in main.cf instead of in master.cf? Thanks, Jeff
How to encrypt email?
Hi All. I found the email files that are stored under the Maildir are clearly code. If I am the administrator of the system,I can see all user's email contents. Is there a method to encrypt the email files so that the administrator can't see the email contents,even if he can read the files? Jeff Huang
Postfix Setup
Hello, I am a newbie... I wish to use my Postfix system (v2.1.5) to accept mail for, and relay mail to another MTA. How do I go about doing this? Thank you for any help offered. Jeff "It does not require many words to speak the truth." - Chief Joseph, Great Nez Perce Indian Chief
Re: Postfix Setup
I don't want to sound ungrateful for pointing me at the docs, but I was hoping for a little clarification on the process. I had looked at the docs, but was still unclear on how to go about it. Jeff victor.ducho...@morganstanley.com 5/5/2009 11:00 AM >>> On Tue, May 05, 2009 at 10:51:58AM -0400, Jeff Bernier wrote: > Hello, > > I am a newbie... > > I wish to use my Postfix system (v2.1.5) to accept mail for, and relay > mail to another MTA. How do I go about doing this? http://www.postfix.org/BASIC_CONFIGURATION_README.html http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the "Reply-To" header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: <mailto:majord...@postfix.org?body=unsubscribe%20postfix-users> If my response solves your problem, the best way to thank me is to not send an "it worked, thanks" follow-up. If you must respond, please put "It worked, thanks" in the "Subject" so I can delete these quickly.
Re: Postfix Setup
I had asked a fairly clear question... it was: Ho do I set Postfix to accept email for, and relay email to another MTA? This is the one thing I need to accomplish. There's really no need to berate me and otherwise treat me like a buffoon Victor. Is there someone willing to help? Please? >>> Victor Duchovni 5/5/2009 11:47 AM >>> On Tue, May 05, 2009 at 11:32:36AM -0400, Jeff Bernier wrote: > I don't want to sound ungrateful for pointing me at the docs, but I > was hoping for a little clarification on the process. I had looked at > the docs, but was still unclear on how to go about it. Specific questions are much easier to answer than "How do I go about doing this?". Carefully identify and write down the requirements for the new system. What must it do (in detail). What must it not do (in detail). This means identifying "use cases", concrete events that occur and how the system should respond. Once you understand the requirements, you need to configure the system to behave the way you want it to behave. Divide the problem into parts, identify which parts you understand and which you are unclear about. Ask specific questions about the parts that are not clear to you and provide a detailed description of the relevant "use case". > victor.ducho...@morganstanley.com 5/5/2009 11:00 AM >>> > On Tue, May 05, 2009 at 10:51:58AM -0400, Jeff Bernier wrote: > > > Hello, > > > > I am a newbie... > > > > I wish to use my Postfix system (v2.1.5) to accept mail for, and relay > > mail to another MTA. How do I go about doing this? > > http://www.postfix.org/BASIC_CONFIGURATION_README.html > http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the "Reply-To" header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: <mailto:majord...@postfix.org?body=unsubscribe%20postfix-users> If my response solves your problem, the best way to thank me is to not send an "it worked, thanks" follow-up. If you must respond, please put "It worked, thanks" in the "Subject" so I can delete these quickly.
backup email
Hi. I want the email server backup the sending out email. For example.The user send a email out to other user,the smtp server copy it and send it to a backup server when it sending the email out. So the administrator or the user can saw the email which he/she sent out. Can the postfix do it and how to ? Thanks. Jeff Huang
Re: Re: backup email
Another way,I want the mail server to deliver all the receiveing mails to two mailBox server(maybe tow pop server). I found the transport_maps can set the relay host that next hop. I set it as: domain1.comrelay:[server1.domian1.com],[server2.domain2.com] But it failed,How can I do for it? Jeff Sender: Corey Chandler Date: 2009-05-06 15:11:15 Subject: Re: backup email Jeff Huang wrote: > Hi. > > I want the email server backup the sending out email. > > For example.The user send a email out to other user,the smtp server > copy it and send it to a backup server when it sending the email out. > > So the administrator or the user can saw the email which he/she sent out. > > Can the postfix do it and how to ? > Check the always_bcc directive. -- Corey Chandler / KB1JWQ Living Legend / Systems Exorcist Today's Excuse: multicasts on broken packets
How to check fake mail
Hi. I have a smtp server and it need to authorized by the id and psw before send mail. But I found I can send a fake mail. For example,I use id1 to authorize and send a email which is mail from i...@domain.com. Is there some methord to check it and prevent from it? Jeff EMail:jbhu...@scut.edu.cn 2009-05-26
Re: Log question
On Mon, 8 Jun 2009 17:18:32 +0200, "Jack Knowlton" wrote: > Hi all. > Today, while sending an email, I monitored postfix's log. The message was > going thru postfix and then relayed to the recipient's MX: > > Jun 8 13:03:21 dsrv postfix/smtpd[13477]: AADDD17B812: > client=whatever[xx.xx.xx.xx], sasl_method=LOGIN, > sasl_username=u...@mydomain.com > Jun 8 13:03:22 dsrv postfix/qmgr[3139]: AADDD17B812: > from=, size=1395, nrcpt=1 (queue active) > Jun 8 13:03:24 dsrv postfix/qmgr[3139]: 4CF1A17D17C: > from=, size=1838, nrcpt=2 (queue active) > Jun 8 13:03:24 dsrv amavis[26650]: (26650-04) Passed CLEAN, [xx.xx.xx.xx] > [xx.xx.xx.xx] -> , Message-ID: > <005f01c9e828$5f41bf50$1dc53d...@com>, mail_id: OXs5BXQ6GyU0, Hits: > -4.012, size: 1395, queued_as: 4CF1A17D17C, 1939 ms > Jun 8 13:03:30 dsrv postfix/smtp[27317]: 4CF1A17D17C: > to=, relay=172.16.0.10[172.16.0.10]:25, > delay=6.5, delays=0.05/0.06/5.7/0.72, dsn=2.0.0, status=sent (250 2.0.0 > Ok: queued as 0F353B81E) > > Until here, everything was kosher. Amavis processed the message and > postfix correctly applied the "sender_bcc_maps" setting. > What I don't really get, is what happened next: > > Jun 8 13:04:14 dsrv postfix/smtpd[13477]: connect from > polluce.unimo.it[155.185.1.151] > Jun 8 13:04:17 dsrv postfix/smtpd[13477]: EFF8117B812: > client=polluce.unimo.it[155.185.1.151] > Jun 8 13:04:17 dsrv postfix/smtpd[13477]: disconnect from > polluce.unimo.it[155.185.1.151] > Jun 8 13:04:23 dsrv postfix/smtp[27318]: 4CF1A17D17C: > to=, relay=polluce.unimo.it[155.185.1.151]:25, delay=59, > delays=0.05/0.07/49/9.4, > dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 7EDDA26494) > Jun 8 13:04:23 dsrv postfix/qmgr[3139]: 4CF1A17D17C: removed > > I understand the message was succesfully delivered to the recipient's > server, but where the heck did EFF8117B812 come from? > And where did it go, since there are no further traces in the logs of that > queue id? I am by no means an expert at e-mail. But, my first guess would be that the server at polluce.unimo.it did a test of the recipient of the e-mail. It connected, tested the recipient e-mail address, and then disconnected. Jeff
XCLIENT patch for postfix
Wietse: Happy new year :) We use niginx's smtp function to redirect mail to postfix server. But in postfix, XCLIENT command can't support the LOGIN paremeter. Severial months ago, I write a patch for postfix-2.5.3. Now nginx official website also supply a patch for this situation as followed: http://www.citrin.ru/nginx:xclient-login-patch. In additional, my patch also support xforward function. We will be very grateful to you if you can accept these patch (nginx official patch or our patch). Of course, you'd better add this function to your new version. After that We can use new version directly, other than patch the original source manually. jeff geng 2010-1-5 postfix-2.5-patch03 Description: Binary data
Re: XCLIENT patch for postfix
Wietse: Please see my reply marked as blue. :) jeff geng 2010/1/5 Wietse Venema > jeff geng: > > Wietse: > > > > Happy new year :) > > > > We use niginx's smtp function to redirect mail to postfix server. But in > > postfix, XCLIENT command can't support the LOGIN paremeter. > > Severial months ago, I write a patch for postfix-2.5.3. Now nginx > official > > website also supply a patch for this situation as followed: > > http://www.citrin.ru/nginx:xclient-login-patch. In additional, my patch > also > > support xforward function. > > > > We will be very grateful to you if you can accept these patch (nginx > > official patch or our patch). Of course, you'd better add this function > to > > your new version. > > After that We can use new version directly, other than patch the original > > source manually. > > Can you explain the following: > > + int got_login =0; > ... > + got_login = 1; > > Why is the got_login variable introduced? It is a write-only variable. > We introduce got_login is for the same reason as got_helo and got_proto.It means postfix has got login information from client, and postfix should save the username and password from XCLIENT. > #ifdef USE_SASL_AUTH > if (var_smtpd_sasl_enable) > ! if (got_proto == 0) > ! smtpd_sasl_auth_reset(state); > #endif > > Why test for the PROTO attribute here? What happens when the client > sends LOGIN=username before PROTO=SMTP? As documented XCLIENT does > not require that attributes are sent in a specific order. > > This is my mistake. It should be if (got_login == 0 && ar_smtpd_sasl_enable(state)) . It means if postfix can't get login infomation from XCLIENT, postfix will involk smtpd_sasl_auth_reset to cleanup state->sasl_username and >sasl_method. After that, if user want to authenticate, he will authenticate through auth login. > > + UPDATE_STR(state->sasl_username, attr_value); > + printable(state->sasl_username, '?'); > + UPDATE_STR(state->sasl_method, "xclient"); > > Why not use the real authentication mechanism? > Otherwise, if XCLIENT pass LOGIN parameter, state->sasl_username and state->sasl_method will be updated, postfix will deem it as an authenticated client. So , if nginx pass through LOGIN parameter, postfix should identify it as a authenticated client, but postix XCLIENT can't support this parameter.
Re: XCLIENT patch for postfix
Wietse: If We modify #ifdef USE_SASL_AUTH if (var_smtpd_sasl_enable) if (got_proto == 0) smtpd_sasl_auth_reset(state); #endif to #ifdef USE_SASL_AUTH if (var_smtpd_sasl_enable) if (got_login == 0) smtpd_sasl_auth_reset(state); #endif the got_login will be used.But this is not the key issues. If nginx will support SASL_USER and SASL_METH parameters, it would be best. If you can put something into Postfix for current nginx We will be very grateful to you. Thank you. jeff geng 2010/1/6 Wietse Venema > Wietse Venema: > > > > + UPDATE_STR(state->sasl_username, attr_value); > > > > + printable(state->sasl_username, '?'); > > > > + UPDATE_STR(state->sasl_method, "xclient"); > > > > > > > > Why not use the real authentication mechanism? > > > > > > > > > > Otherwise, if XCLIENT pass LOGIN parameter, state->sasl_username and > > > state->sasl_method will be updated, postfix will deem it as an > authenticated > > > client. > > > So , if nginx pass through LOGIN parameter, postfix should identify it > as a > > > authenticated client, but postix XCLIENT can't support this parameter. > > > > XCLIENT can support both the login name and the authentication > > method name, and therefore nginx should pass both to Postfix. > > I noticed that the nginx reverse proxy implements TLS, so it makes > sense to plan for future XCLIENT extensions that propagate TLS > attributes, besides the extension for SASL that you introduced with > this thread. > > This means using something like SASL_USER and SASL_METH for the > proposed SASL attributes, and TLS_XXX for future TLS attributes, > so that there will be no conflicts between the names. > > I keep whining about the SASL authentication method, because that > information is used by the Postfix "permit_sasl_authenticated" > access control feature. It would therefore be wrong to set this to > a fixed value like your patch does. > > Now that I understand how your patch is supposed to work, I can > put something into Postfix, but it would help if we can agree on > the attribute names and on the protocol details. > > I am sure that there are a few gotchas when you poke Postfix SASL > attributes without proper initialization and cleanup of the Postfix > SASL layer, but that can be fixed by adding a few functions to that > SASL layer that handle support for proxied attributes. > >Wietse >
allowing outside users access to mailman lists
I am hoping that this is something fairly simple that I am missing
I have a few lists on a mailman server that I run. Until recently, only
authenticated users (those who have actual accounts on my IMAP/Virtual
mailboxes server and can authenticate via SASL). Now I want to allow certain
users who are not authenticated (i. e. they are outside my server and
domains) to send mail to those lists.
as far as I can tell, mailman would allow this (I've made them list owners).
But when they try, I'm getting this in my mail log:
Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from
ns1.siteground235.com[75.125.60.15]: 554 5.7.1 <
myl...@lists.mylistserver.com>: Relay access denied; from=<
otheru...@otherdomain.com> to= proto=ESMTP
helo=
(names changed to protect the innocent, no data changes of relevance)
I've tried a few changes (I'd log them here, if I had documented them,
sorry) that I thought would have taken away the authentication requirement,
to no avail. this might also me an issue of the HELO domain and the FROM
domain being different (which is OK, in this case, but not sure how I have
prohibited it, so don't know what to change.
The goal is to allow outside users without opening up the mailserver (or the
mailman server) to spam, etc...
FYI: the transport for everything to lists.mylistserver.com is mailman: and
lists.mylistserver.com is in $relay_domains
Here are snips from my master.cf that show the path of the message (in smtp,
into amavisd content filter, out of amavisd on 10026 and to mailman)
smtp inet n - n - - smtpd
-o recipient_bcc_maps=mysql:/etc/postfix/mysql_recipient_bcc_maps.cf
-o receive_override_options=no_address_mappings
-o content_filter=amavisfeedl:[127.0.0.1]:10027
amavisfeedl unix- - n- 2 lmtp
-o lmtp_data_done_timeout=1200
-o lmtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20
localhost:10026 inet n - n - - smtpd
-o content_filter=
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_sender_restrictions=
-o
smtpd_recipient_restrictions=permit_mynetworks,permit_auth_destinations,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o smtpd_delay_reject=no
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
-o local_header_rewrite_clients=
mailman unix - n n - 10 pipe
flags=FR user=_mailman argv=/usr/local/mailman/postfix-to-mailman.py
${nexthop} ${user}
and my `postconf -n` output is below.
I'm running Postfix 2.6.5 on Mac OS/X (client) 10.5.8
Any help is appreciated and I will do my best to answer any questions.
Thank you!
--Jeff
-`postconf -n` output
alias_database = mysql:/etc/postfix/mysql_alias_maps.cf
alias_maps = mysql:/etc/postfix/mysql_alias_maps.cf
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_verp_delimiters = +=
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks.pcre
html_directory = /etc/postfix/html
inet_interfaces = all
local_recipient_maps =
luser_relay = ot...@jeffweinberger.com
mail_owner = _postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 0
mydestination = mysql:/etc/postfix/mysql_mydestination_maps.cf
mydomain = jweinberger.homeip.net
myhostname = jweinberger.homeip.net
mynetworks = 127.0.0.0/8, !10.0.1.1, !10.0.1.210, 10.0.1.0/28
newaliases_path = /usr/bin/newaliases
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination, mysql:/etc/postfix/
mysql_relay_domain_maps.cf
relay_recipient_maps =
relayhost = outbound.mailhop.org
sample_directory = /usr/share/doc/postfix/examples
sender_canonical_maps = mysql:/etc/postfix/mysql_sender_canonical_maps.cf
sendmail_path = /usr/sbin/sendmail
setgid_group = _postdrop
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
smtp_tls_CAfile = /etc/postfix/certs/demoCA/cacert.pem
smtp_tls_cert_file = /etc/postfix/certs/postfix-cert.pem
smtp_tls_key_file = /etc/postfix/certs/postfix-key.pem
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtp_tls_session_cache_database =
btree:/var/lib/postfix
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, mouss wrote: > > Jeff Weinberger a �crit : > > I am hoping that this is something fairly simple that I am missing > > > > I have a few lists on a mailman server that I run. Until recently, only > > authenticated users (those who have actual accounts on my IMAP/Virtual > > mailboxes server and can authenticate via SASL). Now I want to allow > > certain users who are not authenticated (i. e. they are outside my > > server and domains) to send mail to those lists. > > > > as far as I can tell, mailman would allow this (I've made them list > > owners). But when they try, I'm getting this in my mail log: > > > > Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from > > ns1.siteground235.com <http://ns1.siteground235.com/>[75.125.60.15]: 554 > > 5.7.1 > <mailto:myl...@...>>: Relay access denied; > > from=mailto:otheru...@...>> > > to= > <mailto:myl...@...>> proto=ESMTP > > helo=http://serv01.siteground235.com/>> > > > > you need to add lists.mylistserver.com to one (and only one) of > mydestination, relay_domains or virtual_maibox_domains. >From my original post: FYI: the transport for everything to lists.mylistserver.com is mailman: and lists.mylistserver.com is in $relay_domains which means that it is not working as you suggest it should Any suggestions on where else to look? > > > [snip] >
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, Wietse Venema wrote:
>
> Jeff Weinberger:
> [ Charset UTF-8 unsupported, converting... ]
> > --- In postfix-us...@yahoogroups.com, mouss wrote:
> > >
> > > Jeff Weinberger a ?crit :
> > > > I am hoping that this is something fairly simple that I am
missing
> > > >
> > > > I have a few lists on a mailman server that I run. Until recently,
only
> > > > authenticated users (those who have actual accounts on my
IMAP/Virtual
> > > > mailboxes server and can authenticate via SASL). Now I want to allow
> > > > certain users who are not authenticated (i. e. they are outside my
> > > > server and domains) to send mail to those lists.
> > > >
> > > > as far as I can tell, mailman would allow this (I've made them list
> > > > owners). But when they try, I'm getting this in my mail log:
> > > >
> > > > Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from
> > > > ns1.siteground235.com <http://ns1.siteground235.com/>[75.125.60.15]:
554
> > > > 5.7.1 > > > <mailto:mylist@>>: Relay access denied;
>
> You have not listed the domain in relay_domains, virtual_alias_domains,
> virtual_mailbox_domains or mydestination.
>
> Convince yourself and examine the output from:
>
> # postconf relay_domains
> # postconf virtual_alias_domains
> # postconf mailbox_domains
> # postconf mydestination
>
> Wietse
>
I did this test prior to posting. You'll see in my postconf -n output that:
relay_domains = $mydestination, mysql:/etc/postfix/
mysql_relay_domain_maps.cf
I then checked with `postmap -q "maill...@lists.mylistserver.com"
mysql:/etc/postfix/mysql_relay_domain_maps.cf` and it showed up fine.
There is a possibility that the MySQL query is returning a result that is
not what postfix needs. I have perused the documentation on this repeatedly
and found no specification as to what that query should return for postfix
to accept the domain.
I have tried it where postfix returns the domain ("lists.mylistserver.com"
without the quotes) and where it returns the value "OK" (again, without the
quotes) and neither one works.
If you can offer specifics on what that query should return, I will make it
do so and test again.
Otherwise, if the proper return value is one of those noted, I'd appreciate
other suggestions on why this might not be working.
Thanks!
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, Wietse Venema wrote: > > Jeff Weinberger: > > > > > > Jeff Weinberger: > > > [ Charset UTF-8 unsupported, converting... ] > > > > --- In postfix-us...@yahoogroups.com, mouss wrote: > > > > > > > > > > Jeff Weinberger a ?crit : > > > > > > I am hoping that this is something fairly simple that I am > > missing > > > > > > > > > > > > I have a few lists on a mailman server that I run. Until recently, > > only > > > > > > authenticated users (those who have actual accounts on my > > IMAP/Virtual > > > > > > mailboxes server and can authenticate via SASL). Now I want to allow > > > > > > certain users who are not authenticated (i. e. they are outside my > > > > > > server and domains) to send mail to those lists. > > > > > > > > > > > > as far as I can tell, mailman would allow this (I've made them list > > > > > > owners). But when they try, I'm getting this in my mail log: > > > > > > > > > > > > Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from > > > > > > ns1.siteground235.com <http://ns1.siteground235.com/>[75.125.60.15]: > > 554 > > > > > > 5.7.1 > > > > > <mailto:mylist@>>: Relay access denied; > > > > > > You have not listed the domain in relay_domains, virtual_alias_domains, > > > virtual_mailbox_domains or mydestination. > > > > > > Convince yourself and examine the output from: > > > > > > # postconf relay_domains > > > # postconf virtual_alias_domains > > > # postconf mailbox_domains > > > # postconf mydestination > > > > > > Wietse > > > > > > > I did this test prior to posting. You'll see in my postconf -n output that: > > > > relay_domains = $mydestination, mysql:/etc/postfix/ > > mysql_relay_domain_maps.cf > > > > I then checked with `postmap -q "maill...@..." > > mysql:/etc/postfix/mysql_relay_domain_maps.cf` and it showed up fine. > > Sorry, that is incorrect. > > As documented, Postfix searches relay_domains for the DOMAIN NAME > not the email address. > http://www.postfix.org/postconf.5.html#relay_domains > > Also, as documented, relay_domains lookup ignores the result value, > it only cares about existence. > http://www.postfix.org/postconf.5.html#relay_domains > > Finally, as documented, don't use MySQL databases BEFORE you have things > working with simple main.cf lists or hash tables. > http://www.postfix.org/DATABASE_README.html > > Wietse > OK, point taken. I have now, based on your suggestion tested the following: `postmap -q "maill...@lists.mylistserver.com" mysql:/etc/postfix/ mysql_relay_domain_maps.cf` and `postmap -q "lists.mylistserver.com" mysql:/etc/postfix/ mysql_relay_domain_maps.cf` Both returned successful results. I tested this extensively with the domains typed in to mail.cf before I moved to mysql queries, but at your suggestion, I tested this also. I changed main.cf so the only "relay_domains" entry is: relay_domains=lists.mylistserver.com I executed `sudo postfix reload` and the confirmed the setting with `postconf -n` The result did not change. I received the same NOQUEUE message in my logs (it is identical in every character to the one I posted previously, with the exception of the timestamp). I suspect you may have other suggestions as to how to address the relay domain issue, and I would appreciate them, and will do my best to try them. However, I am coming to believe that the issue is not in the relay domains, but rather in a sender or recipient restriction. I believe this because whenever I send to any address within lists.mylistserver.com from a user who is SASL-authenticated on my server, the message goes successfully. When I send to any address within lists.mylistserver.com from any user (address) outside my server (not authenticated on my server, simply sending to it), this error occurs. I think in my attempts to ensure tight security on the server, I've disallowed external senders to lists, but I can't see how exactly. Any help on the question on how I might be disallowing external senders to *...@lists.mylistserver.com would be much appreciated. Thank you.
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, Wietse Venema wrote: > > Jeff Weinberger: > > I changed main.cf so the only "relay_domains" entry is: > > > > relay_domains=lists.mylistserver.com > > You need to verify this with the command > > postconf -n > > It's no good posting unverified cut-and-paste to the mailing list. > > Wietse > So you want me to post the entire `postconf -n` again? copying and pasting the one relevant line and stating clearly that I verified it exactly that way doesn't suffice? How do you suggest I verify my cut-and-paste? I'll be happy to do so, if it will help us move beyond log discussions and to the issue at handthat said: I executed `postconf -n | grep relay_domains` and the result was: relay_domains=lists.mylistserver.com I made no other changes other than to relay_domains as suggested. I am hoping that someone can please help with the authenticated user issue and either help me determine why this happens or explain why my interpretation of this is wrong? The crux of this issue is there To recap: Authenticated (SASL) senders can send successfully, outside users can't. My interpretation is the problem lies in there. as that is the only thing that makes any difference at all. I need help figuring out what would cause that, or an explanation of why my interpretation is wrong. I would appreciate some help on this, if anyone has any ideas.
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 1:36 PM, Wietse Venema wrote: > Jeff Weinberger: >> > Jeff Weinberger: >> > > I changed main.cf so the only "relay_domains" entry is: >> > > >> > > relay_domains=lists.mylistserver.com >> > >> > You need to verify this with the command >> > >> > postconf -n >> > >> > It's no good posting unverified cut-and-paste to the mailing list. >> > >> > Wietse >> > >> >> So you want me to post the entire `postconf -n` again? copying and pasting > > I was trying to help, but posting tidbits out of their context > makes support difficult. > > Wietse > I get that - but I'm not sure what would help. I posted my entire `postconf -n` then I posted the result of `postconf -n | grep relay_domains` (as that's the only change I've been making - especially to be sure that no other change could possibly affect this). If there's something else that will help or a different way you want me to post information to help you understand it better, I'm glad to - just tell me what will help and I'll post it here. You've made it clear I'm posting the wrong thing - but I don't know what the "right" thing is
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 2:38 PM, Stan Hoeppner wrote: > Jeff Weinberger put forth on 1/28/2010 4:18 PM: > >> You've made it clear I'm posting the wrong thing - but I don't know >> what the "right" thing is > > Sorry to but in Wietse. > > Jeff, paste all of postconf -n output and obfuscate any sensitive information > in > it such as hostnames or IP addresses that you don't want made public here. > Wietse may not know what the "right" thing is until he sees all of postconf > -n. > There are interdependencies between various settings and often problems can't > be identified without seeing the big picture. > > If you read the list welcome message and posting instructions you'd see that > "postconf -n" output is a standard requirement here for receiving help. You > are > not being asked to provide anything beyond what everyone else is asked to > provide. If you want assistance, we need to see the data. It's that's > simple. > > Cooperate and everything will work out fine, you'll have a solution. > > Best regards. > > -- > Stan > Stan - I can't speak for Wietse, but thanks for butting in. I posted it in the original message, and only changed the one item on the presumption that when diagnosing an issue, making other, non-controlled changes just confuses things. That said, here's the latest, still not working, `postconf -n` complete output, If it got lost somewhere, I"m running Postfix 2.6.5 on Mac OS/X (client) 10.5.8 Again, if there is anything else I can post that will help, please let me know and I will be glad to do so. -`postconf -n` output alias_database = mysql:/etc/postfix/mysql_alias_maps.cf alias_maps = mysql:/etc/postfix/mysql_alias_maps.cf broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 default_verp_delimiters = += disable_vrfy_command = yes header_checks = pcre:/etc/postfix/header_checks.pcre html_directory = /etc/postfix/html inet_interfaces = all local_recipient_maps = luser_relay = ot...@jeffweinberger.com mail_owner = _postfix mailbox_size_limit = 0 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 0 mydestination = mysql:/etc/postfix/mysql_mydestination_maps.cf mydomain = jweinberger.homeip.net myhostname = jweinberger.homeip.net mynetworks = 127.0.0.0/8, !10.0.1.1, !10.0.1.210, 10.0.1.0/28 newaliases_path = /usr/bin/newaliases queue_directory = /private/var/spool/postfix readme_directory = /usr/share/doc/postfix recipient_delimiter = + relay_domains = lists.mylistserver.com relay_recipient_maps = relayhost = outbound.mailhop.org sample_directory = /usr/share/doc/postfix/examples sender_canonical_maps = mysql:/etc/postfix/mysql_sender_canonical_maps.cf sendmail_path = /usr/sbin/sendmail setgid_group = _postdrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = smtp_tls_CAfile = /etc/postfix/certs/demoCA/cacert.pem smtp_tls_cert_file = /etc/postfix/certs/postfix-cert.pem smtp_tls_key_file = /etc/postfix/certs/postfix-key.pem smtp_tls_loglevel = 1 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache smtp_use_tls = yes smtpd_data_restrictions = reject_unauth_pipelining smtpd_etrn_restrictions = permit_mynetworks, reject smtpd_helo_required = yes smtpd_recipient_restrictions = check_recipient_access mysql:/etc/postfix/mysql_check_recipient_access_maps.cf, permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client list.dsbl.org, reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:2501, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $mydomain smtpd_sasl_security_options = noanonymous smtpd_sender_login_maps = mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf smtpd_sender_restrictions = check_sender_access pcre:/etc/postfix/smtpd_sender_restrictions.pcre smtpd_tls_CAfile = /etc/postfix/certs/demoCA/cacert.pem smtpd_tls_cert_file = /etc/postfix/certs/postfix-cert.pem smtpd_tls_key_file = /etc/postfix/certs/postfix-key.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache smtpd_use_tls = yes tls_random_source = dev:/dev/urandom transport_maps = mysql:/etc/postfix/mysql_peraddress_transport_maps.cf, mysql:/etc/postfix/mysql_virtual_transport_maps.cf unknown_local_recipient_reject_code = 550 verp_delimiter_filter = -=+ virtual_alias_domains = mysql:/etc/postfix/mysql_virtual_alias_domains.cf virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf virtual_gid
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 3:16 PM, Noel Jones wrote: > On 1/28/2010 4:46 PM, Jeff Weinberger wrote: >> >> virtual_alias_domains = mysql:/etc/postfix/mysql_virtual_alias_domains.cf > > does lists.mylistserver.com match the above lookup? > postmap -q lists.mylistserver.com mysql:... > No. `postmap -q "lists.mylistserver.com" mysql:/etc/postfix/mysql_virtual_alias_domains.cf` returns nothing (empty). However, `postmap -q "lists.mylistserver.com" mysql:/etc/postfix/mysql_relay_domain_maps.cf returns "OK" (a constant value, as recommended). I was hopeful that you had identified something here...so I did test to be sure.
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 3:39 PM, Noel Jones wrote: > On 1/28/2010 5:36 PM, Jeff Weinberger wrote: >> >> On Thu, Jan 28, 2010 at 3:16 PM, Noel Jones >> wrote: >>> >>> On 1/28/2010 4:46 PM, Jeff Weinberger wrote: >>>> >>>> virtual_alias_domains = >>>> mysql:/etc/postfix/mysql_virtual_alias_domains.cf >>> >>> does lists.mylistserver.com match the above lookup? >>> postmap -q lists.mylistserver.com mysql:... >>> >> >> No. `postmap -q "lists.mylistserver.com" >> mysql:/etc/postfix/mysql_virtual_alias_domains.cf` returns nothing >> (empty). However, `postmap -q "lists.mylistserver.com" >> mysql:/etc/postfix/mysql_relay_domain_maps.cf returns "OK" (a constant >> value, as recommended). >> >> I was hopeful that you had identified something here...so I did test to be >> sure. > > So enable debug output on smtpd (or add a test client to debug_peer_list) > and show us the UNALTERED results of a failed transaction. > http://www.postfix.org/DEBUG_README.html#debug_peer > OK, I see what this will do - thanks for the suggestion. I'll post the complete log here (naturally, anything sensitive masked, but otherwise unaltered).
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 4:02 PM, Jeff Weinberger wrote: > On Thu, Jan 28, 2010 at 3:39 PM, Noel Jones wrote: >> On 1/28/2010 5:36 PM, Jeff Weinberger wrote: >>> >>> On Thu, Jan 28, 2010 at 3:16 PM, Noel Jones >>> wrote: >>>> >>>> On 1/28/2010 4:46 PM, Jeff Weinberger wrote: >>>>> >>>>> virtual_alias_domains = >>>>> mysql:/etc/postfix/mysql_virtual_alias_domains.cf >>>> >>>> does lists.mylistserver.com match the above lookup? >>>> postmap -q lists.mylistserver.com mysql:... >>>> >>> >>> No. `postmap -q "lists.mylistserver.com" >>> mysql:/etc/postfix/mysql_virtual_alias_domains.cf` returns nothing >>> (empty). However, `postmap -q "lists.mylistserver.com" >>> mysql:/etc/postfix/mysql_relay_domain_maps.cf returns "OK" (a constant >>> value, as recommended). >>> >>> I was hopeful that you had identified something here...so I did test to be >>> sure. >> >> So enable debug output on smtpd (or add a test client to debug_peer_list) >> and show us the UNALTERED results of a failed transaction. >> http://www.postfix.org/DEBUG_README.html#debug_peer >> > > OK, I see what this will do - thanks for the suggestion. I'll post the > complete log here (naturally, anything sensitive masked, but otherwise > unaltered). > I'm closing this request. I've found some issues with MySQL on my system (no explanation other than user error for the attempts without mysql), that have now been fixed. This has caused the postfix behavior to return to normal and expected, and all is working as I want. My apologies for bringing this to this forum (though I"m sure you'll see how I thought this was a postfix issue). Thank you to all who helped find the ways to diagnose this. This has raised other questions that I do not fully understand, but for clarity will post them separately. Thank you.
%d and %s in mysql queries?
I am using mysql (quite successfully in most cases) to do lookups for a variety of reasons in postfix. Recently, I had some issues with a domain lookup and in the testing tried varying my MySQL query between using %d and %s as the lookup key. The documentation is clear on this when the query is for an address. It may be as clear, and I may not be understanding this, but I would like to ask for help understanding the difference when the lookup is for a domain. In this case, I have in main.cf: relay_domains = mysql:/etc/postfix/mysql_relay_domains.cf and the query in /etc/postfix/mysql_relay_domains.cf is: query = SELECT 'OK' FROM domain WHERE domain='%d' AND type='relay' I chose %d because I'm looking up only the domain in this case. I noticed that this worked fine when the domain in question is of the form "domain.tld" but didn't work (meaning the result returned from postmap -q... was null) when the domain is of the form "sub.domain.tld" (even though "sub.domain.tld" is in the "domain" table with type "relay"). When I changed the query to use %s, it worked in both cases. So my questions are: 1) Is this expected behavior? 2) in the case where the lookup is for a domain, what is the operative difference between using %d and %s I am hoping to gain a better understanding of these two substitutions. Recommendations on best-practices are appreciated as well, but I'd like to understand the expected behavior. If this is documented and I missed it or didn't understand it well, please point me to the documentation page.
Re: %d and %s in mysql queries?
On Sat, Jan 30, 2010 at 4:41 PM, Wietse Venema wrote: > Jeff Weinberger: >> I am using mysql (quite successfully in most cases) to do lookups for >> a variety of reasons in postfix. >> >> Recently, I had some issues with a domain lookup and in the testing >> tried varying my MySQL query between using %d and %s as the lookup >> key. >> >> The documentation is clear on this when the query is for an address. > > The %d is defined when a key or result is an address: > > %d When the input key is an address of the form u...@domain, > > %d When a result attribute value is an address of the form > u...@domain > > Therefore, %d is not defined for non-address forms. > > Wieste > Thank you! So my use of %d in the case of relay_domains lookup was just incorrect. I understand this now - thanks.
