Forged MAIL FROM issue

[Alexandru Florescu]

Hello everybody.

I have a issue with postfix.

Consider the following scenario:

I telnet to my web server from another location (bar.com) and I start
executing commands.

 

Connected to foo.com.

Escape character is '^]'.

220 smtp1.foo.com ESMTP Postfix (GNU/Linux)

HELO bar.com

250 smtp1.foo.com

MAIL FROM: some...@gmail.com (mail must be valid)

250 2.1.0 Ok

RCPT TO:  a...@foo.com

250 2.1.5 Ok

DATA

354 End data with .

testing some kind of spam

.

250 2.0.0 Ok: queued as C7A602F7605

quit

221 2.0.0 Bye

 

Notes:

In this scenario, foo.com is my "real" mail server, bar.com is my "real"
testing server, some...@gmail.com is an example of an "existing" and valid
mail account and a...@foo.com is my "real" mail address.

 

The odd thing is that this actually works. I can connect and send mails
spoofing the sender's address, despite my postfix configuration directives:

permit_sasl_authenticated,

permit_mynetworks,

reject_unauth_destination,

reject_non_fqdn_hostname,

reject_invalid_hostname,

reject_unknown_recipient_domain,

 reject_unverified_recipient,

 reject_unknown_sender_domain,

 reject_invalid_helo_hostname,

 reject_non_fqdn_helo_hostname,

 reject_non_fqdn_sender,

 reject_unverified_sender,

 reject_unknown_sender_domain,

 reject_sender_login_mismatch,

 reject_unauth_pipelining,

 

Is some option missing? What can I do to prevent this? I found it because I
received spam in this way.

Using postfix 2.3.3 on Centos 5.4.

 

Thanks,

Alex F.

Re: Forged MAIL FROM issue

[Brian Evans - Postfix List]

On 1/13/2010 8:33 AM, Alexandru Florescu wrote:
>
> Hello everybody.
>
> I have a issue with postfix.
>
> Consider the following scenario:
>
> I telnet to my web server from *another location (bar.com)* and I
> start executing commands.
>
> Connected to */foo.com/.*
>
> Escape character is '^]'.
>
> 220 smtp1.foo.com ESMTP Postfix (GNU/Linux)
>
> *HELO /bar.com/*
>
> 250 smtp1.foo.com
>
> *MAIL FROM:/ some...@gmail.com /* (mail must
> be valid)
>
> 250 2.1.0 Ok
>
> *RCPT TO: a...@foo.com *
>
>
> Notes:
>
> In this scenario, _foo.com_ is my “real” mail server, _bar.com_ is my
> “real” testing server, _some...@gmail.com _
> is an example of an “existing” and valid mail account and
> _a...@foo.com _ is my “real” mail address.
>
>
> Is some option missing? What can I do to prevent this? I found it
> because I received spam in this way.
>
> Using postfix 2.3.3 on Centos 5.4.
>
>

Unless you wish to stop getting all email from the wild internet,
Postfix is doing just what it is supposed to do.
Various MTAs in the world will not know how to bypass any security you
set to deliver mail to you.

This scenario is a really job for a policy service, such as policyd or
policyd-weight, and/or spamassassin, via milter or amavis or other
content filter mechanism.
The policy services can score and accept or reject based on criteria
such as matching sender domain to IP records then comparing to the
connected IP.
Spamassassin can be tuned to quarantine mail or do what ever you like
with it.

Re: Forged MAIL FROM issue

[lst_hoe02]

Zitat von Alexandru Florescu :


Hello everybody.

I have a issue with postfix.

Consider the following scenario:

I telnet to my web server from another location (bar.com) and I start
executing commands.



Connected to foo.com.

Escape character is '^]'.

220 smtp1.foo.com ESMTP Postfix (GNU/Linux)

HELO bar.com

250 smtp1.foo.com

MAIL FROM: some...@gmail.com (mail must be valid)

250 2.1.0 Ok

RCPT TO:  a...@foo.com

250 2.1.5 Ok

DATA

354 End data with .

testing some kind of spam

.

250 2.0.0 Ok: queued as C7A602F7605

quit

221 2.0.0 Bye



Notes:

In this scenario, foo.com is my "real" mail server, bar.com is my "real"
testing server, some...@gmail.com is an example of an "existing" and valid
mail account and a...@foo.com is my "real" mail address.



The odd thing is that this actually works. I can connect and send mails
spoofing the sender's address, despite my postfix configuration directives:

permit_sasl_authenticated,

permit_mynetworks,

reject_unauth_destination,

reject_non_fqdn_hostname,

reject_invalid_hostname,

reject_unknown_recipient_domain,

 reject_unverified_recipient,

 reject_unknown_sender_domain,

 reject_invalid_helo_hostname,

 reject_non_fqdn_helo_hostname,

 reject_non_fqdn_sender,

 reject_unverified_sender,

 reject_unknown_sender_domain,

 reject_sender_login_mismatch,

 reject_unauth_pipelining,



Is some option missing? What can I do to prevent this? I found it because I
received spam in this way.

Using postfix 2.3.3 on Centos 5.4.


You are not SASL authenticated which is not needed for sending mail to  
a local address. SASL is only needed for relaying and without it you  
can not detect what user is trying to send so you have no way to match  
user<-->sender-address. This is how SMTP works.


Regards

Andreas



smime.p7s
Description: S/MIME Signatur

Re: Forged MAIL FROM issue

[LuKreme]

On 13-Jan-2010, at 06:33, Alexandru Florescu wrote:
> The odd thing is that this actually works. I can connect and send mails
> spoofing the sender's address, despite my postfix configuration directives:


Your problem is not with postfix. Your problem is with thinking SMTP is 
something it is not and never has been.


-- 
I DID NOT WIN THE NOBEL FART PRIZE
Bart chalkboard Ep. AABF19

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Stan Hoeppner]

Frank Cusack put forth on 1/12/2010 9:46 PM:

> I think it all ended well though?  Except my problem still exists. :\

We know things break when that hosts sends mail to you.  What happens when you
send mail to that host?  Do you see the same disconnect problem or similar?
What were the results of tcpdump?

-- 
Stan

Re: FILTER nexthop woes

[Dominik Schulz]

Am Montag 11 Januar 2010 15:08:05 schrieb Wietse Venema:
> l...@ds.gauner.org:
> > Hi,
> > I'm trying to use header_checks in conjunction with a pcre map to
> > distribute certain mail traffic to certain outgoing transports. I've got
> > a setup like this:
> > --- main.cf snip ---
> > header_checks = pcre:/etc/postfix/header.pcre
> > --- snap ---
> > --- header.pcre snip ---
> > /^X-CUSTOMER-ID: ([0-9])/ FILTER smtpout$1:
> You MUST specify a nexthop destination.  The purpose of FILTER is
> to send mail for MANY destinations through ONE filter destination.
> If you don't specify a next-hop destination, then Postfix will
> choose a default one.
> To make Postfix routing sender dependent, use
> sender_dependent_relayhost_maps (Postfix 2.3 and later) or
> sender_dependent_default_transport_maps (Postfix 2.7 and later).
Thanks for the reply. Unfortunately I don't seem to have myself clear.

I want to controll to nexthop (i.e. the outgoing relay) through some kind of 
"X-"-Header, e.g. "X-CUSTOMER_ID: 34554", and not through the sender/recipient 
addresses.

Is there some way to achieve this behaviour?

-- 
Mit freundlichen Grüßen / Best Regards
Dominik


signature.asc
Description: This is a digitally signed message part.

Re: Forged MAIL FROM issue

[Larry Stone]

On Wed, 13 Jan 2010, LuKreme wrote:


On 13-Jan-2010, at 06:33, Alexandru Florescu wrote:

The odd thing is that this actually works. I can connect and send mails
spoofing the sender's address, despite my postfix configuration directives:



Your problem is not with postfix. Your problem is with thinking SMTP is 
something it is not and never has been.


It's like LuKreme said. What you're seeing is a "feature" of SMTP that 
Postfix implements correctly.


And there are many valid reasons to be able to claim mail came from 
somewhere else. For instance, the university I attended provides us with 
lifetime forwarding e-mail addresses. Mail sent to that address forwards 
to whatever address I choose. I have no mailbox on a university server nor 
the ability to send via their servers. Yet, since I'm an officer of my 
alumni class there, I prefer to use that address for e-mail that is class 
business. The only way to do that is to send via my server and "spoof" the 
sending address.


Also, consider the analogy to paper mail. The sender address you put on a 
paper mail envelope is the address you want mail returned to, not the 
address of the mail box you drop it in (I put my home address on my 
envelopes, then drop it in a post office drop box at work).


-- Larry Stone
   lston...@stonejongleux.com

Re: Speeding up Local Delivery

[Victor Duchovni]

On Wed, Jan 13, 2010 at 12:35:19AM -0600, Wendigo Thompson wrote:

> Postfix accepts mail from the
> corporate mail server and delivers the message via a pipe alias to an
> application that is then inserting the message into the database.

Your choice of delivery mechanism is unfortunate. It is far better
to deliver to a persistent daemon that talks SMTP or LMTP, you get
much lower latency, I/O and CPU impact.

Don't use local(8) for high volume traffic to a single mailbox, or
to fork/exec scripts.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Forged MAIL FROM issue

[Stan Hoeppner]

Alexandru Florescu put forth on 1/13/2010 7:33 AM:

> 
> permit_mynetworks,

> 
> Is some option missing? What can I do to prevent this? I found it because I
> received spam in this way.
> 
> Using postfix 2.3.3 on Centos 5.4.

I'm guessing your telnet client machine is within mynetworks.  If so, none of
your other checks are valid and any/all mail sent via this telnet is thus
accepted regardless of mail from: forgery.

-- 
Stan

Re: FILTER nexthop woes

[Wietse Venema]

Dominik Schulz:
> Am Montag 11 Januar 2010 15:08:05 schrieb Wietse Venema:
> > l...@ds.gauner.org:
> > > Hi,
> > > I'm trying to use header_checks in conjunction with a pcre map to
> > > distribute certain mail traffic to certain outgoing transports. I've got
> > > a setup like this:
> > > --- main.cf snip ---
> > > header_checks = pcre:/etc/postfix/header.pcre
> > > --- snap ---
> > > --- header.pcre snip ---
> > > /^X-CUSTOMER-ID: ([0-9])/ FILTER smtpout$1:
> > You MUST specify a nexthop destination.  The purpose of FILTER is
> > to send mail for MANY destinations through ONE filter destination.
> > If you don't specify a next-hop destination, then Postfix will
> > choose a default one.
> > To make Postfix routing sender dependent, use
> > sender_dependent_relayhost_maps (Postfix 2.3 and later) or
> > sender_dependent_default_transport_maps (Postfix 2.7 and later).
> Thanks for the reply. Unfortunately I don't seem to have myself clear.
> 
> I want to controll to nexthop (i.e. the outgoing relay) through some kind of 
> "X-"-Header, e.g. "X-CUSTOMER_ID: 34554", and not through the 
> sender/recipient 
> addresses.
> 
> Is there some way to achieve this behaviour?

The short answer: specify a FILTER command that points to a Postfix
instance that has its own unique hostname, and that is bound to
its own unique IP address.

myhostname = unique-name.example.com
inet_interfaces = $myhostname

Adding Postfix instances is easy with Postfix 2.6.

Until someone explains why they must use the header and can't use
the envelope sender, I am not inclined to invest a lot of effort
on my side to find out if there exists a better solution.

Wietse

RE: Forged MAIL FROM issue

[Alexandru Florescu]

> I'm guessing your telnet client machine is within mynetworks.  If so, none
of
> your other checks are valid and any/all mail sent via this telnet is thus
> accepted regardless of mail from: forgery.
>
> -- 
> Stan

Hi Stan,
Actually my server was not from the same network. It's from home and it
doesn't have any special access.


> It's like LuKreme said. What you're seeing is a "feature" of SMTP that 
> Postfix implements correctly.
> 
> And there are many valid reasons to be able to claim mail came from 
> somewhere else. For instance, the university I attended provides us with 
> lifetime forwarding e-mail addresses. Mail sent to that address forwards 
> to whatever address I choose. I have no mailbox on a university server nor

> the ability to send via their servers. Yet, since I'm an officer of my 
> alumni class there, I prefer to use that address for e-mail that is class 
> business. The only way to do that is to send via my server and "spoof" the

> sending address.
> 
> Also, consider the analogy to paper mail. The sender address you put on a 
> paper mail envelope is the address you want mail returned to, not the 
> address of the mail box you drop it in (I put my home address on my 
> envelopes, then drop it in a post office drop box at work).
> 
> -- Larry Stone

Hi Larry,
Nice analogy. I think I got the picture now.
I understand that spamassassin deals with this issues so I guess I'll be
tinkering it.

Thank you.

Understanding Postfix and smtpd_recipient_restrictions priorities

[RaSca]

Hi all,
I've got a setup with Debian Lenny, Postfix with MySQL(on a remote 
server in the same LAN of the mail server) and Clamav+Spamassassin.

The original smtpd_recipient_restrictions parameter setting was this one:

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_hostname

Spamassassin is configured with rbl check and so those lists were never 
considered in Postfix... Until now.
Some days ago we started to serve a mail domain with a large amount of 
spam and after that the Mysql database broke up with the message "Too 
many connections".
The cause of this problem (as we saw from the logs) was that for any 
spam message which was directed to a nonexistent mail address (but with 
a correct domain) a connection to the db was also generated.
We've tried to find out a solution by adding some rbl checks directly in 
Postfix:


smtpd_recipient_restrictions =
   reject_non_fqdn_recipient,
   reject_non_fqdn_sender,
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   reject_invalid_helo_hostname,
   reject_unknown_sender_domain,
   reject_unknown_recipient_domain,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client bl.spamcop.net,
   reject_rbl_client list.dsbl.org,
   reject_rbl_client rbl.mail-abuse.org,
   reject_rbl_client spamsources.fabel.dk,
   reject_unlisted_recipient

putting "reject_unlisted_recipient" after all the rbl check drastically 
reduced the db connections, but after some time the Postfix process has 
stopped working.
We saw the process up with a "ps", but it was not accepting mail 
anymore. The only solution was to manually restart the Postfix daemon.


To find out a solution we recompiled and installed the 2.6.5 Postfix 
release (with vda patch, instead of the default Lenny 2.5.5) and after 
that the Postfix process went down just a time in a day, but it was not 
necessary to restart the daemon. The original process become responsive 
again by itself.


So the questions are: what the problems may be? Are they caused just by 
the amount of messages the mail server must manage? Why a new version 
seems to solve the problem? Are the priorities configured in the 
smtpd_recipient_restrictions parameters correct?


Thanks for your help,

--
RaSca
Mia Mamma Usa Linux: Niente è impossibile da capire, se lo spieghi bene!
ra...@miamammausalinux.org
http://www.miamammausalinux.org

Re: Understanding Postfix and smtpd_recipient_restrictions priorities

[Steve]

 Original-Nachricht 
> Datum: Wed, 13 Jan 2010 18:02:38 +0100
> Von: RaSca 
> An: postfix-users@postfix.org
> Betreff: Understanding Postfix and smtpd_recipient_restrictions priorities

> Hi all,
> I've got a setup with Debian Lenny, Postfix with MySQL(on a remote 
> server in the same LAN of the mail server) and Clamav+Spamassassin.
> The original smtpd_recipient_restrictions parameter setting was this one:
> 
> smtpd_recipient_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   reject_unauth_destination,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   reject_invalid_hostname
> 
> Spamassassin is configured with rbl check and so those lists were never 
> considered in Postfix... Until now.
> Some days ago we started to serve a mail domain with a large amount of 
> spam and after that the Mysql database broke up with the message "Too 
> many connections".
> The cause of this problem (as we saw from the logs) was that for any 
> spam message which was directed to a nonexistent mail address (but with 
> a correct domain) a connection to the db was also generated.
> We've tried to find out a solution by adding some rbl checks directly in 
> Postfix:
> 
> smtpd_recipient_restrictions =
> reject_non_fqdn_recipient,
> reject_non_fqdn_sender,
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_unauth_destination,
> reject_invalid_helo_hostname,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> reject_rbl_client zen.spamhaus.org,
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client list.dsbl.org,
> reject_rbl_client rbl.mail-abuse.org,
> reject_rbl_client spamsources.fabel.dk,
> reject_unlisted_recipient
> 
> putting "reject_unlisted_recipient" after all the rbl check drastically 
> reduced the db connections, but after some time the Postfix process has 
> stopped working.
> We saw the process up with a "ps", but it was not accepting mail 
> anymore. The only solution was to manually restart the Postfix daemon.
> 
> To find out a solution we recompiled and installed the 2.6.5 Postfix 
> release (with vda patch, instead of the default Lenny 2.5.5) and after 
> that the Postfix process went down just a time in a day, but it was not 
> necessary to restart the daemon. The original process become responsive 
> again by itself.
> 
> So the questions are: what the problems may be? Are they caused just by 
> the amount of messages the mail server must manage? Why a new version 
> seems to solve the problem? Are the priorities configured in the 
> smtpd_recipient_restrictions parameters correct?
> 
I would suggest you to use proxy maps to lower the amount of connections to the 
MySQL backend. 

And on the above smtpd_recipient_restrictions I would suggest to push 
reject_unlisted_recipient above all RBL checks since there is no benefit in 
checking RBLs if you are anyway going to reject them later (if the recipient is 
not managed on your system).

I as well would not use zen.spamhaus.org (without a subscription) if you have a 
high mail volume.



> Thanks for your help,
> 
> -- 
> RaSca
> Mia Mamma Usa Linux: Niente è impossibile da capire, se lo spieghi bene!
> ra...@miamammausalinux.org
> http://www.miamammausalinux.org

-- 
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Frank Cusack]

On January 13, 2010 8:16:36 AM -0600 Stan Hoeppner  
wrote:

Frank Cusack put forth on 1/12/2010 9:46 PM:


I think it all ended well though?  Except my problem still exists. :\


We know things break when that hosts sends mail to you.  What happens
when you send mail to that host?  Do you see the same disconnect problem
or similar? What were the results of tcpdump?


Sending mail works fine.  Interesting.

Contrary to what I said earlier, tcpdump is in fact interesting.  I see
a 3 way handshake, and that's it.  10 minutes later, a reset.  However
postfix logs a disconnect immediately.  I do notice that their mss is
only 1260, so clearly they are going through some kind of packet mangling
firewall.  But that doesn't excuse postfix for declaring the connection
disconnected when in fact no packet came from them.  What I don't
understand though, is if smtpd goes away prematurely, then when it exits
shouldn't a FIN or RST get sent?

I'm going to explore the resolver issue.

-frank

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Wietse Venema]

Frank Cusack:
> On January 13, 2010 8:16:36 AM -0600 Stan Hoeppner  
> wrote:
> > Frank Cusack put forth on 1/12/2010 9:46 PM:
> >
> >> I think it all ended well though?  Except my problem still exists. :\
> >
> > We know things break when that hosts sends mail to you.  What happens
> > when you send mail to that host?  Do you see the same disconnect problem
> > or similar? What were the results of tcpdump?
> 
> Sending mail works fine.  Interesting.
> 
> Contrary to what I said earlier, tcpdump is in fact interesting.  I see
> a 3 way handshake, and that's it.  10 minutes later, a reset.  However
> postfix logs a disconnect immediately.  I do notice that their mss is
> only 1260, so clearly they are going through some kind of packet mangling
> firewall.  But that doesn't excuse postfix for declaring the connection
> disconnected when in fact no packet came from them.

Would you be willing to share this complete evidence so that other
people can learn from it, or do you expect that we just take your
eyewitness report every claim made here sofar?

Perhaps surprisingly, Postfix does not send or receive network
packets.  Instead, packets are handled by the TCP/IP implementation
in the operating system kernel. 

If anything decides "prematurely" that the connection is dead, it
is your operating system kernel not Postfix.

Please do not fall into the trap of accusing the messenger (Postfix)
of the bad news  that comes from your operatring system kernel
(connection is dead).

Wietse

>  What I don't
> understand though, is if smtpd goes away prematurely, then when it exits
> shouldn't a FIN or RST get sent?
> 
> I'm going to explore the resolver issue.
> 
> -frank
> 
> 

Re: Understanding Postfix and smtpd_recipient_restrictions priorities

[RaSca]

Il giorno Mer 13 Gen 2010 18:09:35 CET, Steve ha scritto:
[...]
I would suggest you to use proxy maps to lower the amount of connections to the MySQL backend. 
And on the above smtpd_recipient_restrictions I would suggest to push reject_unlisted_recipient above all RBL checks since there is no benefit in checking RBLs if you are anyway going to reject them later (if the recipient is not managed on your system).

I as well would not use zen.spamhaus.org (without a subscription) if you have a 
high mail volume.


Thank you Steve,
I made as you suggested and now the MySQL threads still remains low even 
if reject_unlisted_recipient is on the top of the list.
I also removed smahaus.org from the rbl check, I'm going to find out if 
it's conveninet subscribing to the service.


Thanks a lot!

--
RaSca
Mia Mamma Usa Linux: Niente è impossibile da capire, se lo spieghi bene!
ra...@miamammausalinux.org
http://www.miamammausalinux.org

Re: Understanding Postfix and smtpd_recipient_restrictions priorities

[Brian Evans - Postfix List]

On 1/13/2010 12:32 PM, RaSca wrote:
> Il giorno Mer 13 Gen 2010 18:09:35 CET, Steve ha scritto:
> [...]
>> I would suggest you to use proxy maps to lower the amount of
>> connections to the MySQL backend. And on the above
>> smtpd_recipient_restrictions I would suggest to push
>> reject_unlisted_recipient above all RBL checks since there is no
>> benefit in checking RBLs if you are anyway going to reject them later
>> (if the recipient is not managed on your system).
>> I as well would not use zen.spamhaus.org (without a subscription) if
>> you have a high mail volume.
>
> Thank you Steve,
> I made as you suggested and now the MySQL threads still remains low
> even if reject_unlisted_recipient is on the top of the list.
> I also removed smahaus.org from the rbl check, I'm going to find out
> if it's conveninet subscribing to the service.
>

In addition, list.dsbl.org is dead and gone for some time now.
You are just adding a DNS lookup that will never return anything valuable.

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Frank Cusack]

On January 13, 2010 12:27:02 PM -0500 Wietse Venema  
wrote:

Frank Cusack:

Contrary to what I said earlier, tcpdump is in fact interesting.  I see
a 3 way handshake, and that's it.  10 minutes later, a reset.  However
postfix logs a disconnect immediately.  I do notice that their mss is
only 1260, so clearly they are going through some kind of packet mangling
firewall.  But that doesn't excuse postfix for declaring the connection
disconnected when in fact no packet came from them.


Would you be willing to share this complete evidence so that other
people can learn from it, or do you expect that we just take your
eyewitness report every claim made here sofar?


Easy there.  I am just reporting my interim findings.  I thought I
had enough info to be worth the incomplete followup and took the
opportunity to muse a bit.  I certainly wasn't casting any aspersions
on postfix.


Perhaps surprisingly, Postfix does not send or receive network
packets.  Instead, packets are handled by the TCP/IP implementation
in the operating system kernel.

If anything decides "prematurely" that the connection is dead, it
is your operating system kernel not Postfix.


Unless of course postfix has a bug (heaven forbid).

Anyway that's why I added the note about how it seems impossible
that smtpd would die prematurely without my then seeing FIN/RST.
That can't happen unless someone is holding onto the connection
and would seem to exonerate postfix.

I haven't been able to prove this yet (have to wait the agonizing
delay until the remote server tries to run the queue again) but
I think maybe the smtpd log report actually occurs when the FIN
comes (firewall timeout, probably), not when the connection comes
in.  If I create a test host with a huge PTR RRset, and connect
from there, postfix does not reply with a banner.  Ever.  (OK not
for at least 10 minutes.)  This does in fact coincide with my tcpdump;
I see only the handshake and nothing else.  When I disconnect from
my test host nothing gets logged whatsoever, not the connection and
not the disconnect.  I think the OS resolver is indeed broken and/or
postfix is not handling the bug well.  Not sure yet if postfix could
actually do anything about it.  Also not sure yet why postfix logs
something for the real problem host and not my test host.  Perhaps
the difference in how FIN vs RST is presented to the process holding
that fd.

-frank

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Victor Duchovni]

On Wed, Jan 13, 2010 at 12:54:38PM -0500, Frank Cusack wrote:

>> If anything decides "prematurely" that the connection is dead, it
>> is your operating system kernel not Postfix.
>
> Unless of course postfix has a bug (heaven forbid).

I would like to suggest to the rest of the community on this list that
impertinent folly of this type not be rewarded with any further attention
or assistance. The OP has the Postfix source code, he is welcome to find
and fix any relevant bugs he finds. I'm done with this thread too. Over
and out.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Wietse Venema]

Frank Cusack:
> > Perhaps surprisingly, Postfix does not send or receive network
> > packets.  Instead, packets are handled by the TCP/IP implementation
> > in the operating system kernel.
> >
> > If anything decides "prematurely" that the connection is dead, it
> > is your operating system kernel not Postfix.
> 
> Unless of course postfix has a bug (heaven forbid).

Well, if you can provide unmodified evidence, then people
can look into this.

- I already asked for the content of the packet dump including
packet headers, packet flags, packet contents and so on. 

Based on an analysis of this,

- I may also ask you to collect Postfix verbose logging
for that particular IP address.

That gives the Postfix view of what's going on. 

Based on that,

- I may also ask you to collect a system call trace.

That would give the kernel's view of what's going on.

In the meantime, it would help if you could stop posting further
speculation and theoretizing until we have had a chance to look at
actual concrete unmodified evidence.

Wietse

RE: Postfix as an MTA question

[Bucl, Casper]

That's exactly what I was looking for!
Thanks,

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of mouss
Sent: Tuesday, January 12, 2010 1:51 PM
To: postfix-users
Subject: Re: Postfix as an MTA question

Bucl, Casper a écrit :
> Hi,
> 
> I’m trying to use Postfix as an MTA. I don’t want to deliver any mail
> locally, just relay everything to an external mail server. I would also
> like everything that runs though this MTA to be sent as a particular
> user, however I don’t want messages intended for users on the system
> such as root to be delivered. I have gotten everything to work except I
> am getting messages for the root user sent to the sendas address. If the
> system users have to be delivered, that is fine, I can just use the
> aliases to redirect them to a single user and then deal with the mail
> there. I would prefer that they go to a black hole though. I’ve been
> trying to find a solutions to this for some time now and haven’t been
> successful so far. Any direction you can provide is appreciated.
> 

It looks like you want:

http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall


> [snip]

postscreen stress=yes

[Noel Jones]

Is postscreen supposed to always run with stress=yes?
Seems to me stress-adaptive behavior would be useful in 
postscreen.


# postconf mail_version
mail_version = 2.7-20100102

# ps -aux|grep stress
postfix 19967  0.0  1.0 23508 15444  ??  I12:50PM 
0:00.76 smtpd -t pass -u -o stress= -o 
content_filter=amavis-smtp:[1
postfix 19969  0.0  1.0 23508 15484  ??  I12:50PM 
0:00.90 smtpd -t pass -u -o stress= -o 
content_filter=amavis-smtp:[1
postfix 20637  0.0  0.1  3028 1704  ??  Ss1:32PM   0:00.01 
postscreen -l -n smtp -t inet -u -o stress=yes


(under light load)


Did I miss some docs or earlier discussion about this?

  -- Noel Jones

Re: postscreen stress=yes

[Victor Duchovni]

On Wed, Jan 13, 2010 at 01:44:05PM -0600, Noel Jones wrote:

> Is postscreen supposed to always run with stress=yes?
> Seems to me stress-adaptive behavior would be useful in postscreen.
>
> postfix 20637  0.0  0.1  3028 1704  ??  Ss1:32PM   0:00.01 postscreen 
> -l -n smtp -t inet -u -o stress=yes

There is only one process, so it is always at full occupancy, the
stress=yes is an artifact, and should not be taken seriously in this case.
Perhaps the master daemon can be changed to special-case services with
a process limit of 1.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: postscreen stress=yes

[Wietse Venema]

Noel Jones:
> Is postscreen supposed to always run with stress=yes?
> Seems to me stress-adaptive behavior would be useful in 
> postscreen.

The stress=yes setting indicates that a master.cf service is using
up all its process slots. It is applicable only for servers that
accept connections from remote clients.

By design, postscreen runs as a single process. The stress=yes
parameter value therefore carries no useful information. Either
the postscreen service is not running at all, or it uses up all
its process slots because there is only one.

I could make a special case for single-process servers in master.cf
so that they don't have a stress parameter.

Wietse

*** ./master_ent.c- Sat Jan 10 19:02:29 2009
--- ./master_ent.c  Wed Jan 13 15:04:47 2010
***
*** 526,532 
argv_add(serv->args, "-u", (char *) 0);
  if (chroot)
argv_add(serv->args, "-c", (char *) 0);
! if ((serv->flags & MASTER_FLAG_LOCAL_ONLY) == 0) {
argv_add(serv->args, "-o", "stress=" CONFIG_BOOL_YES, (char *) 0);
serv->stress_param_val =
serv->args->argv[serv->args->argc - 1] + sizeof("stress=") - 1;
--- 526,532 
argv_add(serv->args, "-u", (char *) 0);
  if (chroot)
argv_add(serv->args, "-c", (char *) 0);
! if ((serv->flags & MASTER_FLAG_LOCAL_ONLY) == 0 && serv->max_proc > 1) {
argv_add(serv->args, "-o", "stress=" CONFIG_BOOL_YES, (char *) 0);
serv->stress_param_val =
serv->args->argv[serv->args->argc - 1] + sizeof("stress=") - 1;

Re: postscreen stress=yes

[Noel Jones]

On 1/13/2010 2:06 PM, Wietse Venema wrote:

Noel Jones:

Is postscreen supposed to always run with stress=yes?
Seems to me stress-adaptive behavior would be useful in
postscreen.


The stress=yes setting indicates that a master.cf service is using
up all its process slots. It is applicable only for servers that
accept connections from remote clients.

By design, postscreen runs as a single process. The stress=yes
parameter value therefore carries no useful information. Either
the postscreen service is not running at all, or it uses up all
its process slots because there is only one.

I could make a special case for single-process servers in master.cf
so that they don't have a stress parameter.


OK, I think I understand it better now.  I would find it less 
confusing without the stress=yes in the process listing.


Thanks to you and Viktor for the quick response.

  -- Noel Jones

Re: multiple PTR records

[Frank Cusack]

On January 12, 2010 4:19:50 PM -0500 Frank Cusack  
wrote:

I can't think of a scenario for ANY type of server that would *require*
multiple PTR records.


I coincidentally just came across such a case.  zeroconf uses multiple
PTR records.  Not in .in-addr.arpa zones, so you don't use them to
resolve IPs to canonical hostnames, but nonetheless it uses PTR records
not unlike IP->A PTR mapping.  For example you might have

_ipp._tcp.foo.com   IN PTR printer1._ipp._tcp.foo.com.
_ipp._tcp.foo.com   IN PTR printer2._ipp._tcp.foo.com.
...

The printerN._ipp._tcp.foo.com entries then each get an SRV record.

-frank

Bounces

[Dhiraj Chatpar]

Dear All,

What string or what configuration to use in postfix in order to not receive
any bounces at all. I mean incase there is a bounce it should not be
returned back to the sender who initiated the mail.

I am sure there is a way to achieve this in postfix

Rgds
Dhiraj

Re: Bounces

[Stan Hoeppner]

Dhiraj Chatpar put forth on 1/13/2010 3:21 PM:
> Dear All,
> 
> What string or what configuration to use in postfix in order to not
> receive any bounces at all. I mean incase there is a bounce it should
> not be returned back to the sender who initiated the mail.
> 
> I am sure there is a way to achieve this in postfix

http://www.postfix.org/bounce.8.html

-- 
Stan

Re: Bounces

[Dhiraj Chatpar]

Yes, But which parameter to use in order to stop bounces totally and how?


Pablo Picasso
- "Computers are useless. They can only give you answers."

On Thu, Jan 14, 2010 at 02:59, Stan Hoeppner  wrote:

> Dhiraj Chatpar put forth on 1/13/2010 3:21 PM:
> > Dear All,
> >
> > What string or what configuration to use in postfix in order to not
> > receive any bounces at all. I mean incase there is a bounce it should
> > not be returned back to the sender who initiated the mail.
> >
> > I am sure there is a way to achieve this in postfix
>
> http://www.postfix.org/bounce.8.html
>
> --
> Stan
>

Re: Bounces

[Wietse Venema]

Dhiraj Chatpar:
> Dear All,
> 
> What string or what configuration to use in postfix in order to not receive
> any bounces at all. I mean incase there is a bounce it should not be
> returned back to the sender who initiated the mail.
> 
> I am sure there is a way to achieve this in postfix

See:
   RFC 3461 (SMTP DSN Extension)

The DSN option controls how to request bounces with SMTP mail.

See:
   http://www.postfix.org/sendmail.1.html

The -N command-line option controls how to request bounces with
the Postfix sendmail command.

Wietse

Re: Bounces

[Stan Hoeppner]

Dhiraj Chatpar put forth on 1/13/2010 3:31 PM:
> Yes, But which parameter to use in order to stop bounces totally and how?

Please don't top post.

You may try commenting out the bounce daemon in master.cf and restarting 
Postfix.

bounceunix  -   -   -   -   0   bounce
#bounceunix  -   -   -   -   0   bounce

There may be a better or more optimal way to do this.  If so one of the devs or
more seasoned OPs may help you.

-- 
Stan

connections from ipv4 localhost logged as unknown[127.0.0.1]

[Tom Hendrikx]

Hi,

After setting up postfix up on a ipv4/ipv6 dualstack machine I'm seeing
the following issue: connections on 127.0.0.1 (where my content_filter
re-injects mail) are logged as:

010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: warning:
127.0.0.1: address not listed for hostname ip6-localhost
2010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: connect
from unknown[127.0.0.1]

After some time reading google and debugging this is what I found out:
- /etc/hosts contains the following stuff regarding localhost (in the
specified order):
::1 ip6-localhost ip6-loopback
127.0.0.1 localhost

- The test utils in auxiliary/name-addr-test show the same behaviour as
postfix itself:
./getnameinfo 127.0.0.1
Hostname:   ip6-localhost
Address:127.0.0.1
./gethostbyaddr 127.0.0.1
Hostname:   ip6-localhost
Aliases:ip6-loopback
Addresses:  127.0.0.1

- After some tests, I can (temporarily) fix this in 3 ways:
1) Changing postfix's main.cf to use only ipv4 (comment
inet_protocols=all + restart)
2) Removing  the line for ::1 in /etc/hosts
3) Change the order of /etc/hosts, placing the line for ::1 below 127.0.0.1

All of the above on Gentoo Linux, 2.6.27-openvz-briullov.1-r4 kernel,
Postfix 2.6.5 and glibc 2.10 (also tested with 2.9). Postconf -n looks
like this:

command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = //usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
home_mailbox = .maildir/
html_directory = /usr/share/doc/postfix-2.6.5/html
inet_protocols = all
local_recipient_maps = $alias_maps
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
mydomain = whyscream.net
myhostname = a.mx.whyscream.net
mynetworks = cidr:/etc/postfix/mynetworks
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
proxy_interfaces = 217.149.194.147
proxy_read_maps = $virtual_mailbox_domains, $virtual_mailbox_maps,
$virtual_alias_maps
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.5/readme
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_non_fqdn_hostname
   reject_invalid_hostname permit
smtpd_recipient_restrictions = permit_mynetworks
reject_unauth_destination   reject_non_fqdn_sender
reject_non_fqdn_recipient   reject_unknown_sender_domain
reject_unknown_recipient_domain reject_unauth_pipelining
check_client_access hash:/etc/postfix/access_whitelist
check_policy_service unix:private/postgrey   permit
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/postfix/a.mx.whyscream.net-cert.pem
smtpd_tls_key_file = /etc/ssl/postfix/a.mx.whyscream.net-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_maps =
proxy:pgsql:/etc/postfix/pgsql/virtual_alias_maps.conf
proxy:pgsql:/etc/postfix/pgsql/virtual_alias_domain_maps.conf
proxy:pgsql:/etc/postfix/pgsql/virtual_alias_domain_catchall_maps.conf
virtual_gid_maps = static:12
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_domains =
proxy:pgsql:/etc/postfix/pgsql/virtual_mailbox_domains.conf
virtual_mailbox_maps =
proxy:pgsql:/etc/postfix/pgsql/virtual_mailbox_maps.conf
pgsql:/etc/postfix/pgsql/virtual_alias_domain_mailbox_maps.conf
virtual_minimum_uid = 100
virtual_transport = dovecot
virtual_uid_maps = static:251

I've also read this (famous/dreaded) bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=4980 which seems related,
but since I'm well past glibc 2.7, I'd expect not to bitten by that one.
However I'm no expert on the subject and I have no idea how the fix as
mentioned in bug looks like.

Now my question is: is this the place where you'd say "your glibc is
broken, talk to your os vendor" or could there some other issue that I
overlooked?


-- 
Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: Bounces

[Dhiraj Chatpar]

How do i make the changes in postfix so that it stops sending out bounced
mail totally?


Jonathan Swift
- "May you live every day of your life."

On Thu, Jan 14, 2010 at 03:49, Wietse Venema  wrote:

> Dhiraj Chatpar:
> > Dear All,
> >
> > What string or what configuration to use in postfix in order to not
> receive
> > any bounces at all. I mean incase there is a bounce it should not be
> > returned back to the sender who initiated the mail.
> >
> > I am sure there is a way to achieve this in postfix
>
> See:
>   RFC 3461 (SMTP DSN Extension)
>
> The DSN option controls how to request bounces with SMTP mail.
>
> See:
>   http://www.postfix.org/sendmail.1.html
>
> The -N command-line option controls how to request bounces with
> the Postfix sendmail command.
>
>Wietse
>

Re: Bounces

[Dhiraj Chatpar]

Is it possible to # out the bounce line in master.cf? Will that stop all
bounces?


Samuel Goldwyn
- "I'm willing to admit that I may not always be right, but I am never
wrong."

On Thu, Jan 14, 2010 at 03:53, Dhiraj Chatpar  wrote:

> How do i make the changes in postfix so that it stops sending out bounced
> mail totally?
>
>
> Jonathan 
> Swift - "May 
> you live every day of your life."
>
> On Thu, Jan 14, 2010 at 03:49, Wietse Venema  wrote:
>
>> Dhiraj Chatpar:
>> > Dear All,
>> >
>> > What string or what configuration to use in postfix in order to not
>> receive
>> > any bounces at all. I mean incase there is a bounce it should not be
>> > returned back to the sender who initiated the mail.
>> >
>> > I am sure there is a way to achieve this in postfix
>>
>> See:
>>   RFC 3461 (SMTP DSN Extension)
>>
>> The DSN option controls how to request bounces with SMTP mail.
>>
>> See:
>>   http://www.postfix.org/sendmail.1.html
>>
>> The -N command-line option controls how to request bounces with
>> the Postfix sendmail command.
>>
>>Wietse
>>
>
>

Re: Bounces

[Wietse Venema]

Dhiraj Chatpar:
> Dear All,
>
> What string or what configuration to use in postfix in order to not receive
> any bounces at all. I mean incase there is a bounce it should not be
> returned back to the sender who initiated the mail.
>
> I am sure there is a way to achieve this in postfix

Wietse:
> > See:
> >   RFC 3461 (SMTP DSN Extension)
> >
> > The DSN option controls how to request bounces with SMTP mail.
> >
> > See:
> >   http://www.postfix.org/sendmail.1.html
> >
> > The -N command-line option controls how to request bounces with
> > the Postfix sendmail command.

Dhiraj Chatpar:
> How do i make the changes in postfix so that it stops sending out bounced
> mail totally?

YOU MUST FIX YOUR CONFIGURATION ERROR, and stop accepting
mail for non-existent recipients.

See http://www.postfix.org/ADDRESS_CLASS_README.html to set up
the proper recipient address validation BEFORE accepting mail.

Wietse

Re: connections from ipv4 localhost logged as unknown[127.0.0.1]

[Wietse Venema]

Tom Hendrikx:
> Hi,
> 
> After setting up postfix up on a ipv4/ipv6 dualstack machine I'm seeing
> the following issue: connections on 127.0.0.1 (where my content_filter
> re-injects mail) are logged as:
> 
> 010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: warning:
> 127.0.0.1: address not listed for hostname ip6-localhost

Given the client IP address 127.0.0.1, Postfix gets the name
ip6-localhost, but that name does have the address 127.0.0.1.

> After some time reading google and debugging this is what I found out:
> - /etc/hosts contains the following stuff regarding localhost (in the
> specified order):
> ::1 ip6-localhost ip6-loopback
> 127.0.0.1 localhost

And indeed. Name ip6-localhost does not list address 127.0.0.1.

Somewhere, you have a mapping from 127.0.0.1 that returns ip6-localhost,
and that mapping is screwing things up, because 127.0.0.1 is not
listed as an address for ip6-localhost.

Wietse

Re: connections from ipv4 localhost logged as unknown[127.0.0.1]

[Michael Saldivar]

On Wed, Jan 13, 2010 at 3:20 PM, Tom Hendrikx  wrote:

> Hi,
>
> After setting up postfix up on a ipv4/ipv6 dualstack machine I'm seeing
> the following issue: connections on 127.0.0.1 (where my content_filter
> re-injects mail) are logged as:
>
> 010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: warning:
> 127.0.0.1: address not listed for hostname ip6-localhost
> 2010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: connect
> from unknown[127.0.0.1]
>
> After some time reading google and debugging this is what I found out:
> - /etc/hosts contains the following stuff regarding localhost (in the
> specified order):
> ::1 ip6-localhost ip6-loopback
> 127.0.0.1 localhost
>
> [snip]

> mydomain = whyscream.net
> myhostname = a.mx.whyscream.net
>

Add your machine's hostname and FQDN to /etc/hosts:

::1 ip6-localhost ip6-loopback
127.0.0.1 localhost a a.mx.whyscream.net

-Mike

Re: connections from ipv4 localhost logged as unknown[127.0.0.1]

[Tom Hendrikx]

Wietse Venema wrote:
> Tom Hendrikx:
>> Hi,
>>
>> After setting up postfix up on a ipv4/ipv6 dualstack machine I'm seeing
>> the following issue: connections on 127.0.0.1 (where my content_filter
>> re-injects mail) are logged as:
>>
>> 010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: warning:
>> 127.0.0.1: address not listed for hostname ip6-localhost
> 
> Given the client IP address 127.0.0.1, Postfix gets the name
> ip6-localhost, but that name does have the address 127.0.0.1.
> 
>> After some time reading google and debugging this is what I found out:
>> - /etc/hosts contains the following stuff regarding localhost (in the
>> specified order):
>> ::1 ip6-localhost ip6-loopback
>> 127.0.0.1 localhost
> 
> And indeed. Name ip6-localhost does not list address 127.0.0.1.
> 
> Somewhere, you have a mapping from 127.0.0.1 that returns ip6-localhost,
> and that mapping is screwing things up, because 127.0.0.1 is not
> listed as an address for ip6-localhost.
> 

I got as far as this conclusion too, which got me checking for the
contents of /etc/hosts. Since I can influence the lookup results easily
by shuffling the contents of /etc/hosts, can I conclude that this is an
issue with my glibc?

Example: changing the contents of the hosts file to:
::1 ip6-foobar ip6-localhost ip6-loopback
127.0.0.1 localhost

yields the following result:
postfix/smtpd[5128]: warning: 127.0.0.1: address not listed for hostname
ip6-foobar

-- 
Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Rewriting envelope sender for aliases

[Hector Martin]

Hi,

I have Postfix configured with delivery through virtual. Some users get
IMAP mailboxes and some users have their mail redirected elsewhere. I
have virtual_alias_maps set to a file like this:

f...@example.com foo...@gmail.com
...

I find that sometimes my mail is dropped by filters along the way
because the envelope sender is not modified. For example, if
b...@gmail.com sends mail to f...@example.com, mail.example.com ends up
sending out mail from b...@gmail.com (to foo...@gmail.com), which may not
be seen as very legitimate and goes against SPF for some domains.

What I want to do is rewrite the envelope sender such that it appears to
come from the left hand side of the alias map file, so a mail from
b...@gmail.com to f...@example.com would turn into a mail from
f...@example.com to foo...@gmail.com. Is there a way of doing this in
Postfix?

-- 
Hector Martin (hec...@marcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

Re: connections from ipv4 localhost logged as unknown[127.0.0.1]

[Wietse Venema]

Tom Hendrikx:
> Wietse Venema wrote:
> > Tom Hendrikx:
> >> Hi,
> >>
> >> After setting up postfix up on a ipv4/ipv6 dualstack machine I'm seeing
> >> the following issue: connections on 127.0.0.1 (where my content_filter
> >> re-injects mail) are logged as:
> >>
> >> 010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: warning:
> >> 127.0.0.1: address not listed for hostname ip6-localhost
> > 
> > Given the client IP address 127.0.0.1, Postfix gets the name
> > ip6-localhost, but that name does have the address 127.0.0.1.
> > 
> >> After some time reading google and debugging this is what I found out:
> >> - /etc/hosts contains the following stuff regarding localhost (in the
> >> specified order):
> >> ::1 ip6-localhost ip6-loopback
> >> 127.0.0.1 localhost
> > 
> > And indeed. Name ip6-localhost does not list address 127.0.0.1.
> > 
> > Somewhere, you have a mapping from 127.0.0.1 that returns ip6-localhost,
> > and that mapping is screwing things up, because 127.0.0.1 is not
> > listed as an address for ip6-localhost.
> > 
> 
> I got as far as this conclusion too, which got me checking for the
> contents of /etc/hosts. Since I can influence the lookup results easily
> by shuffling the contents of /etc/hosts, can I conclude that this is an
> issue with my glibc?

Obviously, there is no 127.0.0.1 <-> ip6-localhost mapping in /etc/hosts.

Therefore, when Postfix gets ip6-localhost when it asks the name
for 127.0.0.1, then that information did not come from /etc/hosts.

You can tweak your /etc/hosts until the cows come home, or you can try
to find out were that 127.0.0.1->ip6-localhost is coming from.

Wietse

Pflogsumm Status

[Jim Seymour]

Hi All,

As many of you may be aware, about a year ago I emailed the list
asking if anybody would be interested in taking over maintenance
of Pflogsumm.  Several people volunteered.  In the mean-time,
after un-loading a bit (basically taking a hiatus from anything
that resembled computer "work" in my spare time) and reflecting on
it, I decided to keep the project.  At the time I was considering
giving it, and my other projects up, I was going through a pretty
rough patch, life-wise, job-wise, etc..  I've gotten things
straightened-out and back on an even keel.  (Well, as even a keel
as things can get, these days :).)

I'm working on a new release even now.  More information to
follow in a day or two.

Regards,
Jim

--
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Pflogsumm Status

[Joe]

Jim Seymour wrote:

Hi All,


I'm working on a new release even now.  More information to
follow in a day or two.


That is great news - looking forward to your next release. It's a useful 
tool indeed.


Joe

Re: Pflogsumm Status

[Stan Hoeppner]

Joe put forth on 1/13/2010 9:35 PM:
> Jim Seymour wrote:
>> Hi All,
>>
>>
>> I'm working on a new release even now.  More information to
>> follow in a day or two.
> 
> That is great news - looking forward to your next release. It's a useful
> tool indeed.


Seconded.  I use it daily, although I'm probably a few revs behind.
(Debian/Lenny 1.1.0-3)

-- 
Stan

Re: Rewriting envelope sender for aliases

[Victor Duchovni]

On Thu, Jan 14, 2010 at 01:11:17AM +0100, Hector Martin wrote:

> What I want to do is rewrite the envelope sender such that it appears to
> come from the left hand side of the alias map file, so a mail from
> b...@gmail.com to f...@example.com would turn into a mail from
> f...@example.com to foo...@gmail.com. Is there a way of doing this in
> Postfix?

Perhaps with an SRS milter, or similar content filter, assuming these
take extreme caution to avoid loops (never rewrite "<>" to a non empty
return path) and provide appropriate means for bounces to come back to
the original sender in most cases.

Nothing built-in, because supporting the return path requires non-trivial
state.

To support this in Postfix itself, one needs an address class for domains
handled in this way, and a special delivery agent that processes mail
for such domains.

The delivery agent would:

- Securely handle return-path transformations to allow back-propagation
  of bounces.

- Carefully replace the sender address before forwarding messages.
  Deal with DSN notification attributes, ...

The SMTP server would perhaps need to be able to validate authenticated
bounces to return paths generated by the redirect delivery agent.
Alternatively, since bounces don't bounce, one could consider receiving
mail to any address in such a domain, provided the sender is "<>".

You would still be able to alias selective users in normal domains, but
would do indirectly. Hypothetically:

main.cf:
indexed = ${default_database_type}/${config_directory}/
redirect_transport  = redirect
redirect_domains= redirect.example.com
redirect_maps   = ${indexed}redirect_maps

virtual_alias_maps:
u...@inside.example.com uni...@redirect.example.com

redirect_maps:
uni...@redirect.example.com u...@outside.example.net

You would still need to spam filter very well before forwarding
significant volumes of email, otherwise the reputation of your forwarding
systems will be poor, and they experience delivery issues despite
(double negative) lack of SPF non-compliance.

No such delivery agent has been written, or address class implemented,
these are just random thoughts on what this would look like if supported
directly, rather than in content_filter or milter.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.