virtual_alias_maps question

[Louis-David Mitterrand]

Hi, 

I have a virtual_alias_maps with a pcre entry like 

/^(info|contact|etc)@/ localuser

and it delivers i...@anydomain.com to localuser even though
'anydomain.com' is not in virtual_alias_domains, is that normal?

Re: virtual_alias_maps question

[Ralf Hildebrandt]

* Louis-David Mitterrand :
> Hi, 
> 
> I have a virtual_alias_maps with a pcre entry like 
> 
>   /^(info|contact|etc)@/ localuser
> 
> and it delivers i...@anydomain.com to localuser even though
> 'anydomain.com' is not in virtual_alias_domains, is that normal?

Yes.

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
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

Re: virtual_alias_maps question

[Louis-David Mitterrand]

On Thu, Oct 24, 2013 at 10:42:07AM +0200, Ralf Hildebrandt wrote:
> * Louis-David Mitterrand :
> > Hi, 
> > 
> > I have a virtual_alias_maps with a pcre entry like 
> > 
> > /^(info|contact|etc)@/ localuser
> > 
> > and it delivers i...@anydomain.com to localuser even though
> > 'anydomain.com' is not in virtual_alias_domains, is that normal?
> 
> Yes.

So I have to write (and maintain) that entry like this?

/^(info|contact|etc)@(domain1|domain2|domain3|etc).com$/ localuser

Is there a better way?

Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[Patrick Lists]

On 10/23/2013 10:57 PM, Viktor Dukhovni wrote:
[snip]

The problem turns out to be that RedHat's patch did not prune the
list of curves advertised by the TLS client!  They're going to
update the code to only advertise secp{256,384}r1, which will make
connections to gmx.de work again (but without EECDH).


Apologies if this is too OT but did Paul mention why they are ripping 
out curves?


Regards,
Patrick

Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[li...@rhsoft.net]

Am 24.10.2013 11:11, schrieb Patrick Lists:
> On 10/23/2013 10:57 PM, Viktor Dukhovni wrote:
> [snip]
>> The problem turns out to be that RedHat's patch did not prune the
>> list of curves advertised by the TLS client!  They're going to
>> update the code to only advertise secp{256,384}r1, which will make
>> connections to gmx.de work again (but without EECDH).
> 
> Apologies if this is too OT but did Paul mention why they are ripping out 
> curves?

if you look at the history of the 6 years standing original bugreport
clearly because patent trolls and the fact Redhat is a US company

https://bugzilla.redhat.com/show_bug.cgi?id=319901
https://bugzilla.redhat.com/show_bug.cgi?id=319901#c17

Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[Patrick Lists]

On 10/24/2013 11:15 AM, li...@rhsoft.net wrote:


Am 24.10.2013 11:11, schrieb Patrick Lists:

On 10/23/2013 10:57 PM, Viktor Dukhovni wrote:
[snip]

The problem turns out to be that RedHat's patch did not prune the
list of curves advertised by the TLS client!  They're going to
update the code to only advertise secp{256,384}r1, which will make
connections to gmx.de work again (but without EECDH).


Apologies if this is too OT but did Paul mention why they are ripping out 
curves?


if you look at the history of the 6 years standing original bugreport
clearly because patent trolls and the fact Redhat is a US company

https://bugzilla.redhat.com/show_bug.cgi?id=319901
https://bugzilla.redhat.com/show_bug.cgi?id=319901#c17


Thanks you.

Regards,
Patrick

Re: virtual_alias_maps question

[Ralf Hildebrandt]

* Louis-David Mitterrand :
> On Thu, Oct 24, 2013 at 10:42:07AM +0200, Ralf Hildebrandt wrote:
> > * Louis-David Mitterrand :
> > > Hi, 
> > > 
> > > I have a virtual_alias_maps with a pcre entry like 
> > > 
> > >   /^(info|contact|etc)@/ localuser
> > > 
> > > and it delivers i...@anydomain.com to localuser even though
> > > 'anydomain.com' is not in virtual_alias_domains, is that normal?
> > 
> > Yes.
> 
> So I have to write (and maintain) that entry like this?
> 
>   /^(info|contact|etc)@(domain1|domain2|domain3|etc).com$/ localuser
> 
> Is there a better way?

That's the only way. Otherwise it would rewrite the address for all
domains, even non-local ones.

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
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

Re: default_milter_action

[Wietse Venema]

Roland de Lepper:
> Hi ,
> 
> The connection between Postfix and the archive is over SMTP.
> 
> In my example with the smtpd_milter, will the email also go to the hold
> queue if only one archive connection is down?

That depends on how the archive receive its mail. Does POSTFIX
send the mail to the archive, or the MILTER?

Wietse

Re: virtual_alias_maps question

[Wietse Venema]

Louis-David Mitterrand:
> Hi, 
> 
> I have a virtual_alias_maps with a pcre entry like 
> 
>   /^(info|contact|etc)@/ localuser
> 
> and it delivers i...@anydomain.com to localuser even though
> 'anydomain.com' is not in virtual_alias_domains, is that normal?

RTFM:

NAME
   virtual - Postfix virtual alias table format
DESCRIPTION
   The  optional  virtual(5)  alias table rewrites recipient addresses FOR
   ALL LOCAL, ALL VIRTUAL, AND ALL  REMOTE  MAIL  DESTINATIONS.   This  is


Wietse

Re: disable ipv6 when sending to gmail ?

[Mark Martinec]

Dominik George wrote:
> if i would be you i would *not* use "v=spf1 mx ~all"
> here you go for ipv6
>
> > http://www.openspf.org/SPF_Record_Syntax#ip6
>
> Jeez, I don't believe it. The problem is that the mx mechanism simply
> only enumerates A records of MXs. That's broken ...

Wietse wrote:
> That's retarded. I wonder how many sites have been bitten by that bug.

Joni wrote:
> The only place I've seen this problem with the lookup of IPv6 addresses via
> the 'mx' construct in SPF records was Gmail, which was resolved, and
> recently some small local operator who kept insisting that the problem was
> on our side until the evidence was so overwhelmingly pointing to his own
> setup that he could no longer ignore it.
> 
> He made the same claim, however, but never backed it up. How are you
> reaching your conclusion?
> 
> Because this only mentions A records and IPv4 prefixes?
> http://www.openspf.org/SPF_Record_Syntax#mx

That http://www.openspf.org/SPF_Record_Syntax wiki page is wrong,
or misleading in the least.


The SPF specification in RFC 4408 does not fall into this trap,
it talks about a (generic)  address.

Some excerpts from  RFC 4408:


  When any mechanism fetches host addresses to compare with , when
   is an IPv4 address, A records are fetched, when  is an IPv6
  address,  records are fetched.

5.3.  "a"
   This mechanism matches if  is one of the 's IP
   addresses.
 A= "a"  [ ":" domain-spec ] [ dual-cidr-length ]
   An address lookup is done on the .  The  is compared
   to the returned address(es).  If any address matches, the mechanism
   matches.

5.4.  "mx"

   This mechanism matches if  is one of the MX hosts for a domain
   name.
 MX   = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
   check_host() first performs an MX lookup on the .  Then
   it performs an address lookup on each MX name returned.  The  is
   compared to each returned IP address.  [...]

dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]


  Mark

Re: default_milter_action

[Wietse Venema]

Roland de Lepper:
> The connection between Postfix and the archive is over SMTP.
>
> In my example with the smtpd_milter, will the email also go to the hold
> queue if only one archive connection is down?

Wietse:
> That depends on how the archive receive its mail. Does POSTFIX
> send the mail to the archive, or the MILTER?

Roland de Lepper:
> As stated in the manual of mailarchiva, it says:
> MailArchiva has an embedded Milter server that by default listens on port
> 8092. The instructions below configure Postfix to forward milter traffic to
> MailArchiva's milter server.
> 
> So the MILTER sends the mail to the archive.

In that case, to archive all mail you need "milter_default_action
= tempfail". Since the Milter is a before-queue filter, Mail cannot
be delivered while the archive is unavailable.

If you want to deliver mail while the archive is down, use an
after-queue filtering approach, or an approach based on sender_bcc_maps
or recipient_bcc_maps.

Wietse

If the MILTER sends to the archive (I cannot verify that), then no
mail will be archived when the MILTER is unavailable.

Specifically:

1) With "milter_default_action = tempfail" mail is not archived
when the Milter or archive is unavailable.  Mail is not delivered
to the recipient(s). The remote SMTP client receives a 4XX SMTP
reply code. The remote SMTP client retries until the MILTER becomes
available or until the mail is too old.

2) With "milter_default_action = accept" mail is not archived when
the Milter or archive is unavailable.  Mail is delivered to the
recipient(s). The remote SMTP client receives a 2XX SMTP reply code.

3) With "milter_default_action = quarantine" mail is not archived
when the Milter or archive is unavailable.  Mail is stored in the
"hold" queue. The remote SMTP client receives a 2XX SMTP reply code.
Obviously this option is the worst of all.

Wietse

Re: default_milter_action

[Tom Hendrikx]

On 10/24/2013 08:39 AM, Roland de Lepper wrote:
> Hi ,
> 
> The connection between Postfix and the archive is over SMTP.
> 
> In my example with the smtpd_milter, will the email also go to the hold
> queue if only one archive connection is down?
> Or will it deliver the email to the archive which is online? This is an
> important question for me, to get both in sync.

Your config shows that you have 2 milter instances, delivering to both
archive backends. If one of them fails, the other can still succeed
since the milters don't communicate. Only postfix sees the final result
but it on't the milterA that milterB had a failure.

So, if you want to be sure that every mail is always sent to both
backends (i.e. consistency), you need to a single milter that talks to
both backends, and should be able to inform a backend to 'undo' the
store action on backendA when backendB is failing, and vice versa.


Tom

> 
> If the emails will go in the HOLD queue, that is not really a problem for
> me. Our monitoring will scream within a few minutes, the mailq is too big
> and the connection to the archive is down. This way we are noticed to take
> action, keep the emails on HOLD till the problem is solved with the archive
> or take another action if the problem is severe and take too long too
> solve. We can always copy the data from one archive to another.
> This again raise the question if the emails will go to the HOLD queue too
> if one archive is down.
> 
> regards,
> 
> Roland
> 
> 
> On Wed, Oct 23, 2013 at 4:02 PM, Wietse Venema  wrote:
> 
>> Roland de Lepper:
>>> Hi Wietse,
>>>
>>> Thanks for the reply.
>>>
>>> What about milter_default_action = quarantine  ?
>>
>> As documented, this leaves the message in the "hold" queue.  If the
>> Milter should have done something with the message, then those
>> things will never happen. The message is now in the queue, and the
>> Milter is a before-queue feature.
>>
>> If I may ask, is the archive connected over SMTP or over a
>> propietary protocol?
>>
>> I think that "defer accepting mail while the archive is down" is
>> the safest option (i.e. leave it up to the sender to retry).
>> Everything else requires that the message is queued in Postfix while
>> the archive is down, for example as in this simplified picture:
>>
>> network -> smtpd -> queue -> smtp -> smtpd+milter -> queue -> delivery
>> agents
>>
>> The part with "smtp -> smtpd+milter:  would implement an SMTP-based
>> empty after-queue filter.
>>
>> Wietse
>>
>>> regards,
>>>
>>> Roland de Lepper
>>>
>>>
>>> On Wed, Oct 23, 2013 at 1:24 PM, Wietse Venema 
>> wrote:
>>>
 Roland de Lepper:
> smtpd_milters = inet:81.x.x.x:8092 inet:217.x.x.x:8092
> milter_default_action = tempfail
> milter_connect_timeout = 10s
>
> This works perfectly without any problems. the question raised, what
>> if
 the
> connection between the mailserver and location B is down. Is the
>> email

 As documented no mail is delivered after Milter failure. The Postfix
 SMTP server will reply with an error status code (4xx) and the
 client will have to send the message again.

 The bad alternative is "milter_default_action = accept", which means
 that mail will be delivered but not archived.

 If you want both mail delivered AND mail archived, then you need
 to use sender_bcc_maps or recipient_bcc_maps to add recipients for
 archival purposes.

 Then, Postfix will do the retrying until the message is too old,
 at which time it will be returned to the sender.

 Wietse

>>
> 




signature.asc
Description: OpenPGP digital signature

Re: TLS: Certificate signature failure -- what is the reason?

[Viktor Dukhovni]

On Thu, Oct 24, 2013 at 07:59:46AM +0200, Tobias Reckhard wrote:

> >  Support for public key fingerprints was added in Postfix 2.9, ...
> 
> This is stated at the beginning of the section dealing with
> fingerprints. Further down, where the actual openssl commands are noted,
> there is no such note. I'm not saying there should be one there, but had
> there been one, I probably wouldn't have picked the wrong set of commands.

I'll keep that in mind for the next documentation review.  You can
submit documentation patches (as I was recently reminded, after
passing the final documents through an HTML validator).

> >> [...] certificate fingerprint [...] and public-key fingerprints being
> >> [...] mutually exclusive.
> > 
> > They are not mutually exclusive.
> 
> Ah, OK, thanks for the clarification.

That is a "match=..." attribute in a tls policy table fingerprint
entry will match either the peer public key or the peer certificate.

Assuming that 2nd-preimage attacks on your digest function are
computationally infeasible (still true IIRC even for md5), there
is no risk of confusion.  An attacker should not be able to
independently construct a certificate with the same digest as a
given public key or a public key with the same digest as a given
certificate.  All known collision attacks against md5 are I believe
extension attacks where two messages are built with a common prefix.

-- 
Viktor.

Re: virtual_alias_maps question

[/dev/rob0]

On Thu, Oct 24, 2013 at 10:49:43AM +0200, Louis-David Mitterrand 
   wrote:
> On Thu, Oct 24, 2013 at 10:42:07AM +0200, Ralf Hildebrandt wrote:
> > * Louis-David Mitterrand 
> > :
> > > I have a virtual_alias_maps with a pcre entry like 
> > > 
> > >   /^(info|contact|etc)@/ localuser
> > > 
> > > and it delivers i...@anydomain.com to localuser even though 
> > > 'anydomain.com' is not in virtual_alias_domains, is that 
> > > normal?
> > 
> > Yes.
> 
> So I have to write (and maintain) that entry like this?
> 
>   /^(info|contact|etc)@(domain1|domain2|domain3|etc).com$/ localuser
> 
> Is there a better way?

Nested, if/endif:

if /@example\.(com|net|org)$/
/^(info|contact|etc)@   localuser@mydestination.domain
endif

Change your "if" line when adding more domains.

This can probably be done better with SQL tricks rather than PCRE, 
BTW. Not worth changing to SQL if you're not already using it, of 
course.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: virtual_alias_maps question

[Viktor Dukhovni]

On Thu, Oct 24, 2013 at 10:00:00AM -0500, /dev/rob0 wrote:

> > Is there a better way?
> 
> Nested, if/endif:
> 
> if /@example\.(com|net|org)$/
> /^(info|contact|etc)@ localuser@mydestination.domain
> endif

This is all silly, the list of virtual alias domains is known, use
a Makefile to generate the boiler-plate aliases.

-- 
Viktor.

Re: virtual_alias_maps question

[/dev/rob0]

On Thu, Oct 24, 2013 at 10:00:00AM -0500, /dev/rob0 forgot to
terminate a PCRE expression:
> if /@example\.(com|net|org)$/
> /^(info|contact|etc)@ localuser@mydestination.domain
> endif

if /@example\.(com|net|org)$/
/^(info|contact|etc)@/  localuser@mydestination.domain
endif
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: virtual_alias_maps question

[Louis-David Mitterrand]

On Thu, Oct 24, 2013 at 10:04:08AM -0500, /dev/rob0 wrote:
> On Thu, Oct 24, 2013 at 10:00:00AM -0500, /dev/rob0 forgot to
> terminate a PCRE expression:
> > if /@example\.(com|net|org)$/
> > /^(info|contact|etc)@   localuser@mydestination.domain
> > endif
> 
> if /@example\.(com|net|org)$/
> /^(info|contact|etc)@/localuser@mydestination.domain
> endif

This is really, really nice. I always forget the power of if/endif in
posfix confs.

Thanks!

Distant server to test SMTP TLS ?

[BONNET, Frank]

Hello

Continuing on my "secured" email server graal I would like to test SMTP +
TLS exchange of emails

the volume will be very low for testing purpose only and I will be the only
user when I will suceeded to setup my server :-)

My eternal gratitude If anyone knows such server that could be used for
that purpose  ,

thanks you for your help

Re: Distant server to test SMTP TLS ?

[Sebastian Wiesinger]

* BONNET, Frank  [2013-10-24 17:54]:
> Hello
> 
> Continuing on my "secured" email server graal I would like to test SMTP +
> TLS exchange of emails
> 
> the volume will be very low for testing purpose only and I will be the only
> user when I will suceeded to setup my server :-)
> 
> My eternal gratitude If anyone knows such server that could be used for
> that purpose  ,

Hi,

almost every bigger email provider is using TLS. Get yourself a gmail
address for example and test with the gmail mailservers.

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant

Re: Distant server to test SMTP TLS ?

[Frank BONNET]

ok thanks for the tips

Envoyé de mon iPhone.


Le 24 oct. 2013 à 18:02, Sebastian Wiesinger
 a écrit :

> * BONNET, Frank  [2013-10-24 17:54]:
>> Hello
>>
>> Continuing on my "secured" email server graal I would like to test SMTP +
>> TLS exchange of emails
>>
>> the volume will be very low for testing purpose only and I will be the only
>> user when I will suceeded to setup my server :-)
>>
>> My eternal gratitude If anyone knows such server that could be used for
>> that purpose  ,
>
> Hi,
>
> almost every bigger email provider is using TLS. Get yourself a gmail
> address for example and test with the gmail mailservers.
>
> Regards
>
> Sebastian
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE 
> SCYTHE.
>-- Terry Pratchett, The Fifth Elephant

Re: default_milter_action

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Roland,

My proposed solution was a milter that runs locally on the postfix
box, and communicates with both archive boxes so the milter is able to
act on errors in both archive boxes. I did some reading on the
product, and it seems that the milter interface is part of the archive
solution, and even runs the milter interface on the archive box itself.

Anyway, that makes my advice obsolete. You should llok into non-milter
solutions if you need to get both backends synchronized. The
mailarchiva help has some nice alternatives for that. The High
Availability section describes some interesting features.

Tom

On 24-10-13 14:43, Roland de Lepper wrote:
> Hi Tom,
> 
> Thanks for your answer, but unfortunatly, that's not possible
> because the MILTER sends the email to the archive. With only one
> MILTER, both archive server must have the same Ip-address. Or do I
> mis something?
> 
> Roland
> 
> 
> On Thu, Oct 24, 2013 at 2:37 PM, Tom Hendrikx  > wrote:
> 
> On 10/24/2013 08:39 AM, Roland de Lepper wrote:
>> Hi ,
>> 
>> The connection between Postfix and the archive is over SMTP.
>> 
>> In my example with the smtpd_milter, will the email also go to
>> the
> hold
>> queue if only one archive connection is down? Or will it deliver
>> the email to the archive which is online? This
> is an
>> important question for me, to get both in sync.
> 
> Your config shows that you have 2 milter instances, delivering to
> both archive backends. If one of them fails, the other can still
> succeed since the milters don't communicate. Only postfix sees the
> final result but it on't the milterA that milterB had a failure.
> 
> So, if you want to be sure that every mail is always sent to both 
> backends (i.e. consistency), you need to a single milter that talks
> to both backends, and should be able to inform a backend to 'undo'
> the store action on backendA when backendB is failing, and vice
> versa.
> 
> 
> Tom
> 
>> 
>> If the emails will go in the HOLD queue, that is not really a
> problem for
>> me. Our monitoring will scream within a few minutes, the mailq
>> is
> too big
>> and the connection to the archive is down. This way we are
>> noticed
> to take
>> action, keep the emails on HOLD till the problem is solved with
> the archive
>> or take another action if the problem is severe and take too long
>> too solve. We can always copy the data from one archive to
>> another. This again raise the question if the emails will go to
>> the HOLD
> queue too
>> if one archive is down.
>> 
>> regards,
>> 
>> Roland
>> 
>> 
>> On Wed, Oct 23, 2013 at 4:02 PM, Wietse Venema
> mailto:wie...@porcupine.org>> wrote:
>> 
>>> Roland de Lepper:
 Hi Wietse,
 
 Thanks for the reply.
 
 What about milter_default_action = quarantine  ?
>>> 
>>> As documented, this leaves the message in the "hold" queue.  If
>>> the Milter should have done something with the message, then
>>> those things will never happen. The message is now in the
>>> queue, and the Milter is a before-queue feature.
>>> 
>>> If I may ask, is the archive connected over SMTP or over a 
>>> propietary protocol?
>>> 
>>> I think that "defer accepting mail while the archive is down"
>>> is the safest option (i.e. leave it up to the sender to
>>> retry). Everything else requires that the message is queued in
>>> Postfix while the archive is down, for example as in this
>>> simplified picture:
>>> 
>>> network -> smtpd -> queue -> smtp -> smtpd+milter -> queue ->
> delivery
>>> agents
>>> 
>>> The part with "smtp -> smtpd+milter:  would implement an
>>> SMTP-based empty after-queue filter.
>>> 
>>> Wietse
>>> 
 regards,
 
 Roland de Lepper
 
 
 On Wed, Oct 23, 2013 at 1:24 PM, Wietse Venema
> mailto:wie...@porcupine.org>>
>>> wrote:
 
> Roland de Lepper:
>> smtpd_milters = inet:81.x.x.x:8092 inet:217.x.x.x:8092 
>> milter_default_action = tempfail milter_connect_timeout =
>> 10s
>> 
>> This works perfectly without any problems. the question
> raised, what
>>> if
> the
>> connection between the mailserver and location B is down.
>> Is the
>>> email
> 
> As documented no mail is delivered after Milter failure.
> The
> Postfix
> SMTP server will reply with an error status code (4xx) and
> the client will have to send the message again.
> 
> The bad alternative is "milter_default_action = accept",
> which
> means
> that mail will be delivered but not archived.
> 
> If you want both mail delivered AND mail archived, then you
> need to use sender_bcc_maps or recipient_bcc_maps to add
> recipients for archival purposes.
> 
> Then, Postfix will do the retrying until the message is too
> old, at which time it will be returned to the sender.
> 
> Wietse
> 
>>> 
>> 
> 
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG

Re: rewrite sender address when recipient is non "local"

[btb]

On 2013.10.22 09.56, Noel Jones wrote:

On 10/22/2013 8:41 AM, btb wrote:

On 2013.10.21 17.54, Noel Jones wrote:

On 10/21/2013 3:53 PM, btb wrote:

i have a scenario in which certain email is sent using envelope
senders that contain host names that are known only on the local
lan/network, and unknown on the internet.  most mail expressing that
characteristic stays local, but occasionally, some is legitimately
destined for the public internet.  to that end, with such mail, i'd
like to change the sender domain part to @example.com, but only if
the recipient domain part does not end in example.com [both the
sender and recipient domain part may be @example.com,
@foo.example.com, @bar.foo.example.com, etc].

what is the right method for doing this?  given
ADDRESS_REWRITING_README, it seem to possibly be a fit for either
masquerade_domains or smtp_generic_maps, but i'm not certain, and
i'm not sure how to apply selectively.

-ben


smtp_generic_maps will do that nicely. Add the rewriting on the
"smtp" outgoing transport in master.cf to limit rewriting to
non-local recipient domains only.

#master.cf
# find the existing "smtp unix ... smtp" transport and add to it:
-o smtp_generic_maps=regexp:/etc/postfix/generic.regexp


# generic.regexp
/^(.*)@some\.fantasy\.invalid$/  $1...@example.com


thanks.  wrt limit rewriting to non-local recipient domains only, by "stays 
local", i meant local in terms of the local network, not in terms of postfix.  
postfix is responsible for only systems.example.com:

virtual_mailbox_domains = ldap:$table_directory/virtual_mailbox_domains.cf


postmap -q 'systems.example.com' ldap:./tables/virtual_mailbox_domains.cf

systems.example.com

while everything else leaves via smtp and is delivered via mx records - some of 
which is for other recipients ending in @example.com or .example.com [delivered 
to other hosts on the local network], and the rest of course out onto the 
internet.  how can i apply smtp_generic_maps selectively, for only certain 
recipient domains [ones not ending in @example.com or .example.com] leaving via 
smtp - the goal being to rewrite the sender to @example.com for mail destined 
for the internet?

-ben



Postfix doesn't have a specific feature to rewrite the sender based
on the recipient.

Arrange for internal network traffic to use a specific transport,
such as the "relay" transport, and let internet traffic use the
default "smtp" transport.


thanks for this guidance.  i have what [given my testing so far] appears 
to be a setup working as desired, but would appreciate any critiques or 
feedback wrt considerations i may have overlooked.


# transport used by mail leaving the local network
smtp  unix  -   -   -   -   -   smtp
-o smtp_helo_name=msa.example.com
-o smtp_generic_maps=regexp:$table_directory/generic.regexp

# transport used by mail not leaving the local network
example-internal  unix  -   -   -   -   -   smtp
-o syslog_name=postfix/example-internal

>cat transports
# handled by postfix virtual(8)
foo.example.com :
# valid/known on the internet
bar.example.com :

example.com example-internal:
.example.comexample-internal:

>cat generic.regexp
# rewrite everything that ends in .example.com, except bar.example.com
if !/^(.*)@bar\.example\.com$/
/^(.*)@.*\.example\.com$/  $1...@example.com
endif

-ben

Re: virtual_alias_maps question

[LuKreme]

On 24 Oct 2013, at 04:39 , Wietse Venema  wrote:

> Louis-David Mitterrand:
>> Hi, 
>> 
>> I have a virtual_alias_maps with a pcre entry like 
>> 
>>  /^(info|contact|etc)@/ localuser
>> 
>> and it delivers i...@anydomain.com to localuser even though
>> 'anydomain.com' is not in virtual_alias_domains, is that normal?
> 
> RTFM:
> 
> NAME
>   virtual - Postfix virtual alias table format
> DESCRIPTION
>   The  optional  virtual(5)  alias table rewrites recipient addresses FOR
>   ALL LOCAL, ALL VIRTUAL, AND ALL  REMOTE  MAIL  DESTINATIONS.   This  is

BTW, this is very useful.

My wife had used to email a bunch of different people at a edu domain, we'll 
call it fred.example.edu. These were not people that were in her address book 
or mail history, and she tyoped the domain nearly every time as 
ferd.example.edu.

Virtual to the rescue.

Something like this, IIRC.

#Rewrite ferd!
@ferd.example.edu   @fred.example.edu

-- 
I want to secede, but I don't know what state I'm in. - Bart Simpson, 2012

Re: rewrite sender address when recipient is non "local"

[Noel Jones]

On 10/24/2013 2:47 PM, btb wrote:
> On 2013.10.22 09.56, Noel Jones wrote:
>> On 10/22/2013 8:41 AM, btb wrote:
>>> On 2013.10.21 17.54, Noel Jones wrote:
 On 10/21/2013 3:53 PM, btb wrote:
> i have a scenario in which certain email is sent using envelope
> senders that contain host names that are known only on the local
> lan/network, and unknown on the internet.  most mail expressing
> that
> characteristic stays local, but occasionally, some is legitimately
> destined for the public internet.  to that end, with such mail,
> i'd
> like to change the sender domain part to @example.com, but only if
> the recipient domain part does not end in example.com [both the
> sender and recipient domain part may be @example.com,
> @foo.example.com, @bar.foo.example.com, etc].
>
> what is the right method for doing this?  given
> ADDRESS_REWRITING_README, it seem to possibly be a fit for either
> masquerade_domains or smtp_generic_maps, but i'm not certain, and
> i'm not sure how to apply selectively.
>
> -ben

 smtp_generic_maps will do that nicely. Add the rewriting on the
 "smtp" outgoing transport in master.cf to limit rewriting to
 non-local recipient domains only.

 #master.cf
 # find the existing "smtp unix ... smtp" transport and add to it:
 -o smtp_generic_maps=regexp:/etc/postfix/generic.regexp


 # generic.regexp
 /^(.*)@some\.fantasy\.invalid$/  $1...@example.com
>>>
>>> thanks.  wrt limit rewriting to non-local recipient domains only,
>>> by "stays local", i meant local in terms of the local network,
>>> not in terms of postfix.  postfix is responsible for only
>>> systems.example.com:
>>>
>>> virtual_mailbox_domains =
>>> ldap:$table_directory/virtual_mailbox_domains.cf
>>>
 postmap -q 'systems.example.com'
 ldap:./tables/virtual_mailbox_domains.cf
>>> systems.example.com
>>>
>>> while everything else leaves via smtp and is delivered via mx
>>> records - some of which is for other recipients ending in
>>> @example.com or .example.com [delivered to other hosts on the
>>> local network], and the rest of course out onto the internet. 
>>> how can i apply smtp_generic_maps selectively, for only certain
>>> recipient domains [ones not ending in @example.com or
>>> .example.com] leaving via smtp - the goal being to rewrite the
>>> sender to @example.com for mail destined for the internet?
>>>
>>> -ben
>>>
>>
>> Postfix doesn't have a specific feature to rewrite the sender based
>> on the recipient.
>>
>> Arrange for internal network traffic to use a specific transport,
>> such as the "relay" transport, and let internet traffic use the
>> default "smtp" transport.
> 
> thanks for this guidance.  i have what [given my testing so far]
> appears to be a setup working as desired, but would appreciate any
> critiques or feedback wrt considerations i may have overlooked.
> 
> # transport used by mail leaving the local network
> smtp  unix  -   -   -   -   -   smtp
> -o smtp_helo_name=msa.example.com
> -o smtp_generic_maps=regexp:$table_directory/generic.regexp
> 
> # transport used by mail not leaving the local network
> example-internal  unix  -   -   -   -   -  
> smtp
> -o syslog_name=postfix/example-internal
> 
>>cat transports
> # handled by postfix virtual(8)
> foo.example.com:
> # valid/known on the internet
> bar.example.com:
> 
> example.comexample-internal:
> .example.comexample-internal:
> 
>>cat generic.regexp
> # rewrite everything that ends in .example.com, except bar.example.com
> if !/^(.*)@bar\.example\.com$/
> /^(.*)@.*\.example\.com$/  $1...@example.com
> endif
> 
> -ben


I don't see any problems.



  -- Noel Jones

Relay Access Denied

[Tim Legg]

Hello,

I'm not tring to do virtual domains. Just trying to get it to work with just 
one domain. This time, I used this guide:

https://help.ubuntu.com/12.04/serverguide/postfix.html

I can telnet to my machine just fine on port 25.

I tried to send an e-mail from my address on mail.com to my own machine to test 
it out. It bounced. Below is the tail of my mail.log

postfix/smtpd[12344]: NOQUEUE: reject: RCPT from mout.gmx.net[74.208.4.201]: 
554 5.7.1 : Relay access denied; from= 
to= proto=ESMTP helo=
postfix/smtpd[12344]: disconnect from mout.gmx.net[74.208.4.201]

I read about this error on other forums, but I had no idea what they were 
talking about. I just need to do what needs to be done to make it work. 
Unfortunately, on Ubuntu, postfix doesn't seem to work out-of-the-box. I don't 
need to even relay mail, I just want my own incoming mail to be delivered. I 
don't get why this has to be so hard.

Tim Legg

Re: virtual_alias_maps question

[Jeroen Geilman]

On 10/24/2013 11:20 PM, LuKreme wrote:

On 24 Oct 2013, at 04:39 , Wietse Venema  wrote:


Louis-David Mitterrand:

Hi,

I have a virtual_alias_maps with a pcre entry like

/^(info|contact|etc)@/ localuser

and it delivers i...@anydomain.com to localuser even though
'anydomain.com' is not in virtual_alias_domains, is that normal?

RTFM:

NAME
   virtual - Postfix virtual alias table format
DESCRIPTION
   The  optional  virtual(5)  alias table rewrites recipient addresses FOR
   ALL LOCAL, ALL VIRTUAL, AND ALL  REMOTE  MAIL  DESTINATIONS.   This  is

BTW, this is very useful.

My wife had used to email a bunch of different people at a edu domain, we'll 
call it fred.example.edu. These were not people that were in her address book 
or mail history, and she tyoped the domain nearly every time as 
ferd.example.edu.

Virtual to the rescue.

Something like this, IIRC.

#Rewrite ferd!
@ferd.example.edu   @fred.example.edu



Note that this will not alter headers set by the MUA.

The recipient will still see the bad domain, and if you try to reply to 
a message where that was in the CC, it would bounce.


--
J.

Re: Relay Access Denied

[li...@rhsoft.net]

Am 25.10.2013 00:50, schrieb Tim Legg:
> I tried to send an e-mail from my address on mail.com to my own machine to 
> test it out. It bounced.  Below is the
> tail of my mail.log
>  
> postfix/smtpd[12344]: NOQUEUE: reject: RCPT from mout.gmx.net[74.208.4.201]: 
> 554 5.7.1 : Relay
> access denied; from= to= proto=ESMTP 
> helo=
> postfix/smtpd[12344]: disconnect from mout.gmx.net[74.208.4.201]
>  
> I read about this error on other forums, but I had no idea what they were 
> talking about.  I just need to do what
> needs to be done to make it work.  

output of "postconf -n" would be helpful

> Unfortunately, on Ubuntu, postfix doesn't seem to work out-of-the-box

it is impossible to work out of the box because without configuration
no MTA (not only) postfix knows what domains you are hosting nor how
to deliver messages to the mailboxes

Re: Relay Access Denied

[Wietse Venema]

Tim Legg:
> postfix/smtpd[12344]: NOQUEUE: reject: RCPT from
> mout.gmx.net[74.208.4.201]: 554 5.7.1 : Relay
> access denied; from= to=
> proto=ESMTP helo=
> postfix/smtpd[12344]: disconnect from mout.gmx.net[74.208.4.201]
> 
> I read about this error on other forums, but I had no idea what
> they were talking about. I just need to do what needs to be done
> to make it work. Unfortunately, on Ubuntu, postfix doesn't seem
> to work out-of-the-box. I don't need to even relay mail, I just
> want my own incoming mail to be delivered. I don't get why this
> has to be so hard.

*Someone* needs to tell Postfix that it should receive mail for
timothy.com. 

There is no way that Postfix will figure out that by itself.

http://www.postfix.org/BASIC_CONFIGURATION_README.html

Wietse