Re: No From: address in policy delegation protocol?

[Zhang Huangbin]

> On Jun 28, 2016, at 11:15 PM, Wietse Venema  wrote:
> 
> To examine SMTP-level events AND message content, use one of the
> methods described in MILTER_README, SMTPD_PROXY_README, or FILTER_README.

Dear Wietse,

Thanks very much for showing me the direction. :)


Zhang Huangbin, founder of iRedMail project: http://www.iredmail.org/
Time zone: GMT+8 (China/Beijing).

Re: Is not honoring bounces-to violation of RFC?

[Daniele Nicolodi]

On 6/28/16 2:01 PM, Chip wrote:
> My mistake NOT "bounces-to" rather "return-path"

This is not a subtle difference. The Return-Path header gets added (or
replaced, in the case it is already there) by the receiving MTA with the
MAIL FROM address. It is placed there only for convenience of the
receiving part.

Setting the Return-Path header on outbound messages has no effect. What
you need to change is the MAIL FROM address, as already explained a few
times in this thread.

Cheers,
Daniele

Re: Is not honoring bounces-to violation of RFC?

[Chip]

My mistake NOT "bounces-to" rather "return-path" as in the following 
snippet of campaign emails from Home Depot, Martha Stewart and Sears:


From - Mon Jun 20 08:43:03 2016
X-Account-Key: account15
X-UIDL: UID1962-1324328699
X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys:
Return-path:


From - Tue Jun 21 14:39:36 2016

X-Account-Key: account15
X-UIDL: UID1969-1324328699
X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys:
Return-path:


From - Mon Jun 20 08:43:02 2016

X-Account-Key: account15
X-UIDL: UID1961-1324328699
X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys:
Return-path:


So is "Return-path" supposed to be respected?  Because the company I was 
speaking of insists it's appropriate to send bounces to something other 
than "Return-path" usually the "From" or "Reply-to".




On 06/28/2016 03:36 PM, Jim Reid wrote:

On 28 Jun 2016, at 20:26, Jeffs Chips  wrote:

I'm just saying that ALL email campaign services allow and indeed suggest users 
to identity a specific sole purpose email account in which to receive bounces 
to eliminate spam and which almost all email campaigners adhere to

The IETF process is open to all. Feel free to make use of it.

BTW, the IETF is where Internet email protocols get developed and documented. 
It doesn’t and can’t happen on postfix-users.

Re: Is not honoring bounces-to violation of RFC?

[Jim Reid]

> On 28 Jun 2016, at 20:26, Jeffs Chips  wrote:
> 
> I'm just saying that ALL email campaign services allow and indeed suggest 
> users to identity a specific sole purpose email account in which to receive 
> bounces to eliminate spam and which almost all email campaigners adhere to

The IETF process is open to all. Feel free to make use of it.

BTW, the IETF is where Internet email protocols get developed and documented. 
It doesn’t and can’t happen on postfix-users. 

Re: Is not honoring bounces-to violation of RFC?

[Jeffs Chips]

I don't dispute any of what happens just saying that a company out there
that advertises as their mission to eliminate spam and whom, they
advertise, has access to 30 million MX records is sending bounces to the
reply to or envelope sender whereas I'm just saying that ALL email campaign
services allow and indeed suggest users to identity a specific sole purpose
email account in which to receive bounces to eliminate spam and which
almost all email campaigners adhere to, is thus defeating the purpose of
there mission. Maybe what they do works for the small time spammer who uses
a personal account to distribute spam but it defeats the purpose of
eliminating non deliverables for honest mailers.
On Jun 28, 2016 3:17 PM, "Allen Coates"  wrote:

> Mail-server refusals (as in NOQUEUE) are generated before the email body
> is received - and will also be sent to the envelope sender.
>
> On 28/06/16 18:51, Noel Jones wrote:
> > On 6/28/2016 12:12 PM, Chip wrote:
> >> Meaning there are no standards for the way
> >> emailers should respond to bounces?
> > bounces always go to the envelope sender, regardless of any
> > unrelated junk in the headers.
> >
> >
> >
> >
>
>

Re: Is not honoring bounces-to violation of RFC?

[Jim Reid]

> On 28 Jun 2016, at 19:28, Chip  wrote:
> 
> Okay maybe it's not in RFC's but I would it would be at least a 
> recommendation that bounces can be routed back to bounces-to rather than 
> reply-to.  After all, why have the field at all if it's not used properly.

No RFC defines a bounces-to email header. Or how an MTA or MUA should handle 
one. As a matter of fact, the only email-related RFC which contains the word 
“bounce” is RFC5355. Which is in the Experimental category. It uses “bounce" in 
the context of clients speaking UTF8SMTP to servers that don’t support this 
feature.

Here’s the relevant part of Section 4.4 of that RFC:

  Below are a few examples of possible  representations.

  ...

  "DISPLAY_NAME" 
 ; UTF8SMTP but no ALT-ADDRESS parameter provided,
 ; message will bounce if UTF8SMTP extension is not supported

  
 ; without DISPLAY_NAME and quoted string
 ; UTF8SMTP but no ALT-ADDRESS parameter provided,
 ; message will bounce if UTF8SMTP extension is not supported


If you think bounces-to has to be part of Internet email standards, feel free 
to write up a draft and submit it to the IETF.

Re: Is not honoring bounces-to violation of RFC?

[Allen Coates]

Mail-server refusals (as in NOQUEUE) are generated before the email body
is received - and will also be sent to the envelope sender.

On 28/06/16 18:51, Noel Jones wrote:
> On 6/28/2016 12:12 PM, Chip wrote:
>> Meaning there are no standards for the way
>> emailers should respond to bounces?
> bounces always go to the envelope sender, regardless of any
> unrelated junk in the headers.
>
>
>
>

Re: Is not honoring bounces-to violation of RFC?

[Noel Jones]

Bounces go to the envelope sender, the address used in the SMTP MAIL
FROM command.

Not reply-to, nor bounces-to, nor any other address listed in a
header.

To control where bounces are returned, set the envelope sender.



  -- Noel Jones


On 6/28/2016 1:28 PM, Chip wrote:
> In standard email campaign software like phplist, constantcontact,
> mailchimp all of those popular email campaign software many of which
> use Exim and are used literally by millions of email campaigners,
> the bounces-to is where bounces are expected to be returned so that
> they can be effectively removed from mailings and people don't'
> receive spam.  It is an very important part of email campaigns and
> reduces by great amounts the amount of spam that is manufactured.
> 
> Okay maybe it's not in RFC's but I would it would be at least a
> recommendation that bounces can be routed back to bounces-to rather
> than reply-to.  After all, why have the field at all if it's not
> used properly.
> 
> 
> 
> 
> On 06/28/2016 01:51 PM, Noel Jones wrote:
>> On 6/28/2016 12:12 PM, Chip wrote:
>>> Meaning there are no standards for the way
>>> emailers should respond to bounces?
>> bounces always go to the envelope sender, regardless of any
>> unrelated junk in the headers.
>>
>>
>>
>>
> 

Re: Is not honoring bounces-to violation of RFC?

[Chip]

In standard email campaign software like phplist, constantcontact, 
mailchimp all of those popular email campaign software many of which use 
Exim and are used literally by millions of email campaigners, the 
bounces-to is where bounces are expected to be returned so that they can 
be effectively removed from mailings and people don't' receive spam.  It 
is an very important part of email campaigns and reduces by great 
amounts the amount of spam that is manufactured.


Okay maybe it's not in RFC's but I would it would be at least a 
recommendation that bounces can be routed back to bounces-to rather than 
reply-to.  After all, why have the field at all if it's not used properly.





On 06/28/2016 01:51 PM, Noel Jones wrote:

On 6/28/2016 12:12 PM, Chip wrote:

Meaning there are no standards for the way
emailers should respond to bounces?

bounces always go to the envelope sender, regardless of any
unrelated junk in the headers.

Re: Is not honoring bounces-to violation of RFC?

[Noel Jones]

On 6/28/2016 12:12 PM, Chip wrote:
> Meaning there are no standards for the way
> emailers should respond to bounces?

bounces always go to the envelope sender, regardless of any
unrelated junk in the headers.

Re: Is not honoring bounces-to violation of RFC?

[Wietse Venema]

Chip:
> Okay I guess it does.  Meaning there are no standards for the way 
> emailers should respond to bounces?

According to RFC 5321, the definition of the Internet email protocol,
an undeliverable email message is returned to its MAIL FROM address,
and that return message is sent with the null MAIL FROM adress.
Undeliverable mail with the null MAIL FROM address is not returned.

That answers your question, but you probably meant something else.

Wietse

Re: Is not honoring bounces-to violation of RFC?

[Chip]

Okay I guess it does.  Meaning there are no standards for the way 
emailers should respond to bounces?


On 06/28/2016 12:54 PM, Wietse Venema wrote:

Chip:

I know this question is not specifically germane to Postfix but everyone
on this list has extensive experience with bouncing policies.

If a receiver of campaign emails (that promotes itself as an email
security service) sends bounces to "reply-to" rather than "bounces-to"
as a policy despite bounces-to present in all campaign emails headers,
would this be considered a violation of RFCs?

RFCs are published at ietf.org, so I did an experiment:

site:ietf.org bounces-to

Neither google.com nor bing.com produced any matches.

I guess that result speaks for itself, no?

Wietse

Re: Is not honoring bounces-to violation of RFC?

[Wietse Venema]

Chip:
> I know this question is not specifically germane to Postfix but everyone 
> on this list has extensive experience with bouncing policies.
> 
> If a receiver of campaign emails (that promotes itself as an email 
> security service) sends bounces to "reply-to" rather than "bounces-to" 
> as a policy despite bounces-to present in all campaign emails headers, 
> would this be considered a violation of RFCs?

RFCs are published at ietf.org, so I did an experiment:

site:ietf.org bounces-to

Neither google.com nor bing.com produced any matches.

I guess that result speaks for itself, no?

Wietse

Is not honoring bounces-to violation of RFC?

[Chip]

I know this question is not specifically germane to Postfix but everyone 
on this list has extensive experience with bouncing policies.


If a receiver of campaign emails (that promotes itself as an email 
security service) sends bounces to "reply-to" rather than "bounces-to" 
as a policy despite bounces-to present in all campaign emails headers, 
would this be considered a violation of RFCs?

Re: No From: address in policy delegation protocol?

[Wietse Venema]

Zhang Huangbin:
> 
> > On Jun 28, 2016, at 2:15 PM, Benning, Markus  wrote:
> > 
> > Policy service is just a table lookup. From what restriction do you call
> > the policy lookup?
> 
> Postfix is configured to call the policy server at protocol state RCPT
> (smtpd_recipient_restrictions) and END-OF-MESSAGE
> (smtpd_end_of_data_restrictions).
> 
> I understand what a policy service does, just want to know whether
> or not Postfix parses the submitted mail message to get 'From:'
> address and send it to policy server. This is not mentioned in Postfix
> doc: http://www.postfix.org/SMTPD_POLICY_README.html

If it is not documented, then it is not supported.

To examine SMTP-level events AND message content, use one of the
methods described in MILTER_README, SMTPD_PROXY_README, or FILTER_README.

Wietse

RE: Newbie SASL Auth with Dovecot problem

[Michael Fox]

> 
> I don't see any
> 
>  smtpd_sasl_auth_enable = yes
> 
> in your `postconf -n` output although you claim to have set it.  The
> default would be "no".
> 
> Matthias

Oh, jeez.  How embarrassing.  Thanks Matthias.

I had entered smtp_... instead of smtpd_... 

And no matter how many times I looked, I just didn't see it.

Michael

Re: Newbie SASL Auth with Dovecot problem

[Matthias Sitte]

I don't see any

smtpd_sasl_auth_enable = yes

in your `postconf -n` output although you claim to have set it.  The 
default would be "no".


Matthias

On 2016-06-28 05:15, Michael Fox wrote:

I've been using Postfix for a while with no client submission.  I'm 
trying to set up SASL for the first time, using Dovecot, to support 
virtual users.


When I connect with EHLO, I do NOT see "AUTH" capabilities.

Of course, I'm following:  http://www.postfix.org/SASL_README.html

First of all, Dovecot is installed and authentication works

$ telnet localhost 110

Trying 127.0.0.1...

Connected to localhost.localdomain.

Escape character is '^]'.

+OK Dovecot ready.

user @

+OK

pass secret

+OK Logged in.

quit

+OK Logging out.

Connection closed by foreign host.

$

And mail is delivered to the virtual mailboxes just fine.  This tells 
me that the Dovecot passdb and userdb are working.


Now, following the SASL_README:

$ postconf -a

cyrus

dovecot

$ postconf -A

cyrus

I followed the instructions in SASL_README for "Configuring Dovecot 
SASL", plus …


smtpd_sasl_type = dovecot

smtpd_sasl_path = private/auth

smtpd_sasl_auth_enable = yes

The socket exists

~$ sudo ls -l /var/spool/postfix/private

total 0

…

srw-rw 1 postfix postfix 0 Jun 27 18:55 auth

…

$

After reload, the next step in the README is to try a connection.  But 
I don't get any AUTH options:


$ telnet localhost 25

Trying 127.0.0.1...

Connected to localhost.localdomain.

Escape character is '^]'.

220 x ESMTP Postfix (Ubuntu)

EHLO client.example.com

250-x

250-PIPELINING

250-SIZE 102400

250-VRFY

250-ETRN

250-ENHANCEDSTATUSCODES

250-8BITMIME

250 DSN

QUIT

221 2.0.0 Bye

Connection closed by foreign host.

$

I don't know what to do next.  Thanks for any help.

Thanks,

Michael

$ postconf -n

alias_database = hash:/etc/aliases

alias_maps = hash:/etc/aliases

anvil_rate_time_unit = 60s

append_at_myorigin = yes

append_dot_mydomain = yes

biff = no

bounce_queue_lifetime = 8h

bounce_template_file = /etc/postfix/bounce.cf

broken_sasl_auth_clients = yes

canonical_maps = pcre:/etc/postfix/canonical.pcre

config_directory = /etc/postfix

content_filter = amavisfeed:[127.0.0.1]:10024

delay_warning_time = 2h

fast_flush_domains = $relay_domains

header_checks = pcre:/etc/postfix/header_checks.pcre

html_directory = /usr/share/doc/postfix/html

inet_interfaces = all

mailbox_size_limit = 512

maximal_queue_lifetime = 8h

message_size_limit = 102400

mydestination = $myhostname localhost.$mydomain localhost.localdomain 
localhost


mydomain = 

mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 
192.168.8.0/24


myorigin = /etc/mailname

postscreen_access_list = permit_mynetworks 
cidr:/etc/postfix/postscreen_access.cidr


postscreen_blacklist_action = drop

postscreen_dnsbl_action = enforce

postscreen_dnsbl_reply_map = 
pcre:/etc/postfix/postscreen_dnsbl_reply_map.pcre


postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spameatingmonkey.net*2 
psbl.surriel.com*2 bl.spamcop.net 
hostkarma.junkemailfilter.com=127.0.0.2 dnsbl.sorbs.net 
bl.mailspike.net swl.spamhaus.org*-4 list.dnswl.org=127.0.[0..255].0*-1 
list.dnswl.org=127.0.[0..255].1*-2 list.dnswl.org=127.0.[0..255].2*-3 
list.dnswl.org=127.0.[0..255].3*-4


postscreen_dnsbl_threshold = 3

postscreen_dnsbl_ttl = 5m

postscreen_greet_action = enforce

proxy_interfaces = 

readme_directory = /usr/share/doc/postfix

recipient_delimiter = +

relay_domains = n6mef.ampr.org

relay_recipient_maps = pcre:/etc/postfix/relay_recipients.pcre

relay_restrictions = check_sender_access 
pcre:/etc/postfix/relay_sender_access.pcre


remote_header_rewrite_domain = invalid.domain

smtp_host_lookup = native

smtp_sasl_auth_enable = yes

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)

smtpd_client_connection_count_limit = 10

smtpd_client_connection_rate_limit = 10

smtpd_client_restrictions = permit_mynetworks 
reject_unknown_reverse_client_hostname check_client_access 
pcre:/etc/postfix/client_access.pcre reject_rbl_client zen.spamhaus.org 
permit


smtpd_data_restrictions = reject_unauth_pipelining 
reject_multi_recipient_bounce permit


smtpd_delay_reject = yes

smtpd_error_sleep_time = 5s

smtpd_etrn_restrictions = permit_mynetworks reject

smtpd_hard_error_limit = 10

smtpd_helo_required = yes

smtpd_helo_restrictions = reject_invalid_helo_hostname 
reject_non_fqdn_helo_hostname permit_mynetworks 
reject_unknown_helo_hostname check_helo_access 
pcre:/etc/postfix/helo_access.pcre permit


smtpd_junk_command_limit = 2

smtpd_recipient_restrictions = reject_non_fqdn_recipient 
reject_unknown_recipient_domain permit_mynetworks 
reject_unauth_destination check_recipient_access 
pcre:/etc/postfix/recipient_access.pcre check_recipient_access 
pcre:/etc/postfix/relay_recipient_access.pcre permit


smtpd_reject_unlisted_recipient = yes

smtpd_restriction_classes = relay_restrictions

RE: Newbie SASL Auth with Dovecot problem

[Michael Fox]

> 
> There is no AUTH on port 25, take 587.
> 
> Suomi

According to http://www.postfix.org/SASL_README.html#server_sasl_authc I
should see AUTH on port 25.

I also tried port 587.  Same result.

$ telnet localhost 587
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220  ESMTP Postfix (Ubuntu)
EHLO client.example.com
250-
250-PIPELINING
250-SIZE 102400
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye
Connection closed by foreign host.
$

I also tried port 25 and 587 from a separate machine that has an IP address
in mynetworks.  In that case, EHLO is not even recognized:

telnet  587
220  ESMTP Postfix (Ubuntu)
EHLO client.example.com
502 5.5.2 Error: command not recognized
HELO client.example.com
250 
QUIT

Mail.log:
Jun 27 23:23:32 n6mef-gw postfix/smtpd[28356]: connect from
unknown[192.168.7.180]
Jun 27 23:24:32 n6mef-gw postfix/smtpd[28356]: disconnect from
unknown[192.168.7.180]
Jun 27 23:27:29 n6mef-gw postfix/submission/smtpd[28387]: connect from
unknown[192.168.7.180]
Jun 27 23:28:10 n6mef-gw postfix/submission/smtpd[28387]: disconnect from
unknown[192.168.7.180]

Apparently there's something more fundamental that I'm missing.  But I sure
can't figure it out.

Michael

Re: No From: address in policy delegation protocol?

[Benning, Markus]

On 2016-06-28 07:46, Zhang Huangbin wrote:

I have a simple Postfix policy server, and got a problem to reject
sender login mismatch (sender != sasl_username) with Outlook 2016:
user is able to specify a From: address, it would be any address you
want, and the From: address is not passed to policy server.

I can reproduce this issue with a simple Python program:

*) construct mail message with forge sender address. e.g. 'From:
'
*) send email as normal/legal user "auth_u...@my-domain.com" with smtp 
auth.
*) while sending email, specify the sender address as 
"auth_u...@my-domain.com".
*) When user received the email, his MUA shows the address in 'From:' 
as sender.


In this case:

- address 'fo...@forge.com' is not available in policy server
- attributes 'sender=' and 'sasl_username' are 
'auth_u...@my-domain.com'


So the question is, does Postfix parse the submitted mail message to
get 'From:' address? How can i overcome this?


Policy service is just a table lookup. From what restriction do you call
the policy lookup?

The From: is a header instead of a smtp protocol field.
It may be only available within a header check.

It may be easier to implement such a check within a content filter.
For example within a spamassassin rule/plugin.

Markus
--
https://markusbenning.de/