receiving duplicate (or more) copies of email

[Juan Pablo]

Hello,

I am wondering if someone can point me in direction of troubleshooting 
this.


For the past week we have been receiving some emails as duplicates or 
more, some times up to 6 or 7 times.
These multiple copes can be received from any host (eg, skype.com, 
linkedin.com, yahoo, gmail or some corporate services).


From what I can see in the logs, the remote mail server is connecting 
multiple times but for what reason I am not sure


I only have one MX accessible, so it's not coming in via multiple 
sources


Logs for a yahoo.fr email as an example is the following (logs have been 
sanitized):


Jun 11 21:34:13 mailsrv postfix/smtpd[30440]: connect from 
nm11-vm3.bullet.mail.ir2.yahoo.com[212.82.96.164]
Jun 11 21:34:13 mailsrv postfix/smtpd[30440]: setting up TLS connection 
from nm11-vm3.bullet.mail.ir2.yahoo.com[212.82.96.164]
Jun 11 21:34:13 mailsrv postfix/smtpd[30488]: connect from 
nm11-vm8.bullet.mail.ir2.yahoo.com[212.82.96.169]
Jun 11 21:34:14 mailsrv postfix/smtpd[30488]: setting up TLS connection 
from nm11-vm8.bullet.mail.ir2.yahoo.com[212.82.96.169]
Jun 11 21:34:14 mailsrv postfix/smtpd[30440]: Anonymous TLS connection 
established from nm11-vm3.bullet.mail.ir2.yahoo.com[212.82.96.164]: 
TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Jun 11 21:34:14 mailsrv postfix/smtpd[30488]: Anonymous TLS connection 
established from nm11-vm8.bullet.mail.ir2.yahoo.com[212.82.96.169]: 
TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Jun 11 21:34:14 mailsrv postfix/smtpd[30440]: 264B6B11D: 
client=nm11-vm3.bullet.mail.ir2.yahoo.com[212.82.96.164]
Jun 11 21:34:14 mailsrv postfix/cleanup[30492]: 264B6B11D: 
message-id=<1402568771.40464.yahoomail...@web172301.mail.ir2.yahoo.com>
Jun 11 21:34:14 mailsrv postfix/smtpd[30488]: C49551042: 
client=nm11-vm8.bullet.mail.ir2.yahoo.com[212.82.96.169]
Jun 11 21:34:15 mailsrv postfix/cleanup[30491]: C49551042: 
message-id=<1402568771.40464.yahoomail...@web172301.mail.ir2.yahoo.com>
Jun 11 21:34:16 mailsrv postfix/qmgr[29330]: 264B6B11D: 
from=, size=608582, nrcpt=1 (queue active)
Jun 11 21:34:16 mailsrv postfix/smtpd[30440]: disconnect from 
nm11-vm3.bullet.mail.ir2.yahoo.com[212.82.96.164]
Jun 11 21:34:16 mailsrv postfix/smtpd[30500]: connect from 
localhost[127.0.0.1]
Jun 11 21:34:16 mailsrv postfix/smtpd[30500]: D12E6C045: 
client=localhost[127.0.0.1]
Jun 11 21:34:16 mailsrv postfix/cleanup[30493]: D12E6C045: 
message-id=<1402568771.40464.yahoomail...@web172301.mail.ir2.yahoo.com>
Jun 11 21:34:16 mailsrv postfix/qmgr[29330]: D12E6C045: 
from=, size=609073, nrcpt=1 (queue active)
Jun 11 21:34:16 mailsrv postfix/smtpd[30500]: disconnect from 
localhost[127.0.0.1]
Jun 11 21:34:16 mailsrv postfix/smtp[30497]: 264B6B11D: 
to=, relay=127.0.0.1[127.0.0.1]:10024, 
delay=2.5, delays=2/0/0/0.51, dsn=2.6.0, status=sent (250 2.6.0 Ok, 
id=30520-03, from MTA: 250 2.0.0 Ok: queued as D12E6C045)

Jun 11 21:34:16 mailsrv postfix/qmgr[29330]: 264B6B11D: removed
Jun 11 21:34:16 mailsrv postfix/qmgr[29330]: C49551042: 
from=, size=608577, nrcpt=1 (queue active)
Jun 11 21:34:17 mailsrv postfix/smtp[30502]: D12E6C045: 
to=, relay=10.10.2.2[10.10.2.2]:25, 
delay=0.2, delays=0.07/0/0/0.12, dsn=2.0.0, status=sent (250 2.0.0 Ok: 
queued as E72551220061)

Jun 11 21:34:17 mailsrv postfix/qmgr[29330]: D12E6C045: removed
Jun 11 21:34:17 mailsrv postfix/smtpd[30488]: disconnect from 
nm11-vm8.bullet.mail.ir2.yahoo.com[212.82.96.169]
Jun 11 21:34:17 mailsrv postfix/smtpd[30500]: connect from 
localhost[127.0.0.1]
Jun 11 21:34:17 mailsrv postfix/smtpd[30500]: 32882C01D: 
client=localhost[127.0.0.1]
Jun 11 21:34:17 mailsrv postfix/cleanup[30492]: 32882C01D: 
message-id=<1402568771.40464.yahoomail...@web172301.mail.ir2.yahoo.com>
Jun 11 21:34:17 mailsrv postfix/qmgr[29330]: 32882C01D: 
from=, size=609068, nrcpt=1 (queue active)
Jun 11 21:34:17 mailsrv postfix/smtpd[30500]: disconnect from 
localhost[127.0.0.1]
Jun 11 21:34:17 mailsrv postfix/smtp[30494]: C49551042: 
to=, 
orig_to=, 
relay=127.0.0.1[127.0.0.1]:10024, delay=2.6, delays=2.3/0/0/0.3, 
dsn=2.6.0, status=sent (250 2.6.0 Ok, id=30484-10, from MTA: 250 2.0.0 
Ok: queued as 32882C01D)

Jun 11 21:34:17 mailsrv postfix/qmgr[29330]: C49551042: removed
Jun 11 21:34:17 mailsrv postfix/smtp[30507]: 32882C01D: 
to=, relay=10.10.2.2[10.10.2.2]:25, 
delay=0.19, delays=0.08/0/0/0.11, dsn=2.0.0, status=sent (250 2.0.0 Ok: 
queued as 4978B1220071)

Jun 11 21:34:17 mailsrv postfix/qmgr[29330]: 32882C01D: removed

Re: Postfix-DSN support

[Wietse Venema]

hyndavirap...@bel.co.in:
> getting delivered to sender inbox. when Relay server forwards the mail to
> actual destination, Sender is not getting any notification. 

Ask the remote system administrator why they aren't sending DSN.

Wietse

Re: How to deal with erroneous Return-Paths?

[Wietse Venema]

Michael Neurohr:
> Hi,
> the German Free Mailer GMX sends its newsletters with a Return-Path
> like "#16155...@gmx.net".
> I also recognized that sometimes the sending mail server does not
> provide a Return-Path at all.

The Return-Path: header is CREATED upon final delivery.

The Return-Path: header is IGNORED while receiving mail.

The value in the Return-Path: header is the envelope sender address
(see Wikipedia), i.e. the address in the MAIL FROM command during
an SMTP session.

If you use mail software that mis-handles addresses such as
"#16155...@gmx.net" then you need to use better mail software. 

In the address local-part, the "#" character is not special according
to RFC 5321, the SMTP mail standard, or RFC 5322, the Internet
message standard.

Wietse

Strange in maillog

[Konstantin]

Hello,

I found that sometimes my postfix-2.11.0 write following in maillog
Today postfix logged ~ 5000 of rec_get messages to maillog in 1 sec only.
Please advice how to stop this.

Jun  8 11:37:38 server postfix/smtpd[21385]: rec_get: type R len 2 data 50
Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024:
250-ENHANCEDSTATUSCODES
Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024: 250-8BITMIME
Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024: 250-DSN
Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024: 250
XFORWARD NAME ADDR PORT PROTO HELO IDENT SOURCE
Jun  8 11:37:38 server postfix/smtpd[21385]: > 127.0.0.1:10024: XFORWARD
NAME=d216.mailgun.info ADDR=50.23.218.216 PORT=52871 HELO=d216.mailgun.info
IDENT=[UNAVAILABLE] PROTO=ESMTP SOURCE=REMOTE
Jun  8 11:37:38 server postfix/smtpd[21385]: vstream_fflush_some: fd 25
flush 132
Jun  8 11:37:38 server postfix/smtpd[21385]: vstream_buf_get_ready: fd 25
got 23
Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024: 250 2.5.0
Ok XFORWARD
Jun  8 11:37:38 server postfix/smtpd[21385]: > 127.0.0.1:10024: MAIL
FROM: BODY=8BITMIME
Jun  8 11:37:38 server postfix/smtpd[21385]: vstream_fflush_some: fd 25
flush 83
Jun  8 11:37:38 server postfix/smtpd[21385]: vstream_buf_get_ready: fd 25
got 79
Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024: 250 2.1.0
Sender  OK
Jun  8 11:37:38 server postfix/smtpd[21385]: vstream_buf_get_ready: fd 26
got 4096
Jun  8 11:37:38 server postfix/smtpd[21385]: rec_get: type R len 2 data 50
Jun  8 11:37:38 server postfix/smtpd[21385]: rec_get: type S len 27 data
RCPT TO: 127.0.0.1:10024: RCPT
TO:
Jun  8 11:37:38 server postfix/smtpd[21385]: vstream_fflush_some: fd 25
flush 29
Jun  8 11:37:38 server postfix/smtpd[21385]: vstream_buf_get_ready: fd 25
got 44
Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024: 250 2.1.5
Recipient  OK
Jun  8 11:37:38 server postfix/smtpd[21385]: rec_get: type R len 2 data 51
Jun  8 11:37:38 server postfix/smtpd[21385]: rec_get: type S len 4 data DATA
Jun  8 11:37:38 server postfix/smtpd[21385]: > 127.0.0.1:10024: DATA
Jun  8 11:37:38 server postfix/smtpd[21385]: vstream_fflush_some: fd 25
flush 6

-- 
*This message was delivered using 100% recycled electrons*.

Re: Strange in maillog

[li...@rhsoft.net]

Am 12.06.2014 14:00, schrieb Konstantin:
> I found that sometimes my postfix-2.11.0 write following in maillog
> Today postfix logged ~ 5000 of rec_get messages to maillog in 1 sec only.
> Please advice how to stop this.
> 
> Jun  8 11:37:38 server postfix/smtpd[21385]: rec_get: type R len 2 data 50
> Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 
> : 250-ENHANCEDSTATUSCODES
> Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 
> : 250-8BITMIME
> Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 
> : 250-DSN
> Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 
> : 250 XFORWARD NAME ADDR

why do you enable debug logging?

Re: Postfix-DSN support

[hyndavirapuru]

Hi,

  Thanks for the reply. I have only configured the whole setup. I am
getting DSN from relay server to sender but not from the destination.

I have a basic question.. how to enable DSN by default in postfix?

Thanks and regards
Hyndvai




> hyndavirap...@bel.co.in:
>> getting delivered to sender inbox. when Relay server forwards the mail
>> to
>> actual destination, Sender is not getting any notification.
>
> Ask the remote system administrator why they aren't sending DSN.
>
>   Wietse
>



Every 3000 Sheets of paper costs us a tree.. Save trees... Conserve 
Trees. Don't print this email or any Files unless you really need to 
Confidentiality Notice

The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of
the addressee(s) and may contain confidential or privileged 
information. If you are not the intended recipient, please notify
the sender at Bharat Electronics  or supp...@bel.co.in immediately
and destroy all copies of this message and any attachments.

Re: Postfix-DSN support

[Wietse Venema]

hyndavirap...@bel.co.in:
> Thanks for the reply. I have only configured the whole setup. I am
> getting DSN from relay server to sender but not from the destination.

If the relay sends a DSN for success, the remote system won't send one.

If the relay sends a DSN for failure, the remote system won't send one.

DSN for SMTP is defined in RFC 3461. I am not making up this stuff.

Wietse

Re: Strange in maillog

[Konstantin]

I did not enable debug logging.
As i wrote these messages appear from time to time. Not all the time.


2014-06-12 15:07 GMT+03:00 li...@rhsoft.net :

>
> Am 12.06.2014 14:00, schrieb Konstantin:
> > I found that sometimes my postfix-2.11.0 write following in maillog
> > Today postfix logged ~ 5000 of rec_get messages to maillog in 1 sec only.
> > Please advice how to stop this.
> >
> > Jun  8 11:37:38 server postfix/smtpd[21385]: rec_get: type R len 2 data
> 50
> > Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 <
> http://127.0.0.1:10024>: 250-ENHANCEDSTATUSCODES
> > Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 <
> http://127.0.0.1:10024>: 250-8BITMIME
> > Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 <
> http://127.0.0.1:10024>: 250-DSN
> > Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 <
> http://127.0.0.1:10024>: 250 XFORWARD NAME ADDR
>
> why do you enable debug logging?
>



-- 
*This message was delivered using 100% recycled electrons*.

Re: Strange in maillog

[li...@rhsoft.net]

Am 12.06.2014 16:05, schrieb Konstantin:
> I did not enable debug logging
> As i wrote these messages appear from time to time. Not all the time.

*you did*

the commands you also have in your maillog are normally *not*
logged at all (250-ENHANCEDSTATUSCODES, vstream_fflush_some:
fd 25 flush 29 and so on) and if you would

a) not post HTML
b) not top-post
c) not use reply-all
d) do what the welcome message states and provide "postconf -n" output

things would be more readable and somebody could even say you which
exact line in your config enables debug logging, but even
without anbyody can see that you have debug log enabled

> 2014-06-12 15:07 GMT+03:00 li...@rhsoft.net  
> mailto:li...@rhsoft.net>>:
> 
> 
> Am 12.06.2014 14:00, schrieb Konstantin:
> > I found that sometimes my postfix-2.11.0 write following in maillog
> > Today postfix logged ~ 5000 of rec_get messages to maillog in 1 sec 
> only.
> > Please advice how to stop this.
> >
> > Jun  8 11:37:38 server postfix/smtpd[21385]: rec_get: type R len 2 data 
> 50
> > Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 
> 
> : 250-ENHANCEDSTATUSCODES
> > Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 
> 
> : 250-8BITMIME
> > Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 
> 
> : 250-DSN
> > Jun  8 11:37:38 server postfix/smtpd[21385]: < 127.0.0.1:10024 
> 
> : 250 XFORWARD NAME ADDR
> 
> why do you enable debug logging?

Re: Strange in maillog

[Wietse Venema]

Konstantin:
> Jun  8 11:37:38 server postfix/smtpd[21385]: > 127.0.0.1:10024: XFORWARD
> NAME=d216.mailgun.info ADDR=50.23.218.216 PORT=52871 HELO=d216.mailgun.info
> IDENT=[UNAVAILABLE] PROTO=ESMTP SOURCE=REMOTE

You have "smtpd -v" logging turned on in master.cf, or you have
"debug_peer_list" turned on in main.cf.

Wietse

Re: How to deal with erroneous Return-Paths?

[Wietse Venema]

Michael Neurohr:
> On 12.06.2014 13:19, Wietse Venema wrote:
> > If you use mail software that mis-handles addresses such as
> > "#16155...@gmx.net" then you need to use better mail software. 
> 
> The point is, that I'm passing the mail from Postfix with the command
> /usr/bin/procmail -m E_SENDER=${sender} E_RECIPIENT=${recipient} 
> /etc/procmailrc
> to procmail.

And because procmail mis-handles "#16155...@gmx.net", you are on the
wrong mailing list to complain about that.

Wietse

Re: How to deal with erroneous Return-Paths?

[Michael Neurohr]

On 12.06.2014 13:19, Wietse Venema wrote:
> If you use mail software that mis-handles addresses such as
> "#16155...@gmx.net" then you need to use better mail software. 

The point is, that I'm passing the mail from Postfix with the command

/usr/bin/procmail -m E_SENDER=${sender} E_RECIPIENT=${recipient}
/etc/procmailrc

to procmail.

After processing with procmail I'm injecting the mail back to Postfix
with the command

| /usr/sbin/sendmail -i -f $E_SENDER $E_RECIPIENT



The problem now is, that if the variable "E_SENDER" is empty or contains
"#", Procmail passes an empty variable to Sendmail which causes Sendmail
to fail.

Is it the correct way at all to pass the envelope sender address that I
got from Postfix back to Sendmail after processing with Procmail, or
should I rather do something different?

Thanks,
Michael

Re: How to block offering SASL auth to clients based on RBL

[Alex JOST]

Am 11.06.2014 21:17, schrieb Kai Krakow:

   * mbox server: handle pop3 and imap requests from users
   * accepts no external traffic, just from mailout / bulkmail
   * just a receiver for local domains
   * maybe handle dovecot outgoing mails (thou we didn't support anyway)



Any ideas/suggestions? Do you see problems?


When using Dovecot you should consider migrating away from mbox as 
suggested by the developer.

http://dovecot.org/list/dovecot/2014-May/096318.html

--
Alex JOST

Re: How to deal with erroneous Return-Paths?

[Michael Neurohr]

Although it's not a Postfix problem, I'd like to share the solution just
for completeness in the hope it might be useful.

Instead of setting sender and recipient as parameters, one should
forward it as arguments.

The whole thing now looks as follows:

The filter definition in Postfix' master.cf:
=
procmail  unix  -   n   n   -   10   pipe
  flags=Rq user=vmail null_sender= argv=/usr/bin/procmail -m
/etc/procmailrc ${sender} ${recipient} ${domain}
=
Whereas the "q" at flags is very important to get it working.

The /etc/procmailrc contains:
=
SHELL=/bin/sh
E_SENDER=$1
E_RECIPIENT=$2
ER_DOMAIN=$3
SENDMAILFLAGS="-i -f $E_SENDER $E_RECIPIENT"
LOGFILE="/var/log/procmail"
VERBOSE=on

# First make a backup of the mail
:0c:
/var/mail/vhosts/backup-mail/$E_RECIPIENT/

# Scan for viruses
:0fw
| /usr/local/bin/clamassassin

# If no virus has been found, scan for Spam
:0fw
* ^X-Virus-Status: No
| /usr/bin/spamassassin

:0w
* !E_SENDER ?? (.)
| /usr/sbin/sendmail -i -f noreplay@$ER_DOMAIN $E_RECIPIENT

# Last action: inject back to Postfix
:0w
| /usr/sbin/sendmail $SENDMAILFLAGS
=

E_SENDER=$1, E_RECIPIENT=$2 and ER_DOMAIN=$3 are assigning the command
line arguments.

"* !E_SENDER ?? (.)" checks if the variable "E_SENDER" is empty. If it
is empty, we need to adopt the Sendmail command.

If "!E_SENDER ?? (.)" evaluates to true, the Procmail execution ends
after invoking Sendmail, otherwise it executes the last action.

HTH,
Michael

Re: How to deal with erroneous Return-Paths?

[Wietse Venema]

Michael Neurohr:
> Although it's not a Postfix problem, I'd like to share the solution just
> for completeness in the hope it might be useful.
> 
> Instead of setting sender and recipient as parameters, one should
> forward it as arguments.
> 
> The whole thing now looks as follows:
> 
> The filter definition in Postfix' master.cf:
> =
> procmail  unix  -   n   n   -   10   pipe
>   flags=Rq user=vmail null_sender= argv=/usr/bin/procmail -m
> /etc/procmailrc ${sender} ${recipient} ${domain}

...
> ER_DOMAIN=$3
> SENDMAILFLAGS="-i -f $E_SENDER $E_RECIPIENT"

WARNING: THIS WILL LOSE MAIL when the message has more than one recipient.
You must specify "procmail_destination_recipient_limit=1" in main.cf.

Wietse

Quote 1 from pipe(8) manpage:

SINGLE-RECIPIENT DELIVERY
   Some destinations cannot handle more than one  recipient  per  delivery
   request.  Examples  are  pagers  or  fax machines.  In addition, multi-
   recipient delivery is undesirable when prepending a Delivered-to: or X-
   Original-To: message header.

   To  prevent  Postfix  from  sending  multiple  recipients  per delivery
   request, specify

   transport_destination_recipient_limit = 1

   in the Postfix main.cf file, where transport is the name in  the  first
   column  of  the  Postfix  master.cf  entry  for the pipe-based delivery
   transport.

Quote 2 from the pipe(8) manpage:

  ${recipient}
 This macro expands to the complete recipient address.

 A   command-line   argument  that  contains  ${recipient}
 expands to as many command-line arguments  as  there  are
 recipients.

Presumably, this also applies to the ${domain} expansion.

Re: receiving duplicate (or more) copies of email

[Viktor Dukhovni]

On Thu, Jun 12, 2014 at 10:44:36AM +, Juan Pablo wrote:

> Jun 11 21:34:16 mailsrv postfix/smtp[30497]: 264B6B11D:
> to=, relay=127.0.0.1[127.0.0.1]:10024,
> delay=2.5, delays=2/0/0/0.51, dsn=2.6.0, status=sent (250 2.6.0 Ok,
> id=30520-03, from MTA: 250 2.0.0 Ok: queued as D12E6C045)

> Jun 11 21:34:17 mailsrv postfix/smtp[30494]: C49551042:
> to=,
> orig_to=,
> relay=127.0.0.1[127.0.0.1]:10024, delay=2.6, delays=2.3/0/0/0.3, dsn=2.6.0,
> status=sent (250 2.6.0 Ok, id=30484-10, from MTA: 250 2.0.0 Ok: queued as
> 32882C01D)

These were separate envelope recipients of the same message. Notice
"local-recipient-alias" vs. "local-recipient".  The remote system
had no way to know they are the same mailbox.

-- 
Viktor.