Enabling sender-dependent authentication only for fallback relay?
Rich Wales
dependent authentication *only* when mail is being sent out via my
smtp_fallback_relay host, and *not* when I am sending mail directly
to a destination MX? I do not have any "relayhost" defined because
I am trying to send mail directly to a destination.]
This is a followup to my recent thread, "Smarthost as backup transport
if direct sending fails?"
I've currently configured my server (on a static IP address) to send
outgoing mail directly to the destination MX -- with my web hosting
service's SMTP server listed as an smtp_fallback_relay, and also an
smtp_reply_filter configured to change most 5xx-series replies to the
corresponding 4xx-series code (so most outbound rejections will be
requeued for sending to the fallback relay). By design, I don't have
any "relayhost" value in my configuration.
So far, so good, and this arrangement appears to work well -- but I've
noted a problem with one destination host (Verizon). A message for
a @verizon.net recipient was rejected by relay.verizon.net with the
following error:
535 5.7.8 Bad username or password (Authentication failed).
which, as I explained, was intercepted and recast as a temporary
error, then sent out (apparently successfully) via my fallback relay.
Presumably, relay.verizon.net decided for some reason to ask me for
authentication credentials, and it didn't like what I gave it.
The problem, I believe, is that my fallback relay requires me to use
sender-dependent authentication. So, as I understand, I can base my
authentication parameters *only* on the sender address, and the host
I'm talking to can *not* influence the choice of authentication data.
(At least, this is what I understood from a line of questioning from
last year, when I was using Postfix 2.6.5; I'm running 2.8.1 now.)
What I think I want/need to do is to turn off authentication *except*
in cases where I'm talking to my smtp_fallback_relay. Or, if there's
something else I might be accidentally doing that would have caused
a destination MX (*not* my fallback relay) to ask me to authenticate,
I want/need to stop doing that. Can I do anything of this sort?
I can also ask my web hosting provider (Bluehost) if there is any way
to configure my account to use a single password when submitting mail
(rather than a separate password for each member of my family) -- in
which case I would presumably be able to just disable sender-dependent
authentication, and configure authentication only for my web hosting
provider. But my current understanding is that Bluehost simply does
not offer this option.
I'm starting to ponder the idea of setting up a separate service in my
master.cf file -- similar to the standard "smtp" service, but with a
few parameters overridden -- and define that separate service as my
smtp_fallback_relay, and have the separate service use my *real*
fallback relay as its relay host, and enable sender-dependent
authentication in the separate service instead of in my standard
SMTP service. But I realize that would be a messy kludge, and I'd
prefer not to do it this way except as a last resort.
I'm including "postconf -n" output below.
Rich Wales
Palo Alto, CA
ri...@richw.org
=======================================================================
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
default_destination_concurrency_limit = 1
default_destination_recipient_limit = 1
inet_protocols = ipv4
lmtp_destination_recipient_limit = 1
local_destination_concurrency_limit = 1
local_destination_recipient_limit = 1
local_header_rewrite_clients = permit_sasl_authenticated
local_recipient_maps = hash:/etc/postfix/local_recipients $alias_maps
mail_owner = postfix
mailbox_transport = lmtp:[127.0.0.1]
masquerade_domains = $mydomain
maximal_queue_lifetime = 30d
message_size_limit = 50000000
message_strip_characters = \0
milter_default_action = accept
milter_protocol = 2
mydestination = pcre:/etc/postfix/lan_domains
mydomain = richw.org
myhostname = whodunit.richw.org
myorigin = $myhostname
non_smtpd_milters = unix:/var/run/dkim-filter/dkim-filter.sock
queue_directory = /var/spool/postfix
relay_destination_recipient_limit = 1
relay_domains = indigo.richw.org goldsmurf.randerzo.net sandals.richw.org
whodunit.stanford.edu
smtp_destination_concurrency_limit = 1
smtp_destination_recipient_limit = 1
smtp_fallback_relay = [www.richw.org]
smtp_reply_filter = pcre:/etc/postfix/reply_filter
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = PLAIN LOGIN
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
smtp_sasl_security_options = noanonymous
smtp_sender_dependent_authentication = yes
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_delay_open_until_valid_rcpt = no
smtpd_discard_ehlo_keywords = etrn silent-discard
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_milters = unix:/var/run/dkim-filter/dkim-filter.sock
smtpd_recipient_restrictions = check_client_access
hash:/etc/postfix/smtp_access sleep 1 reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname reject_unauth_pipelining
reject_unauth_destination reject_unlisted_recipient permit_mynetworks
permit_dnswl_client hostkarma.junkemailfilter.com=127.0.0.[1;3;5]
permit_dnswl_client swl.spamhaus.org reject_rhsbl_helo
hostkarma.junkemailfilter.com=127.0.0.2 reject_rbl_client
hostkarma.junkemailfilter.com=127.0.0.2 reject_rhsbl_client
hostkarma.junkemailfilter.com=127.0.0.2 reject_rhsbl_sender
hostkarma.junkemailfilter.com=127.0.0.2 reject_rhsbl_helo dbl.spamhaus.org
reject_rbl_client zen.spamhaus.org reject_rhsbl_client dbl.spamhaus.org
reject_rhsbl_sender dbl.spamhaus.org permit
smtpd_reject_footer = Please report any delivery problems to richwales at
gmail dot com
smtpd_tls_CAfile = /etc/postfix/whodunit.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/whodunit.pem
smtpd_tls_key_file = /etc/postfix/whodunit.pem
smtpd_tls_received_header = yes
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual_map
virtual_destination_recipient_limit = 1
=======================================================================
Rich Wales
> I'm starting to ponder the idea of setting up a separate service in
> my master.cf file -- similar to the standard "smtp" service, but with
> a few parameters overridden -- and define that separate service as
> my smtp_fallback_relay, and have the separate service use my *real*
> fallback relay as its relay host, and enable sender-dependent
> authentication in the separate service instead of in my standard
> SMTP service. But I realize that would be a messy kludge, and I'd
> prefer not to do it this way except as a last resort.
That idea doesn't appear to work -- the separate SMTP service considered
the mail passed to it by the main Postfix instance to be unauthenticated
(because it wasn't coming directly from my user agent?) and insisted it
wouldn't act as an open relay.
I tried the option smtpd_recipient_restrictions= in the separate SMTP
service, but that didn't work -- Postfix demands that this parameter must
contain at least one working instance of reject_unauth_destination, reject,
defer, or defer_if_permit -- i.e., it looks like it simply will not allow
itself to be configured as an open relay, period, even if I'm sure I know
what I'm doing.
And there doesn't seem to be any way for me to use my web hosting service
(Bluehost) as my fallback without doing sender-dependent authentication;
their tech support's suggestion that I try using my master domain account
cPanel login info as a site-wide, sender-independent authentication did
not work.
So I appear to be stuck -- I can't avoid the situation (as I described in
my e-mail from last night; see details there) where a random destination
MX is deciding to ask me for authentication, and it understandably doesn't
like my sender-dependent authentication info intended only for my fallback
relay, and I can't selectively give out or withhold my authentication info
because sender-dependent authentication cares *only* about the sender and
apparently can't be told to care about the identity of the destination host.
Any suggestions would be welcome.
Rich Wales
ri...@richw.org
Wietse Venema
There is a lot of "did not work" without concrete detail:
actual configuration, actual error responses.
See my response in a recent thread:
http://archives.neohapsis.com/archives/postfix/2011-05/0020.html
Wietse
Victor Duchovni
> [Short version of my question: Is there any way to enable sender-
> dependent authentication *only* when mail is being sent out via my
> smtp_fallback_relay host, and *not* when I am sending mail directly
> to a destination MX? I do not have any "relayhost" defined because
> I am trying to send mail directly to a destination.]
You have to use a fallback relay setting that sends the mail to a second
Postfix instance on your machine, and have that instance send all mail
to the relay, with sender-dependent authentication.
smtp_fallback_relay=[127.0.0.1]:10035
This would be a full Postfix instance, not just another master.cf entry:
http://www.postfix.org/MULTI_INSTANCE_README.html
--
Viktor.
Rich Wales
> configuration, actual error responses. See my response in a recent
With all possible respect, Wietse, I believe I already provided ample
concrete detail in my original message from last night. If you would
prefer to simply ignore my second message (in which I tried to say
that a possible workaround I had considered doesn't seem to work) and
consider only my original message (perhaps ignoring the paragraph near
the end starting with "I'm starting to ponder"), I won't object.
Rich Wales
ri...@richw.org
Rich Wales
> Postfix instance on your machine, and have that instance send all mail
> Postfix instance, not just another master.cf entry:
Thanks, Victor.
A followup question, if I may. Briefly, can you help me understand what is
going on in a situation like mine that will require the use of a second,
completely separate Postfix instance (and precludes doing what I want to do
in a separate master.cf entry)?
Rich Wales
ri...@richw.org
Victor Duchovni
The mail must be handled by a second separately configured smtp(8) delivery
agent, and therefore, must be placed in a separate queue, which requires
a separate instance.
If the message were handed off to the same queue-manager it would loop.
--
Viktor.
Victor Duchovni
> > The mail must be handled by a second separately configured smtp(8)
> > delivery agent, and therefore, must be placed in a separate queue,
> > which requires a separate instance. If the message were handed off
> > to the same queue-manager it would loop.
>
> Ah. And, not surprisingly, when I tried to solve my problem using an
> alternative smtp in my master.cf, it did precisely that -- the second
> smtp threw the message back into the queue, and my one-and-only Postfix
> dutifully pulled it out of the queue and processed it all over again
> from scratch, leading to a loop.
>
> So I assume there's no way to tag messages in a single Postfix queue
> with some sort of "already processed once -- let the secondary smtp
> agent take care of this one" marker? Instead, doing this requires a
> separate Postfix instance (with its own separate queue)?
Yes, and this is no less efficient, and in fact the configuration is
IMHO simpler, and mailq(1) output is more meaningful, ...
--
Viktor.
Rich Wales
> is IMHO simpler, and mailq(1) output is more meaningful, ...
Thanks again.
As it turned out, I was able to find a way to authenticate to my web
hosting service's outbound SMTP server using a single username/password
combo -- and thereby stop having to use sender-dependent authentication,
and thus avoid the problems which accompanied the sending of my auth
credentials to random servers, without needing to do anything complex.
For the time being, I'm happy. :-) Thanks to everyone for their help.
Rich Wales
ri...@richw.org