Additional discussion: null sender -> MAILER-DAEMON
Ben Goodwin
------=_NextPart_000_0053_01C565CF.2B1095B0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I realize this has been talked about in the past (did some searching prior
to subscribing to the list just now), but it doesn't appear to have ended in
a solution and I'm running into a problem.
I use Postfix (2.1.5) as a mail gateway in front of an Exchange core. When
someone sends email to an Exchange user and the sending MTA does a "mail
from: <>" (seems like broken behavior, yes, but it happens nevertheless),
Postfix rewrites the From as MAILER-DAEMON, which means when someone replies
to the email, they end up replying to MAILER...@mygateway.domain.com
(which goes to me). So I'm ending up getting all these email threads to
MAILER-DAEMON. It also worries me that if an SMTP server sends me a bounce
using the null sender, the bounce appears in my mailbox appearing to come
from MY systems intead of theirs. I'd like a solution, though I don't know
what's most appropriate. For example (and I know this doesn't mean it's
right), under sendmail, there's no From or Reply to - if I reply to the
message, the To: field is blank. Exim actually scans for the From: header
and inserts that into the From field (that seems like an alarmingly bad
thing to do). Is there anything I can do to emulate Sendmail's behavior
without changing code? If not, can we discuss the problem and perhaps come
to a permanent solution for future releases of Postfix?
Thanks all!
-=| Ben
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.1 (Build 2179)
iQA/AwUBQpx6t1QK10CpvqFVEQKZ5ACfczTI+C+pR5IazLWtuZ0s5TnJUbsAnRmy
MogMODKaWNMQZ1OlDdPFtDui
=a073
-----END PGP SIGNATURE-----
------=_NextPart_000_0053_01C565CF.2B1095B0
Content-Type: application/octet-stream;
name="PGPexch.htm.pgp"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="PGPexch.htm.pgp"
-----BEGIN PGP MESSAGE-----
Version: PGP Desktop 9.0.1 (Build 2179)
owHVVjtvI1UUjkAUGLngH5x1kWQlP7LOZlcktjdO7N21tHaiZJZVGuDOzLHn4pl7
zb134njFH0A01GiFgI6Cmg5RUSIKJEACWqiQkOgo4JyZsTeRQEjQgIvxPM7z+75z
Zt5au/Psc2sHTx5/4pW+3v/o0w8evvjMl4/W3oPRtzvea6/++t3tb/ZfOPzh7Xe/
gnfW3v9x8uT7z36afvjL6ItT8fm9we+D337++PlX/DX+ta71jg69s+M+3PeGD+D4
4cGDwSFUao3Go+3DRqPn9fIHN+tb4BmhrHRSKxE3Gv1RpVMutfhpp3W/3+3x1bDv
dSFyblbDN1J53j7UyqFyNW8xQwjyi3bF4YVrRC6J9yCIhLHo2qmtCRtIWVlFWVkP
T7MKbtW3turNl/hwq3m7Akok2L7XH/VPut7RSafVWNZwcNQ74//e4OVO6/S4O4Ig
Fta2t7e3m82bt2/crG3f2Nppbm3tdFp3j0YejEWA7a6RIgYrH2O72RmAQRHTObhI
WoiEhXLJR1TgRDzFEISvUweSriOEmbAONkMZgtUJgkVhgkiqCcyM1AacBpv6NjDS
55t0yU7lUizJ7fWUDkrPr1fB54gOQo1WbTgQsxkFYvNInCOgCikvZRSUJU6ZBRAq
hMFGQrFMqhQHl4rsBSXWfoxJvdXgBgkbhoH+GJJ/iEy5VGBzNea68u1s719FXmGe
WoRjbd1YXlC6zWb9Rn3nep6ACBCQCBnDRDiciwUjMTYkEdBjwgH6F6QkNWGRGazn
TvAoIsaYE60YcEsYWsAsDMN0yYtSmwxOpobtGMwhqZDZoNSVzIkSJruwHru99Ynb
q3CRFjGxEMspgm/0lPL5SHwR71VYoF2xGjGdyoLCczSUJEZrifNluwbnRjpkmXEF
dykRUM/D7uBB/6TW6/aHR6MqzCMZRJAgjSGdX+rN4CyW5F1oK2uxyqcLCkjdQDrL
bBaFAFtduh8ZHLezxpzevZJpP1kUMNdDTQaqHuik0vl7m1aj22FU8kInOi8pwetL
Rk51JtgCYKpqgs7xqYhjrtfikh+qToSZe7l0JfEy1IBGJLYa5toY7j3hYRUEdqaH
06F3TEQaQhty3um5ABpbFbAWUptBQWCplFKzCZoMsqVNPn+WhZYsMu35+qK4W8AY
8LizKLjGM7AL61gNNIRUOwuTwkljVxVvhLlSno4wZ9TpJIIBKY2nfkq7gKLNqZMN
qpnkwSmNplVCaC8j3aW1ghcimcUIm9kWyB2zbbVcIKwTkt4Gi8rISeRIbym3mXW7
kohBslA61xzFPWGdcHc1hnKQ62aprIRkKyZYLXTq6V0YS4xpMVnwY6Gmywr7F5IU
HLiUiF2ADViyY16Ghbp3ISKMiqErl6QirpwtGFRFNjbM4+VJNrPHl0aOGhSxMAnx
EbPUfRHm9i4qKAr1SnsDm7dLXov8+QCoLjJhQ0zSmBCG0wKbjXzl57MMc8k8OcjW
BbsGOsQ7y8Bjws9Vs2BzhFDaILU2fzXki7jocoaG9oDNdZMvajSJUPSae7rUGaVx
6lLDYx2jsKRtklK5VOyKO/+npe4RXlNGkmRw7b9YeO5x+Qh/nazWfhMOUP1ZH61G
9tlBXyH8PVQu/QE=
=hJ7N
-----END PGP MESSAGE-----
------=_NextPart_000_0053_01C565CF.2B1095B0--
Wietse Venema
> I realize this has been talked about in the past (did some searching prior
> to subscribing to the list just now), but it doesn't appear to have ended in
> a solution and I'm running into a problem.
>
> I use Postfix (2.1.5) as a mail gateway in front of an Exchange core. When
> someone sends email to an Exchange user and the sending MTA does a "mail
> from: <>" (seems like broken behavior, yes, but it happens nevertheless),
> Postfix rewrites the From as MAILER-DAEMON, which means when someone replies
On the contrary, "MAIL FROM:<>" is required for SMTP error
notifications, so that they cannot go into an infinite loop.
> to the email, they end up replying to MAILER...@mygateway.domain.com
> (which goes to me). So I'm ending up getting all these email threads to
> MAILER-DAEMON.
That is inaccurate. Postfix replaces the envelope sender ONLY when
delivering via the "pipe to command" interface, for example, when
you use the pipe mailer to send mail into a content filter.
If this is your problem, then I suggest that you use an SMTP or
LMTP based content filter which does not suffer from this limitation.
Wietse
> It also worries me that if an SMTP server sends me a bounce
> using the null sender, the bounce appears in my mailbox appearing to come
> from MY systems intead of theirs. I'd like a solution, though I don't know
> what's most appropriate. For example (and I know this doesn't mean it's
> right), under sendmail, there's no From or Reply to - if I reply to the
> message, the To: field is blank. Exim actually scans for the From: header
> and inserts that into the From field (that seems like an alarmingly bad
> thing to do). Is there anything I can do to emulate Sendmail's behavior
> without changing code? If not, can we discuss the problem and perhaps come
> to a permanent solution for future releases of Postfix?
>
> Thanks all!
>
> -=| Ben
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.0.1 (Build 2179)
>
> iQA/AwUBQpx6t1QK10CpvqFVEQKZ5ACfczTI+C+pR5IazLWtuZ0s5TnJUbsAnRmy
> MogMODKaWNMQZ1OlDdPFtDui
> =a073
> -----END PGP SIGNATURE-----
[ Attachment, skipping... ]
Ben Goodwin
------=_NextPart_000_005C_01C565D5.11452230
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
Forgot to Cc the list ...
Thanks for your quick reply Wietse! Comments in-line below.
> On the contrary, "MAIL FROM:<>" is required for SMTP error
> notifications, so that they cannot go into an infinite loop.
Understood, but these aren't bounce messages; for some reason, some sending
MTAs are sending out legitimate user-initiated mail as "MAIL FROM:<>" which
is why I question the behavior. I'm not sure what the MTA is (or perhaps
it's an MUA issue, or some gateway issue, who knows) at this point.
> That is inaccurate. Postfix replaces the envelope sender ONLY when
> delivering via the "pipe to command" interface, for example, when
> you use the pipe mailer to send mail into a content filter.
>
> If this is your problem, then I suggest that you use an SMTP or
> LMTP based content filter which does not suffer from this limitation.
Interesting; I'm using an SMTP-based filter (PureMessage) -
content_filter = pmx:127.0.0.1:10025
pmx unix - - n - 20 smtp
localhost:10026 inet n - n - 20 smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o myhostname=localhost
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
> telnet localhost 10026
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Postfix
EHLO localhost
250-localhost
250-PIPELINING
250-SIZE 26214400
250-VRFY
250-ETRN
250 8BITMIME
MAIL FROM:<>
250 Ok
RCPT TO: ben
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: "Ben" <b...@atomicmatrix.net>
Subject: Null Sender Test
foo
.
250 Ok: queued as E87DA190002
quit
221 Bye
> tail -15 /var/spool/mail/ben
From MAILER-DAEMON Tue May 31 11:18:58 2005
Return-Path: <>
X-Original-To: ben
Delivered-To: b...@phsmgmx1.partners.org
Received: from localhost (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with ESMTP id E87DA190002
for <ben>; Tue, 31 May 2005 11:17:28 -0400 (EDT)
From: "Ben" <b...@atomicmatrix.net>
Subject: Null Sender Test
Message-Id: <2005053115172...@phsmgmx1.partners.org>
Date: Tue, 31 May 2005 11:17:28 -0400 (EDT)
To: undisclosed-recipients:;
Foo
Could there be something in my config causing this? "postconf -n" attached,
but note the master.cf overrides on port 10026 from above. I'm testing with
10026 in order to bypass the content filter so there's no question about
whether it's the filter causing problems.
FWIW I just tried this on a default install of PF 215 (from the wl0.org RPM)
and the "From" header is still showing up as MAILER-DAEMON. I fear I'm
being stupid/ignorant or maybe there's an issue with those RPMs?
-=| Ben
------=_NextPart_000_005C_01C565D5.11452230
Content-Type: text/plain;
name="postconf.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="postconf.txt"
address_verify_map =3D btree:/var/spool/postfix/verify
address_verify_negative_cache =3D yes
address_verify_negative_expire_time =3D 1d
address_verify_negative_refresh_time =3D 3h
address_verify_poll_count =3D 3
address_verify_poll_delay =3D 3
address_verify_positive_expire_time =3D 31d
address_verify_positive_refresh_time =3D 7d
alias_database =3D hash:/etc/postfix/aliases
alias_maps =3D hash:/etc/postfix/aliases
command_directory =3D /usr/sbin
config_directory =3D /etc/postfix
content_filter =3D pmx:127.0.0.1:10025
daemon_directory =3D /usr/libexec/postfix
debug_peer_level =3D 2
default_process_limit =3D 150
html_directory =3D /usr/share/doc/postfix-2.1.5-documentation/html
mail_owner =3D postfix
mailq_path =3D /usr/bin/mailq.postfix
manpage_directory =3D /usr/share/man
message_size_limit =3D 26214400
mydestination =3D $myhostname localhost.$mydomain =
localhost
mynetworks =3D 127.0.0.0/8 132.183.0.0/16 =
155.52.0.0/16 170.223.0.0/16
newaliases_path =3D /usr/bin/newaliases.postfix
queue_directory =3D /var/spool/postfix
readme_directory =3D /usr/share/doc/postfix-2.1.5-documentation/readme
relay_domains =3D $mydestination /etc/postfix/relay_domains
sample_directory =3D /etc/postfix
sendmail_path =3D /usr/sbin/sendmail.postfix
setgid_group =3D postdrop
smtpd_recipient_restrictions =3D reject_unknown_recipient_domain =
reject_unknown_sender_domain =
check_recipient_access hash:/etc/postfix/verify_recipients_for =
permit_mynetworks reject_unauth_destination
smtpd_restriction_classes =3D verify_recipient
transport_maps =3D hash:/etc/postfix/transport
unknown_local_recipient_reject_code =3D 550
unverified_recipient_reject_code =3D 550
------=_NextPart_000_005C_01C565D5.11452230--
Victor Duchovni
> > tail -15 /var/spool/mail/ben
> From MAILER-DAEMON Tue May 31 11:18:58 2005
> Return-Path: <>
> X-Original-To: ben
> Delivered-To: b...@phsmgmx1.partners.org
> Received: from localhost (localhost.localdomain [127.0.0.1])
> by localhost (Postfix) with ESMTP id E87DA190002
> for <ben>; Tue, 31 May 2005 11:17:28 -0400 (EDT)
> From: "Ben" <b...@atomicmatrix.net>
> Subject: Null Sender Test
> Message-Id: <2005053115172...@phsmgmx1.partners.org>
> Date: Tue, 31 May 2005 11:17:28 -0400 (EDT)
> To: undisclosed-recipients:;
>
This is mbox format! Note the "Return-Path:". The message envelope
sender was empty (<>) as expected. The From_ line is of no significance.
--
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:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
Wietse Venema
> > tail -15 /var/spool/mail/ben
> From MAILER-DAEMON Tue May 31 11:18:58 2005
> Return-Path: <>
> X-Original-To: ben
> Delivered-To: b...@phsmgmx1.partners.org
That is a mailbox file!
And you claim that Sendmail produces a first line without address?
Wietse
Ralf Hildebrandt
> Understood, but these aren't bounce messages; for some reason, some sending
> MTAs are sending out legitimate user-initiated mail as "MAIL FROM:<>" which
> is why I question the behavior.
That Outlook does it: The read notifications are sent that way.
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
http://www.postfix-book.com/ Tel. +49 (0)30-450 570-155
He may look like an idiot and talk like an idiot but don't let that
fool you. He really is an idiot. - Groucho Marx
Ben Goodwin
Hash: SHA1
I'd written up a long email but as I dug for data for the email, I think =
I found out what's going on.
Assume incoming mail converstation is "MAIL FROM:<>" and no "From:" =
header.
PF creates "From: MAILER-DAEMON" and passes this to the content filter. =
The content filter doesn't touch either of the From headers. The =
content filter passes this mail back to PF which now sees a "From: =
MAILER-DAEMON" header and appends its hostname like it's configured to. =
The message goes out as "MAILER-DAEMON@hostname" due to the double-pass =
the content filter requires. What's the appropriate solution (master.cf =
option) for PF 215? Should I be setting append_at_myorigin to no on =
port 10026?
Thanks,
-=3D| Ben=20
- -----Original Message-----
From: Wietse Venema [mailto:wie...@porcupine.org]=20
Sent: Tuesday, May 31, 2005 12:25 PM
To: Ben Goodwin
Cc: postfi...@postfix.org
Subject: Re: Additional discussion: null sender -> MAILER-DAEMON
Ben Goodwin:
> > tail -15 /var/spool/mail/ben
> From MAILER-DAEMON Tue May 31 11:18:58 2005
> Return-Path: <>
> X-Original-To: ben
> Delivered-To: b...@phsmgmx1.partners.org
That is a mailbox file! =20
And you claim that Sendmail produces a first line without address?
Wietse
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.1 (Build 2179)
iQA/AwUBQpyn5FQK10CpvqFVEQL93QCg3m/Sg+8UoaWL/vZe+GbPLiRQxg4AoIBr
teq60YWzsrlrf73F61K+pjpa
=3DQZg7
-----END PGP SIGNATURE-----
Wietse Venema
> I'd written up a long email but as I dug for data for the email, I think I found out what's going on.
>
> Assume incoming mail converstation is "MAIL FROM:<>" and no "From:" header.
>
> PF creates "From: MAILER-DAEMON" and passes this to the content filter. T
>-he content filter doesn't touch either of the From headers. The content fil
>-ter passes this mail back to PF which now sees a "From: MAILER-DAEMON" heade
>-r and appends its hostname like it's configured to. The message goes out as
>- "MAILER-DAEMON@hostname" due to the double-pass the content filter requires
>-. What's the appropriate solution (master.cf option) for PF 215? Should I
>-be setting append_at_myorigin to no on port 10026?
Postfix 2.2 and later has an option to disable message header
address rewriting.
http://www.postfix.org/postconf.5.html#local_header_rewrite_clients
http://www.postfix.org/ADDRESS_REWRITING_README.html#william
The FROM: header is required by RFC 822 and RFC 2822; there currently
is no feature to prevent Postfix from adding one that's missing,
nor is the format of the added header configurable at this time.
Postfix 2.2 and later has a header_checks action that can REPLACE
one message header by another one, but that is just one workaround
instead of a solution.
Wietse
Ben Goodwin
Hash: SHA1
Instead of having Postfix fill in the gaps when it comes to RFC's and =
the FROM: header, would it be wise to reject the mail after the DATA =
conversation completes if there's no valid FROM: header? Could I use =
header_checks(5) (or are header_checks even done before Postfix adds a =
missing FROM: header)?
-=3D| Ben=20
- -----Original Message-----
From: owner-pos...@postfix.org =
[mailto:owner-pos...@postfix.org] On Behalf Of Wietse Venema
Sent: Tuesday, May 31, 2005 2:24 PM
To: Postfix users
Subject: Re: Additional discussion: null sender -> MAILER-DAEMON
Postfix 2.2 and later has an option to disable message header=20
address rewriting.
http://www.postfix.org/postconf.5.html#local_header_rewrite_clients
http://www.postfix.org/ADDRESS_REWRITING_README.html#william
The FROM: header is required by RFC 822 and RFC 2822; there currently
is no feature to prevent Postfix from adding one that's missing,
nor is the format of the added header configurable at this time.
Postfix 2.2 and later has a header_checks action that can REPLACE
one message header by another one, but that is just one workaround
instead of a solution.
Wietse
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.1 (Build 2179)
iQA/AwUBQp3pJ1QK10CpvqFVEQIBCACgpF2hB+9i2WK/ByIInYb+685mV7sAoP8R
UMVEFxdh0MKaU1f5NYuZELu2
=3DnGI7
-----END PGP SIGNATURE-----
Noel Jones
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
> -=| Ben
A year or so ago I experimented with rejecting mail with
existing-but-invalid From: headers and found many otherwise valid messages
(mostly mail lists) would be rejected, so was not able to reject based on
badly formed headers. If memory serves me, over half of the messages
detected with bad From: headers were non-spam - far too much collateral
damage to be a useful test.
I strongly suspect the same for missing From: headers, but no way currently
exists to trigger an action based on a missing required
header. Header_checks, which examine each line independently, cannot
detect and are not designed to detect missing headers.
So no, it would probably not be wise to reject mail due to a missing From:
header, and regardless, there is no way to do this without modifying the
source.
--
Noel Jones