Postscreen DNSBL Sites

[Vincent Lefevre-10]

On 2013-05-07 15:50:33 +0200, Robert Schetterer wrote:
> Am 07.05.2013 14:14, schrieb Vincent Lefevre:
> > A whitelist is not possible as in general, I don't know who
> > sends me such mail
>
> it is possible
> what about reading logs and/or mail headers ?

I meant that it may be a completely new user, who has never sent me
mail before. So, there can't be any trace in the logs to be able to
whitelist the IP before I get the first mail... Or I need a time
machine. :)

--
Vincent Lefèvre <[hidden email]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Vincent Lefevre-10]

On 2013-05-07 17:36:49 -0500, /dev/rob0 wrote:
> I'm going to take this chance to pipe into this thread that I am
> confused about Vincent's issue. He says that the client which lacked
> PTR (the one run by a Debianista) was not a mail exchanger, or not
> exchanging mail.
>
> Why, then, would reject_unknown_reverse_client_hostname be an issue?
> Obviously one must never apply this against one's own submitting
> users. Or was Vincent confused about the distinction between mail
> exchanging clients and submission clients?

I'm not sure about your terminology. When I hear "mail exchanger",
I think about "MX" and a machine pointed to by a MX record. At
least this is what I get when searching for "mail exchanger" on
Google.

Here, I meant that the machine isn't related to a MX record. The
two Received line about the sender are:

Received: from carotte.tilapin.org (unknown [95.138.72.61])
        by ioooi.vinc17.net (Postfix) with ESMTPS id EFA4959
        for <[hidden email]>; Tue,  2 Oct 2012 03:15:23 +0200 (CEST)
Received: from [192.168.1.60] (ident=taffit)
        by carotte.tilapin.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
        (Exim 4.72)
        [...]

It (carotte.tilapin.org) seems to be a machine on a private network
hosting a MSA.

Also, carotte.tilapin.org resolves to a different IP, but perhaps
the IP has changed since Oct 2012. In both cases, the IP addresses
don't have a PTR. But the user can't do much except by asking his
ISP to add one. If the ISP is like the big ones in France, they
will ignore such requests if they don't some from a majority of
customers. :(

> On Tue, May 07, 2013 at 03:12:58PM -0500, Stan Hoeppner wrote:
> > On 5/6/2013 6:54 PM, /dev/rob0 wrote:
> > > FCrDNS itself is not just a best practice, it is a
> > > requirement.
> >
> > It is preferred, but optional, not required.  If it was a
>
> I was speaking in a functional sense. In the real world, you either
> have FCrDNS for your outbound, or you have massive deliverability
> issues.

Perhaps for IPv4 (but this depends: some people send mail to a few
restricted people). If only the IPv6 address lacks a PTR, this is
probably not true, at least in France, where the biggest ISP's don't
support IPv6, so that there are no deliverability issues with them.
Only with the few people who have a MX with IPv6 support.

--
Vincent Lefèvre <[hidden email]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Vincent Lefevre-10]

On 2013-05-07 14:19:40 +0200, Reindl Harald wrote:
> Am 07.05.2013 14:02, schrieb Vincent Lefevre:
> > depending on the recipient or other factors. And it seems that
> > some users forget to set up a PTR for all their IPv6 addresses.
> > This apparently includes Debian's mailing-list server.
>
> that's their problem

Not just the sender's problem, but also the recipients'.

> > I agree, but I repeat that I cannot change the config of other
> > users. From what I can see in my mail archive, it is *not* safe
> > to blindly reject mail from IPs without a valid PTR. At least
> > currently
>
> and because this attitude they are not enforced to fix their
> setups - if any MTA would reject the mails the problem would
> not exist since years because even the dumbest admin would
> realize it if any outgoing message fails

My server is just for me and partly for a few members of my family.
My attitude won't change anything in practice.

--
Vincent Lefèvre <[hidden email]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Vincent Lefevre-10]

On 2013-05-07 23:00:01 +0200, Jan P. Kessler wrote:

> Yes this is possible with postfwd. The policy delegation protocol
> contains reverse_client_name and client_name, which can be used within
> postfwd rulesets.
>
> Example:
>
> id=COMBO01
>     reverse_client_name==unknown
>     rbl=bl.spamcop.net,pbl.spamhaus.org
>     action=REJECT due to no valid rDNS and blacklisting

Thanks for the information. I hesitated between postscreen and
postfwd, and chose postscreen to see if this were sufficient. Now
I have postfwd in my TODO list. I suppose that it's better to use
it in addition to postscreen, as the results from the RBLs should
be cached.

BTW, if I understand correctly what has been said earlier, DEFER would
be better than REJECT as the reverse_client_name==unknown error may be
temporary.

--
Vincent Lefèvre <[hidden email]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Vincent Lefevre-10]

On 2013-05-07 14:33:12 +0200, Patrick Lists wrote:

> On 05/07/2013 02:02 PM, Vincent Lefevre wrote:
> [snip]
> >A PTR is not associated with a host, but with an IP address. That's
> >important because mail may be sent from different IP addresses,
> >depending on the recipient or other factors. And it seems that
> >some users forget to set up a PTR for all their IPv6 addresses.
> >This apparently includes Debian's mailing-list server.
>
> It does not matter who sends the email. The sending MTA host should have a
> proper PTR (yes for the IP address). Forgetting to set a PTR is not an
> excuse. Would you accept it if a gas station forgot to label their fuel
> properly causing possible damage to your car's engine?

While I agree that a PTR should be set, this is different. A MTA
sending legitimate mail (not spam) but without a PTR doesn't cause
any damage.

> If Debian's mailing-list server does not have a PTR set then they
> should fix that. You can probably file a bug somewhere or poke some
> Debian infra person on irc. And if they are not totally clueless
> then their mail admin should see a bunch of bounces in their logs
> due to the absence of a PTR which hopefully rings a bell.

I've reported a Debian bug, and it's apparently "fixed".
See my reply to Stan Hoeppner about this.

> >I agree, but I repeat that I cannot change the config of other
> >users. From what I can see in my mail archive, it is *not* safe
> >to blindly reject mail from IPs without a valid PTR. At least
> >currently.
>
> So you basically accept that a mail admin of another system is
> clueless or lazy? Please don't let them get away with that, even if
> it could be legitimate email.

There are too many clueless/lazy admins. I would like to warn
them, but without rejecting the mail, at least before I know
more about it in *my* context. It's quite annoying to have bug
fixes delayed for months or years just because of lost mail.

If I added reject_unknown_reverse_client_hostname, someone sending
a mail to [hidden email], [hidden email], [hidden email] could
have his mail accepted by free.fr and wanadoo.fr (two big French
ISP's) because his IPv4 address has a valid PTR but rejected by my
server because his IPv6 address doesn't have a valid PTR.

--
Vincent Lefèvre <[hidden email]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Reindl Harald-2]

Am 08.05.2013 01:41, schrieb Vincent Lefevre:

> On 2013-05-07 17:36:49 -0500, /dev/rob0 wrote:
>> I'm going to take this chance to pipe into this thread that I am
>> confused about Vincent's issue. He says that the client which lacked
>> PTR (the one run by a Debianista) was not a mail exchanger, or not
>> exchanging mail.
>>
>> Why, then, would reject_unknown_reverse_client_hostname be an issue?
>> Obviously one must never apply this against one's own submitting
>> users. Or was Vincent confused about the distinction between mail
>> exchanging clients and submission clients?
>
> I'm not sure about your terminology. When I hear "mail exchanger",
> I think about "MX" and a machine pointed to by a MX record. At
> least this is what I get when searching for "mail exchanger" on
> Google

yes MX in case of sending MTA is irrelevant

but as explained you need a PTR on a MTA which wants to
deliver mail to another server or you have to expect
that you mail is rejetced

it is perfectly safe to call anybody who wants deliver
mails to you without having a valid PTR on his machine
a foll and rehect his message and if he complains simply
recommend him to let the job do someone else with more
qualification

period

[Reindl Harald-2]

Am 08.05.2013 01:47, schrieb Vincent Lefevre:
> On 2013-05-07 14:19:40 +0200, Reindl Harald wrote:
>> Am 07.05.2013 14:02, schrieb Vincent Lefevre:
>>> depending on the recipient or other factors. And it seems that
>>> some users forget to set up a PTR for all their IPv6 addresses.
>>> This apparently includes Debian's mailing-list server.
>>
>> that's their problem
>
> Not just the sender's problem, but also the recipients

no - if someone lacks basics how to fullfil requirements
for a MTA it is his problem and i am not a recipients

>> and because this attitude they are not enforced to fix their
>> setups - if any MTA would reject the mails the problem would
>> not exist since years because even the dumbest admin would
>> realize it if any outgoing message fails
>
> My server is just for me and partly for a few members of my family.
> My attitude won't change anything in practice

and because everybody seeks a different excuse to not enforce
mail policies we have since decades the same discussions

[Reindl Harald-2]

Am 08.05.2013 01:58, schrieb Vincent Lefevre:
> BTW, if I understand correctly what has been said earlier, DEFER would
> be better than REJECT as the reverse_client_name==unknown error may be
> temporary

RTFM

http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname
The reply is always 450 in case the address->name lookup failed due to a temporary problem

[Reindl Harald-2]

Am 08.05.2013 02:09, schrieb Vincent Lefevre:
> While I agree that a PTR should be set, this is different. A MTA
> sending legitimate mail (not spam) but without a PTR doesn't cause
> any damage

and because machines does not guess and smell if it is legitimate
there are rules which are enforced and anybody these days who
thinks he needs to maintain his own MTA has to read manuals
and best practices before plug the machine to the internet

[Peter Ajamian]

On 05/08/2013 11:41 AM, Vincent Lefevre wrote:
> Perhaps for IPv4 (but this depends: some people send mail to a few
> restricted people). If only the IPv6 address lacks a PTR, this is
> probably not true, at least in France, where the biggest ISP's don't
> support IPv6, so that there are no deliverability issues with them.
> Only with the few people who have a MX with IPv6 support.

Nope, I can tell your from experience that Comcast will reject your mail
if you relay it from an IPv6 address that doesn't have a PTR.


Peter

[Peter Ajamian]

On 05/08/2013 11:02 AM, Vincent Lefevre wrote:
> I suspect that they temporarily changed the Ethernet card without
> updating their DNS config, as only the last 6 bytes of the IPv6
> address changed for this particular mail.

There are lots of ways that IPv6 can get messed up, and people tend not
to notice when it happens because relatively few people use IPv6 yet.  I
can tell you from experience that it's very easy to misconfigure an IPv6
box and end up sending mail out on an IP other than the one intended.  I
had issues myself recently with my VMs picking up autoconfigured IPv6
addresses and using those instead of the ones that I manually
configured.  Also it becomes more of an issue with IPv6 because you tend
to only configure PTR records for those IPs you actually intend to use
(can you imagine how big of a file you'd have if you configured a PTR
for every IP in a /64 block?).

Anyways, you should expect to have problems with IPv6 from time to time
if you're using it now.  You can either accept that these sorts of
issues will crop up and do the best you can to resolve them and help
others resolve them when they do, or disable IPv6 on your production
machines and stick with IPv4 until IPv6 adoption has reached a level
where it's more stable.


Peter

[Robert Schetterer-2]

Am 08.05.2013 01:07, schrieb Vincent Lefevre:

> On 2013-05-07 15:50:33 +0200, Robert Schetterer wrote:
>> Am 07.05.2013 14:14, schrieb Vincent Lefevre:
>>> A whitelist is not possible as in general, I don't know who
>>> sends me such mail
>>
>> it is possible
>> what about reading logs and/or mail headers ?
>
> I meant that it may be a completely new user, who has never sent me
> mail before. So, there can't be any trace in the logs to be able to
> whitelist the IP before I get the first mail... Or I need a time
> machine. :)
>

Ok, i understand, but however that user will get a bounce which ist not
something evil, you should always have an alternative call channel open
for support things, i.e a website with i.e some mail script and faqs if
problems with your mailserver apear, you should learn problems are
normal , its your job to fix them as postmaster

at last ,qualified support to your problem was given, i see no need for
longing this thread

you should learned for real
reject_unknown_reverse_client_hostname is most safe to use, and its
massive practise by big mail players, anyone who didnt care will end in
massive bounces as reciept ,in rare urgent cases "you" may whitelist ips
at your servers.

However nobody presses you to use this parameter, for more clever use
you may combine it with restriction classes selective only for dyn ips etc

if you dont like what you allready read , only barking at moon might be
a solution *g

Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, [phone]
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

[Stan Hoeppner]

On 5/7/2013 5:36 PM, /dev/rob0 wrote:
...
> Peter has explained this: you indeed seem to have FCrDNS, just not

Maybe my understanding of the definition of Forward Confirmed reverse
DNS is incorrect.  I thought the definition of FCrDNS is that that the
forward and reverse names not only exist but also match.  Apparently
they both must simply exist.

> "good" FCrDNS with a custom PTR. You have generic-looking FCrDNS of
> the kind that your famous PCRE file is designed to block. :)

A little ironic maybe?  Or, does this simply put me in a position to
understand the intricacies of generic rDNS?  I'd say a little of both.

>> You yourself accept mail from my outbound, so obviously you're
>> not strictly enforcing FCrDNS.
>
> I do use reject_unknown_reverse_client_hostname for most recipient
> domains. I do not use reject_unknown_client_hostname much. Neither do
> I use reject_unknown_helo_hostname; and no policy daemon whereby the
> HELO and PTR are required to match. If you're not on Zen (PBL) you're
> fine by me. :)
>
>> That or you've manually whitelisted my IP.
>
> Perish the thought! I would do no such thing! ;)

Heheh.

--
Stan

[markjt]

On 8 May 2013 at 3:03, Stan Hoeppner wrote:

> On 5/7/2013 5:36 PM, /dev/rob0 wrote:
> ...
> > Peter has explained this: you indeed seem to have FCrDNS, just not
>
> Maybe my understanding of the definition of Forward Confirmed reverse
> DNS is incorrect.  I thought the definition of FCrDNS is that that the
> forward and reverse names not only exist but also match.  Apparently
> they both must simply exist.

Your initial understanding is correct.

FCrDNS is commonly associated with reverse and forward lookup results
that are "in agreement", as described in RFC 5451 for the "iprev" message
header field (see section 2.4.3. "iprev" Results). At least one of the returned
names from the reverse lookup must resolve back to the IP:

1.2.3.4 -> host.example.com [ host2.example.com, host.other.co.uk... ]
host.example.com [ || host2.example.com || host.other.co.uk... ]  -> 1.2.3.4
= pass.

However, RFC 5451 can be paraphrased thus:
"iprev" is a nice idea in theory, but not recommended as a practical global
authentication method.

For public facing MXs that expect to receive emails from almost anywhere:
Regional and corporate variations in rDNS implementation currently render
FCrDNS impractical as a primary client rejection method.

Mark

[Peter Ajamian]

On 05/08/2013 08:03 PM, Stan Hoeppner wrote:
> On 5/7/2013 5:36 PM, /dev/rob0 wrote:
> ...
>> Peter has explained this: you indeed seem to have FCrDNS, just not
>
> Maybe my understanding of the definition of Forward Confirmed reverse
> DNS is incorrect.  I thought the definition of FCrDNS is that that the
> forward and reverse names not only exist but also match.  Apparently
> they both must simply exist.

No, they have to match, I'll go into detail so that hopefully you
understand...

Your host claims to be greer.hardwarefreak.com and connects from the IP
65.41.216.221, so first we do a lookup on your hostname:

> greer.hardwarefreak.com. 3448    IN    A    65.41.216.221

...it matches the IP of your connection ... This is good.

Next we do a reverse lookup on the IP:

> 221.216.41.65.in-addr.arpa. 86176 IN    PTR    mo-65-41-216-221.sta.embarqhsd.net.

This doesn't return your initial hostname, but that's ok because that is
not specifically required for FCRDNS.  What is required at this stage is
that the PTR lookup return a valid FQDN and it does indeed.

Note that the FQDN that is returned "looks" like a generic ISP-assigned
hostname (because of the IP address in the name).  This isn't a good
thing and there are some mail hosts that will reject based on this, but
very few in my experience.  That generic-looking hostname does not mean
that it won't pass FCRDNS, though.

Ok, next we do a lookup on the hostname we got back from the previous step:

> mo-65-41-216-221.sta.embarqhsd.net. 86166 IN A    65.41.216.221

...this returns your IP address as well, and that is good because this
is required for FCRDNS.


Peter

[Jan P. Kessler-2]

Am 08.05.2013 01:58, schrieb Vincent Lefevre:

> On 2013-05-07 23:00:01 +0200, Jan P. Kessler wrote:
>> Yes this is possible with postfwd. The policy delegation protocol
>> contains reverse_client_name and client_name, which can be used within
>> postfwd rulesets.
>>
>> Example:
>>
>> id=COMBO01
>>     reverse_client_name==unknown
>>     rbl=bl.spamcop.net,pbl.spamhaus.org
>>     action=REJECT due to no valid rDNS and blacklisting
> BTW, if I understand correctly what has been said earlier, DEFER would
> be better than REJECT as the reverse_client_name==unknown error may be
> temporary.

It is also possible to combine both, like

id=COMBO01
    rbl=bl.spamcop.net,pbl.spamhaus.org
    action=reject_unknown_reverse_client_hostname

As mentioned by someone else reject_unknown_reverse_client_hostname will
use 450 in case of dns errors and 550 on NXDOMAIN.

As I don't want to pollute the postfix list further. You are welcome to
ask postfwd related questions on it's mailinglist or the other contact
information mentioned on the website.

[Steve Jenkins-3]

On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 <[hidden email]> wrote:

>
> Here are my current entries:
>
> smtpd_recipient_restrictions =
>         permit_mynetworks,
>         permit_sasl_authenticated,

I don't put these permit_* in global restrictions; I only apply them
to submission via -o smtpd_relay_restrictions=... in master.cf. And
that brings up another point: if you're using 2.10 you now have
smtpd_relay_restrictions for relay control.

First, thanks for the extremely insightful help, Rob.

OK - I commented those two lines out of smtpd_recipient_restrictions as recommended, and added a new smtpd_relay_restrictions -o line to submission in master.cf. My submission now reads:

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

  -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination

However, I get this when sending a message from my home desktop (connected via Comcast) via my personal Postfix server to my Gmail test address:

May 13 16:05:48 carbonfiber postfix/smtpd[25210]: NOQUEUE: reject_warning: RCPT from c-xx-xxx-xx-xx.hsd1.wa.comcast.net[xx.xxx.xx.xx]: 504 5.5.2 <STEVEJPC>: Helo command rejected: need fully-qualified hostname; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<STEVEJPC>

May 13 16:05:48 carbonfiber postfix/smtpd[25210]: NOQUEUE: reject_warning: RCPT fromc-xx-xxx-xx-xx.hsd1.wa.comcast.net[[xx.xxx.xx.xx]: 450 4.7.1 <STEVEJPC>: Helo command rejected: Host not found; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<STEVEJPC>

May 13 16:05:48 carbonfiber postfix/smtpd[25210]: NOQUEUE: reject: RCPT fromc-xx-xxx-xx-xx.hsd1.wa.comcast.net[[xx.xxx.xx.xx]: 554 5.7.1 <c-xx-xxx-xx-xx5.hsd1.wa.comcast.net[xx.xxx.xx.xx]>: Unverified Client host rejected: Generic - Please relay via ISP (comcast.net); from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<STEVEJPC>

That last line is a result of using from Stan's excellent PCRE file (using check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre).

Uncommenting the two permit_* lines in smtpd_recipient_restrictions allows the message to send without error. I'm running 2.10.0 so smtpd_relay_restrictions should be available to me, but I'm not sure why it's not working as I expected it to on the submission. I'm also wondering if I no longer need that -o smtpd_client_restrictrions in master.cf (

 

>         reject_invalid_hostname,

Deprecated syntax for reject_invalid_helo_hostname.

>         reject_unauth_destination,

See above re: smtpd_relay_restrictions.

>         warn_if_reject reject_non_fqdn_hostname,

I consider this one quite safe. In fact, it's one of the CBL's
listing criteria; when they see a host using a non-FQDN as HELO, it
will be listed. Deprecated syntax again.

>         warn_if_reject reject_non_fqdn_sender,
>         reject_non_fqdn_recipient,
>         reject_unknown_sender_domain,

These are safe, but mostly pointless here. You might want them on
submission, in case a user has a misconfigured MUA.

>         warn_if_reject reject_unknown_reverse_client_hostname,

Safe, because many large receivers do this as well.

>         warn_if_reject reject_non_fqdn_helo_hostname,

This is the new syntax for reject_non_fqdn_hostname, you do the
warning twice for the same thing.

>         warn_if_reject reject_invalid_helo_hostname,

Deja vu all over again!

>         warn_if_reject reject_unknown_helo_hostname,

This one is NOT safe. A lot of sites use HELOs which don't resolve.
So I'd not take off the warn_if_reject.

>         reject_unauth_pipelining,

This could go higher. It's a "cheap" restriction.

>         check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
>         check_helo_access hash:/etc/postfix/helo_access,
>         check_sender_access hash:/etc/postfix/check_backscatterer,
>         check_sender_access hash:/etc/postfix/access,

"access" is not a descriptive name. I would name it either
"sender_access" or whatever the general purpose of the lookup is. It
could also be merged with the check_backscatterer lookup.

>         reject_rhsbl_client dbl.spamhaus.org,
>         reject_rhsbl_sender dbl.spamhaus.org,
>         reject_rhsbl_helo dbl.spamhaus.org,
>         permit
>
> My guess would be to either put them just after the
> reject_unknown_sender_domain or just before the
> check_reverse_client_hostname... but that's a total guess.
> The BRBL entry I'd stick back just in front of the
> reject_rhsbl_client entry.

I wouldn't whitelist the check_*_access lookups, but you might choose
to do that for your own reasons.

I would put Zen just before the three DBL lookups. This way the DBL
lookups might be avoided. I'd keep DBL before DNSWL. I doubt the
DNSWL folks want to list any client sending for DBL-listed domains,
so check DBL first.

The "low, medium, and high" idea is good, although recently I have
seen a case where BRBL listed a DNSWL "none" host (with legitimate
mail, sigh.)

Based on all of the above excellent recommendations, my smtpd_*_restrictions in main.cf now read:

# SMTPD Restrictions

smtpd_helo_required = yes

disable_vrfy_command = yes

smtpd_recipient_restrictions =

        permit_mynetworks,

        permit_sasl_authenticated,

        reject_unauth_pipelining,

        reject_invalid_helo_hostname,

        warn_if_reject reject_non_fqdn_helo_hostname,

        reject_unknown_reverse_client_hostname,

        warn_if_reject reject_unknown_helo_hostname,

        check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,

        check_helo_access hash:/etc/postfix/helo_access,

        check_sender_access hash:/etc/postfix/sender_access,

        reject_rbl_client zen.spamhaus.org,

        reject_rhsbl_client dbl.spamhaus.org,

        reject_rhsbl_sender dbl.spamhaus.org,

        reject_rhsbl_helo dbl.spamhaus.org,

        permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],

        permit

smtpd_relay_restrictions =

        permit_mynetworks,

        permit_sasl_authenticated,

        reject_unauth_destination

Much cleaner, thanks (plz let me know if I'm still obtusely misunderstanding anything in there). 

However, I'm still scratching me head as to why the smtpd_relay_restrictions on submission aren't allowing my SASL authenticated message to sail through.

Thanks in advance to anyone who can help troubleshoot,

SteveJ

[Noel Jones-2]

On 5/13/2013 6:34 PM, Steve Jenkins wrote:

> On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     >
>     > Here are my current entries:
>     >
>     > smtpd_recipient_restrictions =
>     >         permit_mynetworks,
>     >         permit_sasl_authenticated,
>
>     I don't put these permit_* in global restrictions; I only apply them
>     to submission via -o smtpd_relay_restrictions=... in master.cf
>     <http://master.cf>. And
>     that brings up another point: if you're using 2.10 you now have
>     smtpd_relay_restrictions for relay control.
>
>
> First, thanks for the extremely insightful help, Rob.
>
> OK - I commented those two lines out of smtpd_recipient_restrictions
> as recommended, and added a new smtpd_relay_restrictions -o line to
> submission in master.cf <http://master.cf>. My submission now reads:
>
> 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
>   -o
> smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
>
> However, I get this when sending a message from my home desktop
> (connected via Comcast) via my personal Postfix server to my Gmail
> test address:

Don't forget that all the other main.cf parameters are still in
effect on your "submission" entry; likely you're seeing unintended
spillover.

I suggest setting ALL the smtpd_*_restrictions entries for
submission in master.cf so you don't have unexpected results.

submission inet n       -       n       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o milter_macro_daemon_name=ORIGINATING
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject



  -- Noel Jones

[Noel Jones-2]

On 5/13/2013 8:42 PM, Noel Jones wrote:

> On 5/13/2013 6:34 PM, Steve Jenkins wrote:
>> On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     >
>>     > Here are my current entries:
>>     >
>>     > smtpd_recipient_restrictions =
>>     >         permit_mynetworks,
>>     >         permit_sasl_authenticated,
>>
>>     I don't put these permit_* in global restrictions; I only apply them
>>     to submission via -o smtpd_relay_restrictions=... in master.cf
>>     <http://master.cf>. And
>>     that brings up another point: if you're using 2.10 you now have
>>     smtpd_relay_restrictions for relay control.
>>
>>
>> First, thanks for the extremely insightful help, Rob.
>>
>> OK - I commented those two lines out of smtpd_recipient_restrictions
>> as recommended, and added a new smtpd_relay_restrictions -o line to
>> submission in master.cf <http://master.cf>. My submission now reads:
>>
>> 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
>>   -o
>> smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
>>
>> However, I get this when sending a message from my home desktop
>> (connected via Comcast) via my personal Postfix server to my Gmail
>> test address:
>
> Don't forget that all the other main.cf parameters are still in
> effect on your "submission" entry; likely you're seeing unintended
> spillover.
>
> I suggest setting ALL the smtpd_*_restrictions entries for
> submission in master.cf so you don't have unexpected results.
>
> submission inet n       -       n       -       -       smtpd
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o milter_macro_daemon_name=ORIGINATING
>   -o smtpd_client_restrictions=
>   -o smtpd_helo_restrictions=
>   -o smtpd_sender_restrictions=
>   -o smtpd_recipient_restrictions=
>   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
>

and don't forget
  -o smtpd_data_restrictions=
  -o smtpd_end_of_data_restrictions=



>
>
>   -- Noel Jones
>

[Steve Jenkins-3]

On Mon, May 13, 2013 at 6:42 PM, Noel Jones <[hidden email]> wrote:

On 5/13/2013 6:34 PM, Steve Jenkins wrote:
> On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     >
>     > Here are my current entries:
>     >
>     > smtpd_recipient_restrictions =
>     >         permit_mynetworks,
>     >         permit_sasl_authenticated,
>
>     I don't put these permit_* in global restrictions; I only apply them
>     to submission via -o smtpd_relay_restrictions=... in master.cf
>     <http://master.cf>. And
>     that brings up another point: if you're using 2.10 you now have
>     smtpd_relay_restrictions for relay control.
>
>
> First, thanks for the extremely insightful help, Rob.
>
> OK - I commented those two lines out of smtpd_recipient_restrictions
> as recommended, and added a new smtpd_relay_restrictions -o line to
> submission in master.cf <http://master.cf>. My submission now reads:
>
> 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
>   -o
> smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
>
> However, I get this when sending a message from my home desktop
> (connected via Comcast) via my personal Postfix server to my Gmail
> test address:

Don't forget that all the other main.cf parameters are still in
effect on your "submission" entry; likely you're seeing unintended
spillover.

I suggest setting ALL the smtpd_*_restrictions entries for
submission in master.cf so you don't have unexpected results.

submission inet n       -       n       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o milter_macro_daemon_name=ORIGINATING
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

Hmm.. for some reason, I can't seem to get it to aceept my smtpd_relay_restrictions settings.

In main.cf: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

but the I get:

# postconf -d | grep smtpd_relay

smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination

Any idea why my permit_sasl_authenticated is being ignored in favor of the default?

SteveJ