date:20161121

Hello,

In my setup, I’m using the greylisting policy. Now, a spammer tries to send 
mail to a nonexistent address. But he still gets the greylisting temp failure 
sent:

Nov 21 16:35:42 vanroodewierda.rna.nl postfix/smtpd[21832]: connect from 
unknown[186.1.16.66]
Nov 21 16:35:43 vanroodewierda /usr/libexec/postfix/greylist.pl[21841]: 
Temporary message rejection to:  from: 
 sent from: [186.1.16.66] for: 60 seconds due to 
greylisting
Nov 21 16:35:43 vanroodewierda.rna.nl postfix/smtpd[21832]: NOQUEUE: reject: 
RCPT from unknown[186.1.16.66]: 450 4.7.1 : Recipient 
address rejected: Service is unavailable; from= 
to= proto=ESMTP helo=
Nov 21 16:35:43 vanroodewierda.rna.nl postfix/smtpd[21832]: disconnect from 
unknown[186.1.16.66]

rna.nl is in $mydestinations (it is $mydomain), g.c.th.wierdadd does not exist 
(is not a valid user or alias or virtual_user).

Config

smtpd_helo_restrictions =
permit_mynetworks
reject_non_fqdn_helo_hostname
reject_invalid_helo_hostname
permit
smtpd_client_restrictions =
permit_mynetworks
permit_sasl_authenticated
check_client_access 
regexp:/Library/Server/Mail/Config/postfix/rna_rbl_whitelist_clients
reject_rbl_client zen.spamhaus.org
permit
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
reject_unknown_recipient_domain
reject_unverified_recipient
check_client_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients
check_sender_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders
check_policy_service unix:private/policy
permit

Question: why does this message end up in greylisting while I have 
reject_unverified_recipient set?

Is this potentially an (unexpected) result of smtpd_delay_reject = yes?

Thanks,

G

Re: Question about reject_unverified_recipient in smtpd_recipient_restrictions

Gerben Wierda:
> smtpd_recipient_restrictions =
>   permit_sasl_authenticated
>   permit_mynetworks
>   reject_unauth_destination
>   reject_unknown_recipient_domain
>   reject_unverified_recipient

You may want to look at these settings (defaults shown):

unverified_recipient_defer_code = 450
unverified_recipient_reject_code = 450
unverified_recipient_reject_reason =
unverified_recipient_tempfail_action = $reject_tempfail_action
reject_tempfail_action = defer_if_permit

I suspect that you're hitting a cached defer_if_permit response.

Wietse

>   check_client_access 
> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients
>   check_sender_access 
> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders
>   check_policy_service unix:private/policy
>   permit
> 
> Question: why does this message end up in greylisting while I have 
> reject_unverified_recipient set?
> 
> Is this potentially an (unexpected) result of smtpd_delay_reject = yes?
> 
> Thanks,
> 
> G

Re: Best place to filter spam (x-original-to, no_address_mappings)


Can anyone help with this please?

On 2016-11-18 21:03, MRob wrote:

Hello,

I am looking at a system where SpamAssassin is called out from the
delivery agent. I know there will be a difference here in terms of the
envelope information but I'm not familiar enough to know the pitfalls
of this versus calling SA from the postfix content_filter.

Specifically, I believe it's recommended to call SA in context of
receive_override_options=no_address_mappings but this wouldn't be the
case when we are in the delivery agent I think. What are the effects
of this?

Also, if it's possible to have LMTP send the original envelope sender
(x-original-to?), would that help? And is that possible yet in the
newest version of Postfix?

Re: Question about reject_unverified_recipient in smtpd_recipient_restrictions

> On 21 Nov 2016, at 17:33, Wietse Venema  wrote:
> 
> Gerben Wierda:
>> smtpd_recipient_restrictions =
>>  permit_sasl_authenticated
>>  permit_mynetworks
>>  reject_unauth_destination
>>  reject_unknown_recipient_domain
>>  reject_unverified_recipient
> 
> You may want to look at these settings (defaults shown):
> 
>unverified_recipient_defer_code = 450
>unverified_recipient_reject_code = 450
>unverified_recipient_reject_reason =
>unverified_recipient_tempfail_action = $reject_tempfail_action
>reject_tempfail_action = defer_if_permit

from postconf:

address_verify_map = btree:$data_directory/verify_cache
unverified_recipient_defer_code = 450
unverified_recipient_reject_code = 450
unverified_recipient_reject_reason =
unverified_recipient_tempfail_action = $reject_tempfail_action
reject_tempfail_action = defer_if_permit

> I suspect that you're hitting a cached defer_if_permit response.

I don’t understand what that means or what to do about it. Should I just remove 
/Library/Server/Mail/Data/mta/verify_cache.db and do a reload?

Or should I just have to add to main.cf:
unverified_recipient_reject_code = 550
and do a reload? 

And is that last thing safe? Another question. The phrase “Reject the request 
when mail to the RCPT TO address is known to bounce, or when the recipient 
address destination is not reachable.” leads to some confusion for me. Does 
‘not reachable’ also include temporary failures? If so, wouldn’t this mechanism 
turn normal 450 into 550 when it is not supposed to do?

What I’m looking for is a way that nonexistent local addresses are rejected. 
The strange thing is, they are of course at some point. When I try to mail to 
n...@rna.nl  from a local machine (so ssl_authenticated and 
local network) I get The server response was: mailto:n...@rna.nl>>: Recipient address rejected: User unknown in local 
recipient table But when spammers do this, they currently get a policy response 
instead.

I don’t want to hit outgoing mail (my own users, all authenticated) with this, 
only incoming for my own destinations,

G

PS. What command do I use to get my exact postfix version?

> 
>   Wietse
> 
>>  check_client_access 
>> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients
>>  check_sender_access 
>> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders
>>  check_policy_service unix:private/policy
>>  permit
>> 
>> Question: why does this message end up in greylisting while I have 
>> reject_unverified_recipient set?
>> 
>> Is this potentially an (unexpected) result of smtpd_delay_reject = yes?
>> 
>> Thanks,
>> 
>> G

Re: Best place to filter spam (x-original-to, no_address_mappings)

MRob:
> Can anyone help with this please?

Looks like this is not a common use case.

 Wietse

Re: Question about reject_unverified_recipient in smtpd_recipient_restrictions

Gerben Wierda:
> 
> > On 21 Nov 2016, at 17:33, Wietse Venema  wrote:
> > 
> > Gerben Wierda:
> >> smtpd_recipient_restrictions =
> >>permit_sasl_authenticated
> >>permit_mynetworks
> >>reject_unauth_destination
> >>reject_unknown_recipient_domain
> >>reject_unverified_recipient
> > 
> > You may want to look at these settings (defaults shown):
> > 
> >unverified_recipient_defer_code = 450
> >unverified_recipient_reject_code = 450
> >unverified_recipient_reject_reason =
> >unverified_recipient_tempfail_action = $reject_tempfail_action
> >reject_tempfail_action = defer_if_permit
> 
> from postconf:
> 
> address_verify_map = btree:$data_directory/verify_cache
> unverified_recipient_defer_code = 450
> unverified_recipient_reject_code = 450
> unverified_recipient_reject_reason =
> unverified_recipient_tempfail_action = $reject_tempfail_action
> reject_tempfail_action = defer_if_permit
> 
> > I suspect that you're hitting a cached defer_if_permit response.

Actually, the stored info is one of {accepted, deferred, rejected}.
I cannot quickly locate the code that uses the
unverified_recipient_tempfail_action setting.

> Or should I just have to add to main.cf:
> unverified_recipient_reject_code = 550
> and do a reload? 

Yes, you probably want to reject mail immediately.

> Another question. The phrase ?Reject the request when mail to the
> RCPT TO address is known to bounce, or when the recipient address
> destination is not reachable.? leads to some confusion for me.
> Does ?not reachable? also include temporary failures?

Temporary failure means that the answer is not known. When making
an irreversible decision (like permanently rejecting mail), Postfix
is quite insistent on making the distinction between having and not
having authoritative information.

Wietse

postscreen logging

2016-11-21 Thread @lbutlr

I am wondering what the various possible types of events postscreen logs. I 
checked man postsreen(8) but it doesn’t seem to give them.

I know there are PASS NEW, PASS OLD, CONNECT, DISCONNECT, HANGUP, NOQUEUE, 
COMMAND, cache, and DNSBL. Any others I am missing?

Are these documented in some other man page?

(Currently I’m interested int he difference between HANGUP and DISCONNECT and 
NOQUEUE and why sometimes hosts that connect thousands of times with high RBL 
scores don’t necessarily get HANGUP.)

Re: Question about reject_unverified_recipient in smtpd_recipient_restrictions

Wietse, sorry, please bear with me here, but this is not easy to understand 
(given the complexity of all the settings). And I’m afraid to damage my mail in 
the sense that I start refusing legitimate mail.

> On 21 Nov 2016, at 21:17, Wietse Venema  wrote:
> 
> Gerben Wierda:
>> 
>>> On 21 Nov 2016, at 17:33, Wietse Venema  wrote:
>>> 
>>> Gerben Wierda:
 smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
reject_unknown_recipient_domain
reject_unverified_recipient
>>> 
>>> You may want to look at these settings (defaults shown):
>>> 
>>>   unverified_recipient_defer_code = 450
>>>   unverified_recipient_reject_code = 450
>>>   unverified_recipient_reject_reason =
>>>   unverified_recipient_tempfail_action = $reject_tempfail_action
>>>   reject_tempfail_action = defer_if_permit
>> 
>> from postconf:
>> 
>> address_verify_map = btree:$data_directory/verify_cache
>> unverified_recipient_defer_code = 450
>> unverified_recipient_reject_code = 450
>> unverified_recipient_reject_reason =
>> unverified_recipient_tempfail_action = $reject_tempfail_action
>> reject_tempfail_action = defer_if_permit
>> 
>>> I suspect that you're hitting a cached defer_if_permit response.
> 
> Actually, the stored info is one of {accepted, deferred, rejected}.
> I cannot quickly locate the code that uses the
> unverified_recipient_tempfail_action setting.
> 
>> Or should I just have to add to main.cf:
>> unverified_recipient_reject_code = 550
>> and do a reload? 
> 
> Yes, you probably want to reject mail immediately.
> 
>> Another question. The phrase ?Reject the request when mail to the
>> RCPT TO address is known to bounce, or when the recipient address
>> destination is not reachable.? leads to some confusion for me.
>> Does ?not reachable? also include temporary failures?
> 
> Temporary failure means that the answer is not known. When making
> an irreversible decision (like permanently rejecting mail), Postfix
> is quite insistent on making the distinction between having and not
> having authoritative information.

So, just that I understand. With *my* unverified_recipient_reject_code in the 
5xx range, but a remote SMTP server giving a temporary failure (4xx) on an 
address (or just plain unreachable), *my* postfix would still return 4xx 
because it cannot be certain?

I still would like to understand why with a setting like this

smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
reject_unknown_recipient_domain
reject_unverified_recipient
check_client_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients
check_sender_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders
check_policy_service unix:private/policy
permit

and a recipient that is not in the 'local recipient table’, 
check_policy_service is even reached. Is that *solely* because of 
unverified_recipient_reject_code is in the 4xx range? 

And the best thing is: how do I make sure that reject_unverified_recipient only 
works on local ($mydestination) addresses?

I am rna.nl . If foo.com  sends mail to 
u...@rna.nl  I want rejection on locally undeliverable 
recipients to be quick. If my users connect to my mail server for outgoing 
mail, I want no local cache of ‘verified’ recipients, I leave that to the MTA 
at the final destination.

G

Re: Best place to filter spam (x-original-to, no_address_mappings)

2016-11-21 Thread @lbutlr

On Nov 21, 2016, at 11:43 AM, MRob  wrote:
> On 2016-11-18 21:03, MRob wrote:
>> Hello,
>> I am looking at a system where SpamAssassin is called out from the
>> delivery agent. I know there will be a difference here in terms of the
>> envelope information but I'm not familiar enough to know the pitfalls
>> of this versus calling SA from the postfix content_filter.

You can call spam assassin from an LDA like procmail or sieve, but that is not 
a topic for this list.

Calling SA during the transaction is much better though, since it allows you to 
drop very spammy messages as undeliverable.

Re: Question about reject_unverified_recipient in smtpd_recipient_restrictions

I did another test. I changed the recipient restrictions to:

smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
reject_unknown_recipient_domain,
reject_unverified_recipient,
check_client_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients,
check_sender_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders,
check_policy_service unix:private/policy,
permit

But when I locally send mail to a non fqdn address, it just gets delivered:

Nov 21 22:14:49 vanroodewierda.rna.nl postfix/smtpd[26346]: 5E2B31BBECEC: 
client=hermione.rna.nl[192.168.2.86], sasl_method=DIGEST-MD5, 
sasl_username=gerben
Nov 21 22:14:49 vanroodewierda.rna.nl postfix/cleanup[26389]: 5E2B31BBECEC: 
message-id=<578450b1-63a8-487d-91c3-a434f7ddb...@rna.nl>
Nov 21 22:14:49 vanroodewierda.rna.nl postfix/qmgr[26379]: 5E2B31BBECEC: 
from=, size=517, nrcpt=1 (queue active)
Nov 21 22:14:49 vanroodewierda.rna.nl postfix/pipe[26392]: 5E2B31BBECEC: 
to=, orig_to=, relay=dovecot, delay=0.24, 
delays=0.14/0.02/0/0.08, dsn=2.0.0, status=sent (delivered via dovecot service)
Nov 21 22:14:49 vanroodewierda.rna.nl postfix/qmgr[26379]: 5E2B31BBECEC: removed

Now, this is weird. Definitely non-fqdn (orig_to=), 
reject_non_fqdn_recipient, but delivered nonetheless.

G

> On 21 Nov 2016, at 21:17, Wietse Venema  wrote:
> 
> Gerben Wierda:
>> 
>>> On 21 Nov 2016, at 17:33, Wietse Venema  wrote:
>>> 
>>> Gerben Wierda:
 smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
reject_unknown_recipient_domain
reject_unverified_recipient
>>> 
>>> You may want to look at these settings (defaults shown):
>>> 
>>>   unverified_recipient_defer_code = 450
>>>   unverified_recipient_reject_code = 450
>>>   unverified_recipient_reject_reason =
>>>   unverified_recipient_tempfail_action = $reject_tempfail_action
>>>   reject_tempfail_action = defer_if_permit
>> 
>> from postconf:
>> 
>> address_verify_map = btree:$data_directory/verify_cache
>> unverified_recipient_defer_code = 450
>> unverified_recipient_reject_code = 450
>> unverified_recipient_reject_reason =
>> unverified_recipient_tempfail_action = $reject_tempfail_action
>> reject_tempfail_action = defer_if_permit
>> 
>>> I suspect that you're hitting a cached defer_if_permit response.
> 
> Actually, the stored info is one of {accepted, deferred, rejected}.
> I cannot quickly locate the code that uses the
> unverified_recipient_tempfail_action setting.
> 
>> Or should I just have to add to main.cf:
>> unverified_recipient_reject_code = 550
>> and do a reload? 
> 
> Yes, you probably want to reject mail immediately.
> 
>> Another question. The phrase ?Reject the request when mail to the
>> RCPT TO address is known to bounce, or when the recipient address
>> destination is not reachable.? leads to some confusion for me.
>> Does ?not reachable? also include temporary failures?
> 
> Temporary failure means that the answer is not known. When making
> an irreversible decision (like permanently rejecting mail), Postfix
> is quite insistent on making the distinction between having and not
> having authoritative information.
> 
>   Wietse

Re: Veracode reported vulnerabilities

2016-11-21 Thread Mc Security

Here are the line numbers for the remaining two items:

1. Buffer overflow Sourcefile: dns_rr.c, Line: 129, Module: dnsblog

2. Buffer oevrflow Sourcefile: tls_scache.c, Line: 208, Module: smtpd

Thanks,

Mc.

On Wed, Nov 16, 2016 at 9:40 PM, Mc Secuirty  wrote:

> Wietse:
>
> Thank you very much for the response. I will look at the remaining two
> items to see if they are also false positives based on the information you
> provided for the other items. If I can't, I will try to get the lines
> numbers at least for those two.
>
> Thanks
> Mc.
>
> On Wed, Nov 16, 2016 at 7:54 PM, Wietse Venema 
> wrote:
>
>> McSec:
>> > A Veracode scan reported the following vulnerabilites in postfix 3.0.1:
>> >
>> > vulnerabilitymodulesource
>> > Buffer Over Flowdnsblog   home/.../src/dns/dns_rr.c
>> > Buffer Over Flowsmtpd home/.../src/tls/tls_scache.c
>>
>> There is no line number information, therefore this information is
>> not actionable.
>>
>> > Numeric Errors  dnsblog   home/.../src/dns/dns_rr.c 262
>> > Numeric Errors  dnsblog   home/.../src/dns/dns_rr.c 302
>>
>> Both are not a vulnerability, because DNS replies don't contain 268
>> million responses. The DNS reply count is a 16-bit number, and is
>> therefore limited to 0..65535.
>>
>> > Numeric Errors  dnsblog   home/.../src/dns/dns_strtype.c
>> 207
>>
>> Not a vulnerability, because the dns_type_map[] table with symbolic
>> names for DNS record types is much smaller than 2 billion.  The DNS
>> record type is a 16-bit number, therefore there can be only 65536
>> different record types.
>>
>> > Numeric Errors  smtpd home/.../src/tls/tls_dane.c 1291
>>
>> Not a vulnerability, because the trust anchor file is owned by a
>> trusted local user (root), and because that file will contain fewer
>> than 2 billion entries.
>>
>> Wietse
>>
>
>

Re: postscreen logging

2016-11-21 Thread Noel Jones

On 11/21/2016 2:46 PM, @lbutlr wrote:
> I am wondering what the various possible types of events postscreen logs. I 
> checked man postsreen(8) but it doesn’t seem to give them.
> 
> I know there are PASS NEW, PASS OLD, CONNECT, DISCONNECT, HANGUP, NOQUEUE, 
> COMMAND, cache, and DNSBL. Any others I am missing?
> 
> Are these documented in some other man page?

Most of this is covered in the readme:
http://www.postfix.org/POSTSCREEN_README.html

> 
> (Currently I’m interested int he difference between HANGUP and DISCONNECT and 
> NOQUEUE and why sometimes hosts that connect thousands of times with high RBL 
> scores don’t necessarily get HANGUP.)

HANGUP: the client disconnected unexpectedly. Spambots often do this
after a recipient is rejected.
DISCONNECT: postscreen is done with the client and did not pass the
connection to smtpd
NOQUEUE: if you've configured postfix to log the sender/recipient of
a rejected message (enforce), this is both a placeholder for the
queue id and a reminder the message was not queued.

If you've configured postscreen with "enforce", it's not unusual for
all three of the above to be logged for a particular client connection.

As you see, HANGUP is something the client does, not a postscreen
action.

  -- Noel Jones

Re: Best place to filter spam (x-original-to, no_address_mappings)


On 2016-11-21 11:58, wie...@porcupine.org wrote:

MRob:

Can anyone help with this please?


Looks like this is not a common use case.


I'm looking for conceptual clarification, as in what, if any, difference 
the envelope fields have when a message is inspected at the 
content_filter scope, both with no_address_mappings on and off -- as 
well as how the message is seen when sent for delivery via LMTP.


I also assume multi-recipient messages would be filtered multiple times 
if done in delivery vs. only once in content_filter.


Susequent to that is if anyone has advice for the implications of the 
change in envelope fields on how SA scores messages.


Is that any better for the question?

Oh, and if having X-Original-To header would help, if I can even get 
Postfix to append it when using LMTP.

Re: Best place to filter spam (x-original-to, no_address_mappings)


On 2016-11-21 13:06, @lbutlr wrote:

On Nov 21, 2016, at 11:43 AM, MRob  wrote:

On 2016-11-18 21:03, MRob wrote:

Hello,
I am looking at a system where SpamAssassin is called out from the
delivery agent. I know there will be a difference here in terms of 
the

envelope information but I'm not familiar enough to know the pitfalls
of this versus calling SA from the postfix content_filter.


You can call spam assassin from an LDA like procmail or sieve, but
that is not a topic for this list.

Calling SA during the transaction is much better though, since it
allows you to drop very spammy messages as undeliverable.


Appreciate the reply, but I wasn't asking how to set it up. I thought my 
question made it clear I was asking about the pros/cons of the placement 
of SA in the mail flow. Please see my message just sent a minute ago for 
another try.


By the way it is my impression that, at least for sites with volume 
above that of a home or very small business, calling out to filters like 
SA or clam during the SMTP transaction can really kill performance and 
that it's best to simply send messages scored very highly to the bit 
bucket.

Re: Veracode reported vulnerabilities

2016-11-21 Thread Mc Security

I see that there is careful memory allocation done for DNS_RR and
TLS_SCACHE_ENTRY in in dns_rr.c  and tls_scache.c respectively so that
buffer overflow is not caused. However, a confirmation would be great.

On Mon, Nov 21, 2016 at 1:51 PM, Mc Security  wrote:

> Here are the line numbers for the remaining two items:
>
> 1. Buffer overflow Sourcefile: dns_rr.c, Line: 129, Module: dnsblog
>
> 2. Buffer oevrflow Sourcefile: tls_scache.c, Line: 208, Module: smtpd
>
> Thanks,
>
> Mc.
>
> On Wed, Nov 16, 2016 at 9:40 PM, Mc Secuirty  wrote:
>
>> Wietse:
>>
>> Thank you very much for the response. I will look at the remaining two
>> items to see if they are also false positives based on the information you
>> provided for the other items. If I can't, I will try to get the lines
>> numbers at least for those two.
>>
>> Thanks
>> Mc.
>>
>> On Wed, Nov 16, 2016 at 7:54 PM, Wietse Venema 
>> wrote:
>>
>>> McSec:
>>> > A Veracode scan reported the following vulnerabilites in postfix 3.0.1:
>>> >
>>> > vulnerabilitymodulesource
>>> > Buffer Over Flowdnsblog   home/.../src/dns/dns_rr.c
>>> > Buffer Over Flowsmtpd home/.../src/tls/tls_scache.c
>>>
>>> There is no line number information, therefore this information is
>>> not actionable.
>>>
>>> > Numeric Errors  dnsblog   home/.../src/dns/dns_rr.c 262
>>> > Numeric Errors  dnsblog   home/.../src/dns/dns_rr.c 302
>>>
>>> Both are not a vulnerability, because DNS replies don't contain 268
>>> million responses. The DNS reply count is a 16-bit number, and is
>>> therefore limited to 0..65535.
>>>
>>> > Numeric Errors  dnsblog   home/.../src/dns/dns_strtype.c
>>> 207
>>>
>>> Not a vulnerability, because the dns_type_map[] table with symbolic
>>> names for DNS record types is much smaller than 2 billion.  The DNS
>>> record type is a 16-bit number, therefore there can be only 65536
>>> different record types.
>>>
>>> > Numeric Errors  smtpd home/.../src/tls/tls_dane.c 1291
>>>
>>> Not a vulnerability, because the trust anchor file is owned by a
>>> trusted local user (root), and because that file will contain fewer
>>> than 2 billion entries.
>>>
>>> Wietse
>>>
>>
>>
>

Re: Veracode reported vulnerabilities

2016-11-21 Thread Viktor Dukhovni

> On Nov 21, 2016, at 5:44 PM, Mc Security  wrote:
> 
> I see that there is careful memory allocation done for DNS_RR and 
> TLS_SCACHE_ENTRY in in dns_rr.c  and tls_scache.c respectively so that buffer 
> overflow is not caused. However, a confirmation would be great.

I think the correct protocol for reporting static analysis results
is that the triage effort is the responsibility of the reporter, not
the upstream maintainer.

It makes little sense for upstream maintainers to pursue every unverified
report that some new tool spits out.  These tools unavoidably have
non-negligible FP rates, and require human attention to separate reality
from fiction.

So if you don't see a problem, we're done.  If you do find a credible
problem in a report, please do forward it along.  If such a problem is
potentially remotely exploitable, report it off-list.

-- 
Viktor.

Re: Best place to filter spam (x-original-to, no_address_mappings)

2016-11-21 Thread @lbutlr

On Nov 21, 2016, at 3:30 PM, MRob  wrote:
> Appreciate the reply, but I wasn't asking how to set it up. I thought my 
> question made it clear I was asking about the pros/cons of the placement of 
> SA in the mail flow.

No, that wasn’t clear. At least not to me.

The main advantage to checking spam status early is to reject the mail outright 
and possibly black list the sending IP address. the disadvantage, of course, is 
you have to hold the connection long enough to score the email.

The main advantage to scoring after delivery is that you can foist the work off 
to an LDA the can, honestly, take as long as it wants to process and score the 
mail. Also, this might be an entirely different machine than the one receiving 
mail. The disadvantage is you receive a lot more spam.

> Please see my message just sent a minute ago for another try.
> 
> By the way it is my impression that, at least for sites with volume above 
> that of a home or very small business, calling out to filters like SA or clam 
> during the SMTP transaction can really kill performance and that it's best to 
> simply send messages scored very highly to the bit bucket.

Not sure where the cutoff is, but many reasonably large mail servers use amavis 
(or similar) to score mail and will reject it for high spam levels.

Not the gmails of the world, but still, large servers.

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

2016-11-21 Thread Joel Linn

Hey Guys,

this issue has decayed a bit but I now finally found the time (and the
nerves) to integrate the fix in my system.
I'm running Ubuntu 16.04 and trying not change to many things and be
able to have clean comparison I applied the patch to the apt sources and
only replaced the postfix-mysql package (ubuntu is using 3.1.0 it seems)
with my own.
I introduced some stored procedures and from my tests I conclude it
works. I will see in the next couple of days if there are issues I
overlooked.
I ran into an issue where I was returning no result set using
"smtpd_recipient_restrictions = check_recipient_access mysql:/[...]".
I'm not sure if that's an dict_mysql issue or caused by design upstream.
I overcame that by doing "select 1 from dual where false" when I don't
have anything else to return, which basically is an empty result set.

Thanks very much for your work,
Joel

On 2016-07-07 00:46, John Fawcett wrote:

On 07/04/2016 09:58 PM, j...@conductive.de wrote:

Quoting John Fawcett :
I can propose a code submission to add stored procedure support
(based

on the proof of concept code from 2008), but the biggest part will be
doing the testing and non regression testing not the actual coding.

I believe the best approach to adding stored procedure support is to
iterate over multiple result sets and if there are exactly two and
the

last one is the status result of the stored procedure and it is
successful then allow the lookup against the first result set. In all
other cases there should be an error for multiple result sets. In the
context of Postfix don't think it is useful to have more than one
result

set generated by multiple queries or more than two result sets
(including the status one) from a stored procedure.

John

That is exactly what I had on my mind.

The specific error message would enable admins to exactly see where
the trouble originates.
Also consuming all results still allows subsequent lookups to succeed
normally.

I would of course volunteer to "test" the change per se but I'm afraid
my knowledge of postfix's inner workings converges to zero, rendering
my testing unrepresentative at last :/
Although the subset of postfix interfacing with mysql is quite small.

Joel

here is my proposed submission to add mysql stored procedure support to
Postfix. As per Wietse's comments in the following thread

http://postfix.1071664.n5.nabble.com/fatal-table-lookup-problem-with-Postfix-lookup-call-to-MySQL-StoredProcedure-td13240.html

"I would be grateful if that support came with test cases for single
and multi-result queries, including non-error and error results so
that we can run the test whenever something in the code is changed."

One further thing to point out and that may need to be adjusted still:

An error is returned whenever:

- the check for further result sets gives an error instead of yes (0)
or

no (-1)

- the stored procedure final result set with the status is not as
expected (mysql_field_count returns 0)

- there is more than one result set containing data.

While testing with postmap and multiple result sets I was able to
generate the following error message from postmap.c

"postmap: fatal: table mysql:./mysql-test2.cf: query error: Success"

The final "Success" comes from %m parameter reporting the errno. Since
no system call error has been returned, but it is an application error
I

have forced errno to ENOTSUP. If instead the "Success" status is deemed
correct, then the statement setting errno and the inclusion of errno.h
can be elimianted without changing the basic functioning of the patch.

I am available to make any further adjustments needed. I look forward
to
feedback from Joel or other interested people about more extensive
testing.

John

Re: Veracode reported vulnerabilities

Mc Security:
> Here are the line numbers for the remaining two items:
> 
> 1. Buffer overflow Sourcefile: dns_rr.c, Line: 129, Module: dnsblog

False positive. Veracode does not understand how the code works.

> 2. Buffer oevrflow Sourcefile: tls_scache.c, Line: 208, Module: smtpd

Same thing.

Postfix software may be 'free' to use, but supporting it costs real
effort. Don't waste it.

Wietse

Re: Question about reject_unverified_recipient in smtpd_recipient_restrictions

Gerben Wierda:
> I did another test. I changed the recipient restrictions to:
> 
> smtpd_recipient_restrictions =
>   reject_unauth_pipelining,
>   reject_non_fqdn_recipient,
>   permit_sasl_authenticated,
>   permit_mynetworks,

Due to permit_mynetworks, sending mail from a "local" client will
skip all further checks.

>   reject_unauth_destination,
>   reject_unknown_recipient_domain,
>   reject_unverified_recipient,
>   check_client_access 
> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients,
>   check_sender_access 
> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders,
> check_policy_service unix:private/policy,
> permit

Re: Best place to filter spam (x-original-to, no_address_mappings)