Re: Question about reject_unauthenticated_sender_login_mismatch (additional information)
Jeff Weinberger a écrit : [snip] 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 it would be better to move the reject_sender... part to main.cf (in 587_master_sender_restrictions). since you are already using this custom variable, go ahead and use it fully. [snip]
Re: Question about reject_unauthenticated_sender_login_mismatch (additional info
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. 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)
Re: Question about reject_unauthenticated_sender_login_mismatch (additional info
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. 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 - table 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. -- 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: 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 - table 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: Question about reject_unauthenticated_sender_login_mismatch
--- In post...@yahoogroups.com, Victor Duchovni victor.ducho...@... wrote: On Mon, Jan 12, 2009 at 09:35:14PM -0800, Jeff Weinberger wrote: 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? Yes, that's what I said. Am I then correct in concluding that with: smtpd_sender_restrictions = permit_sasl_authenticated, reject_authenticated_sender_login_mismatch, reject Observe that the order of the first two elements is not entirely correct. that the permit_sasl_autheticated obviates the need for reject_unauthenticated_sender_login_mismatch? (as there would never be an unauthenticated sender permitted...) Yes. this saves you a table lookup before unauthenticated senders are rejected outright via reject. And am I also correct in concluding that if 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, that's I said. I think I've misunderstood this again. here's the behavior I observed: I added -o smtpd_sender_restrictions=reject_unauthenticated_sender_login_mismatch to my master.cf smtp service entry (receiving mail on port 25). It then rejected all mail. Each message was rejected because the sender was not authenticated. This is obviously undesireable behavior for this service, as I will never receive any mail. The behavior I was seeking was that it would reject messages where the MAIL FROM is one of the addresses that validly authenticates. In other words if a spammer were to forge the MAIL FROM address as one of my valid users, then send the message to that same user or any other user on my server, postfix would reject it, knowing that that particular address should be sent from a matching (smtpd_sender_login_maps) authenticated user. Further, any mail received with a MAIL FROM that is not listed in my smtpd_sender_login_maps) should then be permitted to pass, at least to the next check. Given that reject_unauthenticated_sender_login_mismatch does not produce this behavior, is there another way to produce this behavior? (with the obvious corollary - is there any reason I would not want to do so?) Thank you!!
Re: Question about reject_unauthenticated_sender_login_mismatch
On Wed, Jan 14, 2009 at 11:15:54PM -, jeff_homeip wrote:
I think I've misunderstood this again. here's the behavior I observed:
I added -o
smtpd_sender_restrictions=reject_unauthenticated_sender_login_mismatch to
my master.cf smtp service entry (receiving mail on port 25).
It then rejected all mail. Each message was rejected because the sender was
not
authenticated.
You should not really expect us to help you with this with no log entries,
associated postconf -n, and actual master.cf entries.
The behavior I was seeking was that it would reject messages where
the MAIL FROM is one of the addresses that validly authenticates.
The reject_unauthenticated_sender_login_mismatch feature only rejects
addresses listed in the smtpd_sender_logim_maps table:
/*
* Reject if the client is not logged in and the sender address has an
* owner.
*/
if (smtpd_sasl_is_active(state) state-sasl_username == 0) {
reply = (const RESOLVE_REPLY *) ctable_locate(smtpd_resolve_cache,
sender);
if (reply-flags RESOLVE_FLAG_FAIL)
reject_dict_retry(state, sender);
if (check_mail_addr_find(state, sender, smtpd_sender_login_maps,
STR(reply-recipient), (char **) 0) != 0)
return (smtpd_check_reject(state, MAIL_ERROR_POLICY, 553, 5.7.1,
%s: Sender address rejected: not logged in, sender));
}
So either your report is incomplete/inaccurate, or you have managed to
list all the senders you tested in smtpd_sender_login_maps (difficult
with indexed files, easier with regexp tables and SQL lookups).
Given that reject_unauthenticated_sender_login_mismatch does not
produce this behavior, [ ... ]
With false premises you can reach any conclusion.
--
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: Question about reject_unauthenticated_sender_login_mismatch
--- In post...@yahoogroups.com, Victor Duchovni victor.ducho...@... wrote:
On Wed, Jan 14, 2009 at 11:15:54PM -, jeff_homeip wrote:
I think I've misunderstood this again. here's the behavior I observed:
I added -o
smtpd_sender_restrictions=reject_unauthenticated_sender_login_mismatch to
my master.cf smtp service entry (receiving mail on port 25).
It then rejected all mail. Each message was rejected because the sender was
not
authenticated.
You should not really expect us to help you with this with no log entries,
associated postconf -n, and actual master.cf entries.
I'm always happy to provide whatever might be helpful, and yet always conscious
of
excessively long messages. I generally don't post postconf -n in its entirety
for that and
disclosure reasons (yes, I'm paranoid). But I try to give the relevant entries
and anything
else you think will help.
The behavior I was seeking was that it would reject messages where
the MAIL FROM is one of the addresses that validly authenticates.
The reject_unauthenticated_sender_login_mismatch feature only rejects
addresses listed in the smtpd_sender_logim_maps table:
/*
* Reject if the client is not logged in and the sender address has an
* owner.
*/
if (smtpd_sasl_is_active(state) state-sasl_username == 0) {
reply = (const RESOLVE_REPLY *) ctable_locate(smtpd_resolve_cache,
sender);
if (reply-flags RESOLVE_FLAG_FAIL)
reject_dict_retry(state, sender);
if (check_mail_addr_find(state, sender, smtpd_sender_login_maps,
STR(reply-recipient), (char **) 0) != 0)
return (smtpd_check_reject(state, MAIL_ERROR_POLICY, 553, 5.7.1,
%s: Sender address rejected: not logged in, sender));
}
So either your report is incomplete/inaccurate, or you have managed to
list all the senders you tested in smtpd_sender_login_maps (difficult
with indexed files, easier with regexp tables and SQL lookups).
Given that reject_unauthenticated_sender_login_mismatch does not
produce this behavior, [ ... ]
With false premises you can reach any conclusion.
I am quite certain that my premises are not false. I tested it with senders who
I know for a
fact ARE listed in the smtpd_sender_login_maps both as authenticated (they were
accepted) and from another client that did not authenticate (they were properly
rejected).
Then I waited for someone else to send mail to one of my users. Here is the log
entry that
was produced:
Jan 14 15:03:37 s postfix/smtpd[44746]: NOQUEUE: reject: RCPT from
mail37.messagelabs.com[216.82.241.83]: 553 5.7.1 katie.prev...@morris.com:
Sender
address rejected: not logged in; from=katie.prev...@morris.com
to=myu...@userdomain.tld proto=SMTP helo=mail37.messagelabs.com
only altered to avoid posting one of my users' e-mail addresses and otherwise
as logged.
The address logged as from=... is not in my smtpd_sender_login_maps (I
looked again
to be sure) and is not a user or sender on my server at all.
The master.cf entry is:
smtp inet n - n - - smtpd
-o smtpd_sender_restrictions=reject_unauthenticated_sender_login_mismatch
that is the only line I used.
I would expect the above-mentioned mail to be permitted, and in other cases I
have had
no problems.
Immediately after seeing this in the logs, I removed the -o
smtpd_sender_restrictions=reject_unauthenticated_sender_login_mismatch from my
master.cf entry, and since then no mail has been rejected with a reason of not
logged in.
I don't know how else to interpret this behavior, other than to conclude that
adding that
line to my master.cf caused the mail to be rejected, which is not what I
expected.
Knowing that I cannot determine, apparently, what will be helpful in diagnosing
this
behavior or suggesting ways I can achieve the desired behavior, I am posting
below my
complete postconf -n (some addresses and sensitive items edited out as noted,
but
otherwise unaltered).
I am hoping that you or someone will either identify what I've done wrong or
help me find
a way to achieve the desired behavior.
If there is any additional information I have not provided here that would be
helpful in
doing one of these two, please ask - I will provide as much as I am able.
Thank you for your help.
--Jeff
postconf -n:
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
debug_peer_level = 2
default_verp_delimiters = +=
disable_vrfy_command = yes
html_directory = /etc/postfix/html
inet_interfaces = all
local_recipient_maps =
luser_relay = address hidden
mail_owner = postfix user
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 0
mydestination =
Re: Question about reject_unauthenticated_sender_login_mismatch
On Thu, Jan 15, 2009 at 12:21:51AM -, jeff_homeip wrote: I am quite certain that my premises are not false. I tested it with senders who I know for a fact ARE listed in the smtpd_sender_login_maps both as authenticated (they were accepted) and from another client that did not authenticate (they were properly rejected). Then I waited for someone else to send mail to one of my users. Here is the log entry that was produced: Jan 14 15:03:37 s postfix/smtpd[44746]: NOQUEUE: reject: RCPT from mail37.messagelabs.com[216.82.241.83]: 553 5.7.1 katie.prev...@morris.com: Sender address rejected: not logged in; from=katie.prev...@morris.com to=myu...@userdomain.tld proto=SMTP helo=mail37.messagelabs.com The map lookup matched on katie.prev...@morris.com. If you're using SQL for this table, you need to re-examine your query. Test queries with something like: postmap -q katie.prev...@morris.com mysql:/path/to/xxx.cf Note there is a difference between not found and an empty response. -- Noel Jones
Re: Question about reject_unauthenticated_sender_login_mismatch
On Wed, Jan 14, 2009 at 08:54:52PM -0600, Noel Jones wrote: Jan 14 15:03:37 s postfix/smtpd[44746]: NOQUEUE: reject: RCPT from mail37.messagelabs.com[216.82.241.83]: 553 5.7.1 katie.prev...@morris.com: Sender address rejected: not logged in; from=katie.prev...@morris.com to=myu...@userdomain.tld proto=SMTP helo=mail37.messagelabs.com The map lookup matched on katie.prev...@morris.com. If you're using SQL for this table, you need to re-examine your query. Test queries with something like: postmap -q katie.prev...@morris.com mysql:/path/to/xxx.cf Spot on! Note there is a difference between not found and an empty response. In most cases Postfix suppresses empty results (and records a warning int the logs). On Thu, Jan 15, 2009 at 12:21:51AM -, jeff_homeip wrote: So either your report is incomplete/inaccurate, or you have managed to list all the senders you tested in smtpd_sender_login_maps (difficult with indexed files, easier with regexp tables and SQL lookups). Jan 14 15:03:37 s postfix/smtpd[44746]: NOQUEUE: reject: RCPT from mail37.messagelabs.com[216.82.241.83]: 553 5.7.1 katie.prev...@morris.com: Sender address rejected: not logged in; from=katie.prev...@morris.com to=myu...@userdomain.tld proto=SMTP helo=mail37.messagelabs.com I don't know how else to interpret this behavior, other than to conclude that adding that line to my master.cf caused the mail to be rejected, which is not what I expected. I suggested two possibilities (and even hinted at SQL query issues as a possible cause), you seem to have overlooked the second. smtpd_sender_login_maps = mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf There's the problem. Now test the table as Noel suggested. $ echo katie.prev...@morris.com | postmap -q - mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf -- 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: Question about reject_unauthenticated_sender_login_mismatch
--- In post...@yahoogroups.com, Victor Duchovni victor.ducho...@... wrote: On Wed, Jan 14, 2009 at 08:54:52PM -0600, Noel Jones wrote: Jan 14 15:03:37 s postfix/smtpd[44746]: NOQUEUE: reject: RCPT from mail37.messagelabs.com[216.82.241.83]: 553 5.7.1 katie.prev...@...: Sender address rejected: not logged in; from=katie.prev...@... to=myu...@... proto=SMTP helo=mail37.messagelabs.com The map lookup matched on katie.prev...@... If you're using SQL for this table, you need to re-examine your query. Test queries with something like: postmap -q katie.prev...@... mysql:/path/to/xxx.cf Spot on! Note there is a difference between not found and an empty response. In most cases Postfix suppresses empty results (and records a warning int the logs). On Thu, Jan 15, 2009 at 12:21:51AM -, jeff_homeip wrote: So either your report is incomplete/inaccurate, or you have managed to list all the senders you tested in smtpd_sender_login_maps (difficult with indexed files, easier with regexp tables and SQL lookups). Jan 14 15:03:37 s postfix/smtpd[44746]: NOQUEUE: reject: RCPT from mail37.messagelabs.com[216.82.241.83]: 553 5.7.1 katie.prev...@...: Sender address rejected: not logged in; from=katie.prev...@... to=myu...@... proto=SMTP helo=mail37.messagelabs.com I don't know how else to interpret this behavior, other than to conclude that adding that line to my master.cf caused the mail to be rejected, which is not what I expected. I suggested two possibilities (and even hinted at SQL query issues as a possible cause), you seem to have overlooked the second. smtpd_sender_login_maps = mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf There's the problem. Now test the table as Noel suggested. $ echo katie.prev...@... | postmap -q - mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf -- 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...@...?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. Noel, Viktor: I see why you think that - but I did test with postmap -q quite extensively before I added this, sorry I didn't mention it here. I just tested again with this result: % /etc/postfix : postmap -q katie.prev...@morris.com mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf % /etc/postfix : postmap returned an empty result, which I thought was correct. Should it be returning something different? If so, what should the result for an address not listed on my server be? I appreciate your help and your work to narrow down and isolate the issue here. Thanks! --Jeff
Re: Question about reject_unauthenticated_sender_login_mismatch
--- In post...@yahoogroups.com, Victor Duchovni victor.ducho...@... wrote: On Thu, Jan 15, 2009 at 05:17:07AM -, jeff_homeip wrote: There's the problem. Now test the table as Noel suggested. $ echo katie.prevost@ | postmap -q - mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf I just tested again with this result: % /etc/postfix : postmap -q katie.prev...@... mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf % /etc/postfix : Please use the suggested: echo lookup-key | postmap -q - table form. Also as documented, smtpd_sender_login_maps uses additional lookup keys: http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps 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_interfaces or $proxy_interfaces. 3) @domain This table lookup is done last and has the lowest precedence. 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. You need to tset the full set of lookup keys (sh, ksh or bash, not csh): ( echo morris.com | postmap -q - mysql:/etc/postfix/mysql_mydestination_maps.cf 2 echo katie.prevost sleep 1 echo katie.prev...@... echo @morris.com ) | postmap -q - mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf All this assumes that the sender address in question is unmodified... % /etc/postfix : ( echo morris.com | postmap -q - mysql:/etc/postfix/mysql_mydestination_maps.cf 2 echo katie.prevost sleep 1 echo katie.prev...@... echo @morris.com ) | postmap -q - mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf % /etc/postfix : again, an empty result set. I'm not sure of all the possible meanings of All this assumes that the sender address in question is unmodified... but I know I've left the sender address untouched and I don't think I have anything that rewrites the sender address, so as far as I know it's unmodified. I appreciate you continuing to seek possible causes. I am having another issue which is not exactly this, but is related to this thread, and i suspect there may be some relation (I think it's the same thing - getting my restriction slightly wrong): Per your and Wietse's suggestions, I changed: -o smtpd_sender_restrictions= permit_sasl_authenticated,reject_sender_login_mismatch,reject in my submission service to: -o smtpd_sender_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,rejec t so that the permit_sasl_authenticated didn't obviate the reject_sender_login_mismatch. Now I am unable to send mail when authenticated as me with a valid address from a client outside of my_networks. My master.cf submission entry is: 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=reject_sender_login_mismatch,permit_sasl_authenticated,rejec t -o milter_macro_daemon_name=ORIGINATING in its unaltered entirety. my postconf -n remains as in the message in this thread of several hours ago. The log entry is: Jan 14 22:10:06 s postfix/smtpd[1557]: NOQUEUE: reject: RCPT from unknown[32.155.5.72]: 554 5.7.1 jweinber...@mac.com: Relay access denied; from=j...@jweinberger.homeip.net to=jweinber...@mac.com proto=ESMTP helo=[10.97.215.245] I am using my mobile phone to test this, but I verified that it is submitting on port 587. jweinber...@mac.com is another address that is also mine. It is listed as a valid from address sasl authenticated user in my smtpd_sender_login_maps (so I can send messages from that when I don't have immediate access to my regular mail client and Im logged in as j...@jweinberger.homeip.net. If I send to another unrelated address, it works fine, so this is clearly caused by the fact that the address to which I'm sending is also listed in smtpd_sender_login_maps. I didn't expect this behavior, but I'm guessing it's what postfix is supposed to do. Can you explain why this happens? and do you have any suggestions to avoid it? Thank you again.
Re: Question about reject_unauthenticated_sender_login_mismatch
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 jeff_homeip wrote: If I send to another unrelated address, it works fine, so this is clearly caused by the fact that the address to which I'm sending is also listed in smtpd_sender_login_maps. I'm not following the thread too deeply, but ... This points more and more to a map problem. I didn't expect this behavior, but I'm guessing it's what postfix is supposed to do. Can you explain why this happens? and do you have any suggestions to avoid it? Have you already shown your map SQL query? If not, doing so might help. - -- Victoriano Giralt Systems Manager Central Computing Facility University of Malaga SPAIN -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJbt6xV6+mDjj1PTgRAzOWAJ0XjHCQbCh6g/8fa4k+O6hWEzHP1ACdGrDF hhRV6Dvixd7L1P05eeifyyk= =hqgE -END PGP SIGNATURE-
Re: Question about reject_unauthenticated_sender_login_mismatch (additional info
--- In post...@yahoogroups.com, Victor Duchovni victor.ducho...@... wrote:
On Thu, Jan 15, 2009 at 05:17:07AM -, jeff_homeip wrote:
There's the problem. Now test the table as Noel suggested.
$ echo katie.prevost@ |
postmap -q - mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf
I just tested again with this result:
% /etc/postfix : postmap -q katie.prev...@...
mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf
% /etc/postfix :
Please use the suggested:
echo lookup-key | postmap -q - table
form. Also as documented, smtpd_sender_login_maps uses additional
lookup keys:
http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps
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_interfaces
or $proxy_interfaces.
3) @domain
This table lookup is done last and has the lowest precedence.
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.
You need to tset the full set of lookup keys (sh, ksh or bash, not csh):
(
echo morris.com |
postmap -q - mysql:/etc/postfix/mysql_mydestination_maps.cf 2
echo katie.prevost
sleep 1
echo katie.prev...@...
echo @morris.com
) | postmap -q - mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf
All this assumes that the sender address in question is unmodified...
--
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...@...?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.
Here's some additional information on the issue of not being able to send from
outside
my_networks from one authorized address to another:
I restored my master.cf from my latest backup and before I started testing the
reject_(un)authorixed, I had one additional smtpd_sender_restrictions
listed:
-o
smtpd_sender_restrictions=$submission_sender_restrictions,reject_sender_login_mismatc
h,permit_sasl_authenticated,reject
in my submission service. it's defined in main.cf as:
submission_sender_restrictions =check_sender_access
pcre:/etc/postfix/smtpd_sender_restrictions.pcre
smtpd_sender_restrictions.pcre is:
/^(.*)/ PREPEND X-Envelope-Sender: ${1}
just the one line where I hope I can capture the envelope sender (this is
related to an
earlier issue where my spam filter failed to preserve the envelope sender, so
this is a
workaround).
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?
I thought this information might be useful or important.
Thanks again!
Re: Question about reject_unauthenticated_sender_login_mismatch
jeff_homeip a écrit : --- In post...@yahoogroups.com, Victor Duchovni victor.ducho...@... wrote: [snip] Am I then correct in concluding that with: smtpd_sender_restrictions = permit_sasl_authenticated, reject_authenticated_sender_login_mismatch, reject Observe that the order of the first two elements is not entirely correct. I hope you didn't miss this. in your restrictions, reject_authenticated_* is useless, because authenticated transactions have been permitted by permit_sasl_authenticated. or did you mean reject_UNauthenticated_*? thank you for confirming, and allowing my still-growing knowledge of postfix to confirm your answers. this will help quite a lot! to sum up: - if f...@example.com can only be used by user 'foo', then use reject_sender_login_mismatch. - if f...@example.com must be authenticated (but you don't care who the user is), then use reject_unauthenticated_* - if f...@example.com can be used (without auth) OR (if auth'ed, the user must be 'foo'), then use reject_authenticated_*. advanced (skip if not confident...) you can implement this on a per sender basis using a check_sender_access with a map that returns one of the above depending on the sender. for example: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access_sender_login == access_sender_login: j...@example.comreject_sender_login_mismatch j...@example.comreject_authenticated_sender_login_mismatch j...@example.comreject_unauthenticated_sender_login_mismatch f...@example.comDUNNO example.com reject_sender_login_mismatch /advanced
Re: Question about reject_unauthenticated_sender_login_mismatch
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 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. 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. (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. 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. -- 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: 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.
Re: Question about reject_unauthenticated_sender_login_mismatch
On Mon, Jan 12, 2009 at 09:35:14PM -0800, Jeff Weinberger wrote: 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? Yes, that's what I said. Am I then correct in concluding that with: smtpd_sender_restrictions = permit_sasl_authenticated, reject_authenticated_sender_login_mismatch, reject Observe that the order of the first two elements is not entirely correct. that the permit_sasl_autheticated obviates the need for reject_unauthenticated_sender_login_mismatch? (as there would never be an unauthenticated sender permitted...) Yes. this saves you a table lookup before unauthenticated senders are rejected outright via reject. And am I also correct in concluding that if 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, that's I said. -- 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: Question about reject_unauthenticated_sender_login_mismatch
--- In post...@yahoogroups.com, Victor Duchovni victor.ducho...@... wrote: On Mon, Jan 12, 2009 at 09:35:14PM -0800, Jeff Weinberger wrote: 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? Yes, that's what I said. Am I then correct in concluding that with: smtpd_sender_restrictions = permit_sasl_authenticated, reject_authenticated_sender_login_mismatch, reject Observe that the order of the first two elements is not entirely correct. that the permit_sasl_autheticated obviates the need for reject_unauthenticated_sender_login_mismatch? (as there would never be an unauthenticated sender permitted...) Yes. this saves you a table lookup before unauthenticated senders are rejected outright via reject. And am I also correct in concluding that if 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, that's I said. thank you for confirming, and allowing my still-growing knowledge of postfix to confirm your answers. this will help quite a lot! -- 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...@...?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.
