Re: Problem filtering broken PGP mail with body_checks

2015-09-11 Thread Stuart Longland
On 12/09/15 08:31, Sebastian Nielsen wrote:
> Yep. On top of that: ([^-]*) means any charachter except for -, so it
> shouldn't match any -, and thus $2 cannot contain the charachter "-" at
> all.
> 
> I suspect that postfix in some way matches the whole message in once,
> and when the REPLACE word is given, the whole message, even including
> parts of message that does not match the regexp, are replaced by the
> "REPLACE". But I tried with (.*) before and after, and added $1 to the
> beginning and $4 to the end, and also changed $1$2 to $2$3, but that
> didnt help.

Indeed, does it dump the email body content for *all* emails or just the
ones with inline PGP?

If not, a possible rule:

/[ \t\r\f]*-BEGIN ([^-]*)-[ \t\r\f]*(.*)-END \1-/
REPLACE -BEGIN $1-\r$2-END $1-

That should preserve the content inside the PGP message (probably
discarding anything outside).  You want to avoid changing things between
BEGIN and END though because that might cause signature invalidation.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.



signature.asc
Description: OpenPGP digital signature


Re: spf/dkim authentication-failure

2015-09-11 Thread Benny Pedersen

On September 12, 2015 12:03:21 AM Alice Wonder  wrote:


I don't think there is anything I can do about that in my dmarc
configuration, but I just want to make sure.


dmarc pass is fine for me, if it fails on other maillists its not your fault


Re: Problem filtering broken PGP mail with body_checks

2015-09-11 Thread Sebastian Nielsen
Yep. On top of that: ([^-]*) means any charachter except for -, so it 
shouldn't match any -, and thus $2 cannot contain the charachter "-" at all.


I suspect that postfix in some way matches the whole message in once, and 
when the REPLACE word is given, the whole message, even including parts of 
message that does not match the regexp, are replaced by the "REPLACE". But I 
tried with (.*) before and after, and added $1 to the beginning and $4 to 
the end, and also changed $1$2 to $2$3, but that didnt help.


-Ursprungligt meddelande- 
From: Stuart Longland

Sent: Saturday, September 12, 2015 12:29 AM
To: postfix-users@postfix.org
Subject: Re: Problem filtering broken PGP mail with body_checks [Invalid]

On 12/09/15 08:24, Stuart Longland wrote:

This is just a wild guess on my part, but could that possibly be matching:


> -BEGIN BLAH-

   ^^^

> yadda yadda yadda

  ^

> -END BLAH-

  ^

and giving you: $1="BEGIN", $2=" BLAH-\r\nyadda yadda
yadda\r\n-END BLAH"?


And as most wild guesses, they can be wildly inaccurate.  Just realised
what the substitution would look like in that case.  Apologies for the
noise.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
 ...it's backed up on a tape somewhere.



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Problem filtering broken PGP mail with body_checks

2015-09-11 Thread Stuart Longland
On 12/09/15 08:24, Stuart Longland wrote:
> This is just a wild guess on my part, but could that possibly be matching:
> 
>> > -BEGIN BLAH-
>^^^
>> > yadda yadda yadda
>   ^
>> > -END BLAH-
>   ^
> 
> and giving you: $1="BEGIN", $2=" BLAH-\r\nyadda yadda
> yadda\r\n-END BLAH"?

And as most wild guesses, they can be wildly inaccurate.  Just realised
what the substitution would look like in that case.  Apologies for the
noise.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.



signature.asc
Description: OpenPGP digital signature


Re: Problem filtering broken PGP mail with body_checks

2015-09-11 Thread Stuart Longland
On 12/09/15 06:29, Sebastian Nielsen wrote:
> So the rule is as follows:
> /[ \t\r\f]*-(BEGIN|END)([^-]*)-[ \t\r\f]*/ REPLACE -$1$2-
>  
> The problem with this, is that this removed the whole body of the mail
> except for the -BEGIN PGP MESSAGE- line.
>  
> What are im doing wrong? I have tried with different flags like /s or
> /si and such, but still it removes the whole body.
> I want it to scan line for line and process it.

This is just a wild guess on my part, but could that possibly be matching:

> -BEGIN BLAH-
   ^^^
> yadda yadda yadda
  ^
> -END BLAH-
  ^

and giving you: $1="BEGIN", $2=" BLAH-\r\nyadda yadda
yadda\r\n-END BLAH"?

What happens if you try

/[ \t\r\f]*-(BEGIN|END)([A-Z ]*)-[ \t\r\f]*/ REPLACE -$1$2-

instead?
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.


spf/dkim authentication-failure

2015-09-11 Thread Alice Wonder

I have started to get a lot of those when I send messages to some lists.

I understand what is happening, dmarc identifies my domain as DKIM/SPIF 
enabled but when sending a message to a list, both of those will fail.


I don't think there is anything I can do about that in my dmarc 
configuration, but I just want to make sure.


-=-

Also, if I start checking dmarc on my server (I haven't yet) for 
messages coming in to me, is there an intelligent way to determine cases 
where they fail because it is a list and NOT send the useless e-mail to 
the dmarc address?


Problem filtering broken PGP mail with body_checks

2015-09-11 Thread Sebastian Nielsen
Im trying to filter broken PGP mail into usable mail with body checks.
I have selected to use pcre: when defining body_checks.

The problem is that certain PGP useragents, inserts a \r charachter, a tab, 
space, or any other whitespace char immediately before or after the “-BEGIN 
PGP MESSAGE-“ header.

So the rule is as follows:
/[ \t\r\f]*-(BEGIN|END)([^-]*)-[ \t\r\f]*/ REPLACE -$1$2-

The problem with this, is that this removed the whole body of the mail except 
for the -BEGIN PGP MESSAGE- line.

What are im doing wrong? I have tried with different flags like /s or /si and 
such, but still it removes the whole body.
I want it to scan line for line and process it.

smime.p7s
Description: S/MIME Cryptographic Signature


RE: Check NS (name or IP) against RBL

2015-09-11 Thread Marius Gologan
Thank you Wietse and Viktor.

I know check_{sender,helo,client}_{ns,mx}_access files and played a bit with
them, but I already run a granular RBL service.
Unfortunately I'm not winning the game with some type of spam sent
repeatedly during night time using: 
IPs from class B, multiple domains, unique content, no URLs, but common
private name servers (for now).
No bounces, sending is extremely slow, no other RBLs are listing the sources
in due time.

A policy is much better for my scope: keep volume under dynamic limits in a
cache db for the above resources not matching the pattern of large ESPs.

Marius.


-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema
Sent: Friday, September 11, 2015 3:52 PM
To: Postfix users
Subject: Re: Check NS (name or IP) against RBL

Marius Gologan:
> Thank you. I will go with central RBL service  and a policy service
script.
> 

FYI, check_sender_ns_access does not require a policy server.

Wietse
> 
> -Original Message-
> From: "Wietse Venema" 
> Sent: ?9/?11/?2015 2:15 AM
> To: "postfix-users@postfix.org" 
> Subject: Re: Check NS (name or IP) against RBL
> 
> Viktor Dukhovni:
> > On Fri, Sep 11, 2015 at 12:25:56AM +0300, Marius Gologan wrote:
> > 
> > > Is there any way to check the name server (name and/or IP) of the 
> > > Sender domain against RBL service?
> > 
> > Only via a policy service that does the relevant DNS lookups.
> 
> I have used check_sender_ns_access to block persistent spammers.
> There are also check_sender_mx_access, and similar features for 
> client, helo, recipient.
> 
>   Wietse


smime.p7s
Description: S/MIME cryptographic signature


Re: add a recipient in a policy daemon

2015-09-11 Thread Wietse Venema
Ram:
> On 09/11/2015 08:01 PM, Wietse Venema wrote:
> > Ram:
> >> How can I add a bcc recipient using a policy daemon
> >>
> >> I have written a custom policy daemon , and the logic requires that for
> >> some conditions  the mail needs to be bcc'ed to a program
> >>
> >> Can this be done ?
> > Postfix 3.0 and later:
> >
> > BCC user@domain
> >Send one copy of the message to the specified recipient.
> So can I write in my perl policy filter something like
> 
> if($condition) {
>print STDOUT "bcc scr...@domain.com";
> }

Almost. See http://www.postfix.org/SMTPD_POLICY_README.html#protocol
for the expected reply syntax (there is an example at the end of
this section).

Wietse


Re: add a recipient in a policy daemon

2015-09-11 Thread Ram



On 09/11/2015 08:01 PM, Wietse Venema wrote:

Ram:

How can I add a bcc recipient using a policy daemon

I have written a custom policy daemon , and the logic requires that for
some conditions  the mail needs to be bcc'ed to a program

Can this be done ?

Postfix 3.0 and later:

BCC user@domain
   Send one copy of the message to the specified recipient.

So can I write in my perl policy filter something like

if($condition) {
  print STDOUT "bcc scr...@domain.com";
}




Re: add a recipient in a policy daemon

2015-09-11 Thread Wietse Venema
Ram:
> How can I add a bcc recipient using a policy daemon
> 
> I have written a custom policy daemon , and the logic requires that for 
> some conditions  the mail needs to be bcc'ed to a program
> 
> Can this be done ?

Postfix 3.0 and later:

   BCC user@domain
  Send one copy of the message to the specified recipient.

  If multiple BCC actions are specified within the same SMTP  MAIL
  transaction, only the last action will be used.

  This feature is available in Postfix 3.0 and later.

Postfix does not implement "mail to program" recipients, as that
would be a security hole. Instead, use transport_maps and a pipe(8)
daemon entry in master.cf.

/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport:
u...@example.comcommand:

/etc/postfix/master.cf:
command ... ... ... ... ... ... pipe
user=xxx argv=/path/to/file ...

or execute the command from a $HOME/.forward file or /etc/aliases file.

Wietse


Re: Dynamic 'myhostname'

2015-09-11 Thread Mick

Hi Christian,


Hi Wietse,

I only have 1 IP address (2 if you count the IPv6 address).  A reverse
DNS lookup will always find my primary domain so even if I used
'sender_dependent_default_transport' and set up multiple switches just
to change HELO name, they still have to point to the same IP.  If
reverse DNS was then carried out, secondary domain provided in the HELO

would not match and mail could be rejected. Think I'm stuffed without
additional IPv4s, but at least I know why.

Your setup should work. I have a similar setup with 5 domains of which the one 
that holds the helo-name of my Mailserver is not my primary maildomain... and 
that works well with spf dkim and dmarc.

When searching for your error message it seems that maybe your envelope and 
from aren't aligned, this could be checked on spf test websites that analyse 
your setup after you send them an email to a special one-time address.


Thank you very much indeed for your help. As a result I re-checked my 
configuration and found you were spot on, the culprit being postsrsd. 
The very thing I added to allow forwarding without breaking SPF / DMARC  
appends the From field to the primary domain regardless of the domain 
the message comes from. I've withdrawn postsrsd for now while I look 
into a possibility of work around or something to replace it.





Have you had a look at the spf rfc 7208?


Yes. It's a good document. I'm more a pragmatist than theorist so always 
appreciate examples which rfc7208 provides plenty.



Best regards,

Mick.




Regards
Christian



Thanks for your advice.

Mick.



Wietse







add a recipient in a policy daemon

2015-09-11 Thread Ram

How can I add a bcc recipient using a policy daemon

I have written a custom policy daemon , and the logic requires that for 
some conditions  the mail needs to be bcc'ed to a program


Can this be done ?

Thanks
Ram



Re: ASPL: discarding a single recipient or a set of them from a multi-recipient message

2015-09-11 Thread Wietse Venema

You could use virtual_alias_maps to rewrite the envelope recipient
to a bit-bucket address (virtual aliases take effect unless you
specify alias expansion with receive_override_options).

Either way, the sender-dependent delivery agent would need to be
able to deliver the bit-bucket address to a destination that 
always accepts it.

Wietse


Re: Check NS (name or IP) against RBL

2015-09-11 Thread Wietse Venema
Marius Gologan:
> Thank you. I will go with central RBL service  and a policy service script.
> 

FYI, check_sender_ns_access does not require a policy server.

Wietse
> 
> -Original Message-
> From: "Wietse Venema" 
> Sent: ?9/?11/?2015 2:15 AM
> To: "postfix-users@postfix.org" 
> Subject: Re: Check NS (name or IP) against RBL
> 
> Viktor Dukhovni:
> > On Fri, Sep 11, 2015 at 12:25:56AM +0300, Marius Gologan wrote:
> > 
> > > Is there any way to check the name server (name and/or IP) of the Sender
> > > domain against RBL service?
> > 
> > Only via a policy service that does the relevant DNS lookups.
> 
> I have used check_sender_ns_access to block persistent spammers.
> There are also check_sender_mx_access, and similar features for
> client, helo, recipient.
> 
>   Wietse


RE: Check NS (name or IP) against RBL

2015-09-11 Thread Marius Gologan
Thank you. I will go with central RBL service  and a policy service script.

Sent from phone

-Original Message-
From: "Wietse Venema" 
Sent: ‎9/‎11/‎2015 2:15 AM
To: "postfix-users@postfix.org" 
Subject: Re: Check NS (name or IP) against RBL

Viktor Dukhovni:
> On Fri, Sep 11, 2015 at 12:25:56AM +0300, Marius Gologan wrote:
> 
> > Is there any way to check the name server (name and/or IP) of the Sender
> > domain against RBL service?
> 
> Only via a policy service that does the relevant DNS lookups.

I have used check_sender_ns_access to block persistent spammers.
There are also check_sender_mx_access, and similar features for
client, helo, recipient.

Wietse


Re: ASPL: discarding a single recipient or a set of them from a multi-recipient message

2015-09-11 Thread Francis Brosnan Blázquez
Hi Viktor,

> > Yes, but this doesn't work if you need to adjust outgoing IP based on
> > the sasl user (published solutions insist on using FILTER :-( [1])
> 
> Then perhaps we should provide a way of doing the same thing by
> SASL login.  Both the envelope address and the SASL login name are
> really features of the sender.  The original purpose of the feature
> (in the form of a sender dependent relay host) was to allow users
> to relay mail through the right email provider that hosts the
> mailbox for the sender address, and might have DKIM, SPF, ...
> 
> I don't think that we're going out of our way to facilitate snow-show
> bulk-email (possibly legitimate, and just dealing with real obstacles,
> or at times trying to flying under the radar with less legitimate
> content).
> 
> So there's a limit to how much effort in that direction is likely
> in the mainstream Postfix distribution.
> 
> What are the legitimate use-cases for transport for SASL id?

Ok, before explaining the use case, I would like to recall why this
thread was started: to have the possibility to selectively discard
recipients in a multi-recipient message. 

However, after sharing with you both the case, and reviewing the issue,
we are starting to consider the problem not as such, but as a limitation
which is somehow caused/activated by the way the email agent is sending
content and, more over, and possibly, more important, sending content to
accounts that will cause us problems (RBLs), which is something we
cannot accept (obviously).

Having said that, the use case follows. 

What we have now is a good balance where users are grouped into
different outgoing IP, so we can reduce the impact of a compromised
accounts ([1]), and at the same time we don't have to deal with
different combinations of sender+sasl-user ([1]) so we do the routing
using the SASL identifer,

Even though mail sending is controlled by quotas and we also implement
sender login mismatch (sasl identifier must much sender account),
there's a set of "users" that have exceptions (for the complexity and
commercial reasons), but not spammers (unless they got compromised, of
course).

Given all this, the big likelihood this can be used for bad things(tm)
and the fact that, even implemented, we will not be able to take
advantage of it in the short term, the reasonable conclusion for us is
that we have to work out the problem by other means (which may include
users' reeducation :-)

> > > Postfix is not a one-stop-shopping solution for a snow-shoe spam
> > > MTA.  Removing pesky recipients like me who'll report the sender
> > > to RBL maintainers and abuse departments needs to happen in the
> > > upstream lists, not in the MTA.  Turn-away customers with harvested
> > > lists, or you'll find your outbound IPs on RBLs.
> > 
> > :-) Hehe...I'd really like to (turn away those customers), but daily
> > life reality is far from there...
> > 
> > Anyway, certainly, that "FILTER" for transport selection we are doing is
> > very disruptive (according to postfix way of doing things). I'll take me
> > time to review this, 
> > 
> > [1] http://comments.gmane.org/gmane.mail.postfix.user/250046
> 
> Well, that works provided you don't also try to do any interesting
> per-recipient routing (e.g. routing to discard(8)).
> 
> There isn't at present a "DEFAULT ..." access(5) directive that
> instead of "FILTER", which preempts routing, sets the default
> transport.  This would have to write a new record into the queue-file
> that the queue-manager would then convey to trivial-rewrite(8) in
> the "resolve" protocol request (which would need to change), so
> that trivial-rewrite would return the per-message default transport.

Ok,

> Can't estimate the likelihood of this becoming an official feature.

Looks reasonable to me,

Thanks for all clarifications and comments Viktor, 
Best Regards,

[1] The amount of users that care about its box, do not use wifi
connections that shouldn't be used, do not install unrecommended
software (thus compromising his/her equipment) and do not configure
fancy combinations of my-yahoo-account+sasl_user_of_my_isp is function
that nearly approximates to 0


-- 
Francis Brosnan Blázquez 
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL
 
En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL).
 
ASPL garantiza que los datos serán tratados con la finalidad de mantener
las oportunas relaciones comerciales o promocionales con usted o la
entidad que usted representa. No obstante, usted puede ejercitar sus
derechos de acceso, rectificación, cancelación y oposición dispuestos en
la mencionada Ley Orgánica, notificándolo por escrito a ASPL -
Protección Datos, C/Ant