On 15/01/2013 14:11, Charles Bradshaw wrote:
Hi Patrick
I would do as you ask, but it's bad security to download anything from a
mailing list and just run it. Especially something as long and complex as
gen-auth, at which I can only have a quick and un-informed look.
Given that I don't know
Tom
I'm a complete beginner at this, just 67 years old, so you will please excuse
me if I comment on your response.
Obviously I didn't know what Gen-Auth is, so thanks for the heads-up.
As far as biting hands is concerned, I respectfully suggest you read what I
said before you put in your two
* Charles Bradshaw b...@bradcan.homelinux.com:
Hi Patrick
I would do as you ask, but it's bad security to download anything from a
mailing list and just run it. Especially something as long and complex as
gen-auth, at which I can only have a quick and un-informed look.
Given that I don't
Patrick
I have tested CRAM-MD5 with both pwcheck_method:saslauthd and
pwcheck_method:auxprop in /etc/sasl2/Sendmail.config
Both work so your assertion about fallback appears to be correct and the
readme is, at best, misleading! Certainly the case when using sendmail. If and
when I switch to
I am considering switching my smptd from sendmail to postfix, but I am a
little confused.
The following snip from http://www.postfix.org/SASL_README.html
/etc/sasl2/smtpd.conf:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
Do not specify any other mechanisms in mech_list than PLAIN
* Charles Bradshaw b...@bradcan.homelinux.com:
I am considering switching my smptd from sendmail to postfix, but I am a
little confused.
The following snip from http://www.postfix.org/SASL_README.html
/etc/sasl2/smtpd.conf:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
Do
On Jan 14, 2013, at 5:09 PM, Patrick Ben Koetter p...@sys4.de wrote:
Is there a rational explanation or do I just put it down to a ghost in the
machine?
I am confused too, because I had it first hand from Alexey Melnikov, who is
one of the main developers of Cyrus SASL, and he told me
On Fri, 11 Sep 2009, Sahil Tandon wrote:
The list of CIDR IP ranges to relay for is in the mynetworks variable,
so I can't do the recipient domain verification in
smtpd_recipient_restrictions because I need permit_mynetworks, so
that my networks can relay through the box! permit_mynetworks
On Fri, 11 Sep 2009, Sahil Tandon wrote:
Why don't you reject_unknown_recipient_domain BEFORE permitting your networks
(and/or SASL authenticated clients) in smtpd_recipient_restrictions?
So, how do I make mynetworks exempt from the
smtpd_recipient_restrictions, yet make mynetworks able to
On 9/11/2009 3:30 AM, Duncan B. wrote:
I tried putting permit_mynetworks at the end of the
smtpd_recipient_restrictions instead, but it still just allows all
relaying from mynetworks:
smtpd_recipient_restricions = reject_unauth_destination,
reject_non_fqdn_recipient,
On Fri, 11 Sep 2009, Noel Jones wrote:
smtpd_recipient_restricions = reject_unauth_destination,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
permit_mynetworks
Am I doing something wrong?
It seems to me that the restrictions aren't processed in the order that
you specify them
On 9/11/2009 8:40 AM, Duncan B. wrote:
or perhaps you misspelled restricions in main.cf like you did in
this message.
Always check your postconf -n output to verify that postfix see what
you expect.
Ahh this is more than possible .. Would 'postfix reload' not complain
about a syntax error? I'm
Hi,
Just a quick config question, which I'm not too sure how to achieve.
I'd like to enable recipient domain validation, which I've partly done (at
the data stage), however if you then enter another rcpt to after the
data command failed, it'll allow it through. E.g.
220
On Thu, 10 Sep 2009, Duncan B. wrote:
The list of CIDR IP ranges to relay for is in the mynetworks variable,
so I can't do the recipient domain verification in
smtpd_recipient_restrictions because I need permit_mynetworks, so
that my networks can relay through the box! permit_mynetworks
14 matches
Mail list logo
