Re: Why would dovecot not be answering

[Joe Acquisto-j4]

> On Sun, Jan 23, 2022 at 12:33:57PM -0500, Bill Cole wrote:
>> On 2022-01-22 at 23:00:55 UTC-0500 (Sat, 22 Jan 2022 23:00:55 -0500)
>> Ruben Safir 
>> is rumored to have said:
>> 
>> >I am really lost as to why dovecot is not authenticating
>> >
>> >I have
>> >
>> >smtpd_sasl_type = dovecot
>> >
>> >in main.cf
>> >
>> >and
>> >
>> ># Postfix smtp-auth
>> >unix_listener /var/spool/postfix/private/auth {
>> > mode = 0666
>> > user = postfix
>> > group = postfix
>> >}
>> >in /etc/dovecot/conf.d/10-master.conf
>> >
>> >
>> >I want it to authenticate on submition only
>> >
>> >Everything I read says this should do it, but I am up against a
>> >wall.  I
>> >have no debugging information or log at all to confirm what postfix is
>> >doing.
>> 
> 
> 
> where is it logged?

You might look in

/var/log/postfix.log 
/var/log/mail

For possible clues. 
 
I'd not post those entire logs though, just what might be logged around the 
time of you attempts

>> That's unfortunate, because what you've provided is inadequate to
>> dioagnose your problem.
>> 
>> AS ALWAYS, 'postconf -nf' and 'postconf -Mf' output plus relevant
>> (non-verbose) log lines are critical to getting useful help here.

postconf -nf  > somename (like postconf-main-log.txt)
postconf -Mf > someothername (like postconf-master-log.txt)

I probably won't be much help beyond that.

joe a.

Re: SASL questions

[Joe Acquisto-j4]

>>
> On Sat, Jan 22, 2022 at 05:56:31PM -0500, Joe Acquisto-j4 wrote:
> 
>> >> > noauth unix  -   -   n   -   -   smtp
>> >> > -o smtp_sasl_enable=no
>> >> > -o smtp_sender_dependent_authentication=no
>> >> > -o smtp_sasl_password_maps=
>> >> 
>> >> My initial attempts did not produce the desired result.   Do I need to
>> >> set all three options or just the first?
>> > 
>> > Any one of the three is logically sufficient, but the smtp(8) delivery
>> > agent will be unhappy with SASL enabled and no password map, so the last
>> > alone won't work.
>> > 
>> >> When I use all three log show invalid comment for smtp
>> > 
>> > You need to as quickly as possible get out of the habit of
>> > non-substantive problem reports.  If you post no logs and/or
>> > no associated configuration data (postconf -nf/postconf -Mf)
>> > it didn't happen, and nobody can help you.
>> 
>> Apologies.   While I am remiss in not posting that particular error, I
>> did post the configuration you mention back on 1/18/2022 1:27:39 PM
>> in this same thread. I assumed you had seen them.   Easy enough to 
>> miss from that far back.
>> 
>> The error I mentioned happened when I attempted to set all three options 
> above
>> with all three options set as shown.  It is pasted here:
>> 
>> Jan 22 17:07:18 aux postfix/smtp[32115]: fatal: specify a password table via 
> the `smtp_sasl_password_maps' configuration parameter
> 
> That's because I typo'd the first parameter name, always check
> postconf(5) and look at warnings, ...  The right setting is:
> 
> -o smtp_sasl_auth_enable=no

And, just like that . . . the problem seems resolved.  "To Grok inf fullness"
may still be far off, but, we have learned . . . 

>> I can generate new config dumps if you like, or reference the previous
>> ones, which except for the changes above are IIRC virtually unchanged.
> 
> Yes, whenever you change your settings and observe a new issue, post the
> new settings. 
> 
> -- 
> Viktor.

I presume no logs will be needed at this point.

Thanks. To all. 

joe a.

-
   j4computers, llc
   Stone Ridge, NY 12484
845-687-3734
   www.j4computers.com
-

Re: SASL questions

[Joe Acquisto-j4]

> On Sat, Jan 22, 2022 at 05:11:02PM -0500, Joe Acquisto-j4 wrote:
> 
>> > Therefore your master.cf file needs to have an least one additional
>> > smtp-based transport, with either SASL disabled entirely, and/or 
>> > sender-dependent authentication disabled, or perhaps a variant
>> > password table...  Below all three are set to "discourage" use
>> > of SASL:
>> > 
>> > noauth unix  -   -   n   -   -   smtp
>> > -o smtp_sasl_enable=no
>> > -o smtp_sender_dependent_authentication=no
>> > -o smtp_sasl_password_maps=
>> 
>> My initial attempts did not produce the desired result.   Do I need to
>> set all three options or just the first?
> 
> Any one of the three is logically sufficient, but the smtp(8) delivery
> agent will be unhappy with SASL enabled and no password map, so the last
> alone won't work.
> 
>> When I use all three log show invalid comment for smtp
> 
> You need to as quickly as possible get out of the habit of
> non-substantive problem reports.  If you post no logs and/or
> no associated configuration data (postconf -nf/postconf -Mf)
> it didn't happen, and nobody can help you.

Apologies.   While I am remiss in not posting that particular error, I
did post the configuration you mention back on 1/18/2022 1:27:39 PM
in this same thread. I assumed you had seen them.   Easy enough to 
miss from that far back.

The error I mentioned happened when I attempted to set all three options above
with all three options set as shown.  It is pasted here:

Jan 22 17:07:18 aux postfix/smtp[32115]: fatal: specify a password table via 
the `smtp_sasl_password_maps' configuration parameter
Jan 22 17:07:19 aux postfix/master[32097]: warning: process 
/usr/lib/postfix/bin//smtp pid 32115 exit status 1
Jan 22 17:07:19 aux postfix/master[32097]: warning: /usr/lib/postfix/bin//smtp: 
bad command startup -- throttling
Jan 22 17:08:19 aux postfix/smtp[32129]: fatal: specify a password table via 
the `smtp_sasl_password_maps' configuration parameter
Jan 22 17:08:20 aux postfix/master[32097]: warning: process 
/usr/lib/postfix/bin//smtp pid 32129 exit status 1
Jan 22 17:08:20 aux postfix/master[32097]: warning: /usr/lib/postfix/bin//smtp: 
bad command startup -- throttling
Jan 22 17:09:10 aux postfix/postfix-script[32143]: stopping the Postfix mail 
system

I can generate new config dumps if you like, or reference the previous ones, 
which except for the changes above are IIRC virtually unchanged.

Thanks for your efforts/

joe a.


-
   j4computers, llc
   Stone Ridge, NY 12484
845-687-3734
   www.j4computers.com
-

Re: SASL questions

[Joe Acquisto-j4]

> On Sat, Jan 22, 2022 at 02:03:29PM -0500, Joe Acquisto-j4 wrote:
> 
>> > IIRC Wietse already suggested a work-around, by making the
>> > sender-dependent authentication settings be transport-specific.
>> > 
>> > In particular the internal nexthop that does not do SASL should be
>> > handled by a transport in which sender-dependent authentication is
>> > disabled.
>>
>> I do desire outgoing email, with the "next hop" being my ISP, to have
>> sender dependent authentication.  Incoming email, once processed by
>> Postfix, SA, ClamAV, is sent to "the last hop" which does no
>> authentication.   
> 
> Sure, which means that the (smtp) transport used for that nexthop should
> have sender dependent authentication enabled.
> 
>> I do get, I think, the point you illuminate in last your paragraph
>> that in my case, a specific inbound transport must be defined for all
>> incoming messages and this transport must not specify authentication.
> 
> By not enabling sender dependent authentication for the (smtp) transport
> used to reach the internal mailstore.
> 
>> However, I get a bit fuzzy about any distinction between "sender
>> dependent authentication" and "no authentication".   Presumably that
>> will require some what different configuration than Wietse described? 

Thanks for your continued efforts.
 
> Postfix attempts to use SASL authentication when:
> 
> * smtp_sasl_enable=yes
> * and either
>   - smtp_sender_dependent_authentication = yes and
> smtp_sasl_password_maps contains a match for the sender, OR
>   - smtp_sasl_password_maps contains a match for the nexthop or
> just the underlying hostname extracted from the nexthop
> [host]:port or the like.
> Therefore your master.cf file needs to have an least one additional
> smtp-based transport, with either SASL disabled entirely, and/or 
> sender-dependent authentication disabled, or perhaps a variant
> password table...  Below all three are set to "discourage" use
> of SASL:
> 
> noauth unix  -   -   n   -   -   smtp
> -o smtp_sasl_enable=no
> -o smtp_sender_dependent_authentication=no
> -o smtp_sasl_password_maps=

My initial attempts did not produce the desired result.   Do I need to
set all three options or just the first?  When I use all three log show invalid 
comment for smtp
 
> With this, just make sure that deliveries to the internal mailstore
> use the "noauth" transport:
> 
> internal.example  noauth:[gateway.example]

This I took to be an entry in /etc/postfix/transport.  Is that correct?

joe a. 

>> In any event I am nagged however by what causes Postfix to attempt 
> authentication, 
>> for this oddball email when others sent to the same user do not, with the 
> same 
>> configuration.
> 
> See above.  You enabled authentication by enabling sender-dependent
> authentication and configuring a table with passwords specified for
> the sender addresses in question.

I still see a distinction but, let's just move on and see if it can be set to 
rights.

joe a.


-
   j4computers, llc
   Stone Ridge, NY 12484
845-687-3734
   www.j4computers.com
-

Re: SASL questions

[Joe Acquisto-j4]

> On Sat, Jan 22, 2022 at 08:01:27AM +1100, raf wrote:
> 
>> > It is an issue with email that postfix has received, via fetchmail, and is
>> > attempting to deliver to another system.  Authentication is being 
>> > attempted, without it being required or requested, at least as far as I 
>> > can 
> tell.
>> 
>> That doesn't sound right. Add that remote server to debug_peer_list
>> to increase the debugging when sending mail to it.
> 
> There's no need.  The OP reported use of sender dependent
> authentication, which causes any mail *from* some recipients
> to expect to need to authenticate to the nexthop server.
> 
> If the messages in question are not in fact routed to a nexthop that
> requires authentication, then sender dependent authentication should
> not be enabled for these users.
> 
> IIRC Wietse already suggested a work-around, by making the
> sender-dependent authentication settings be transport-specific.
> 
> In particular the internal nexthop that does not do SASL should be
> handled by a transport in which sender-dependent authentication is
> disabled.
> 
> -- 
> Viktor.

Perhaps I am simply slow these last few days.  Please bear with me.

While it may already be clear, I'll recap.  

I do desire outgoing email, with the "next hop" being my ISP, to have 
sender dependent authentication.  Incoming email, once processed by
Postfix, SA, ClamAV, is sent to "the last hop" which does no authentication.   

I do get, I think, the point you illuminate in last your paragraph that in my 
case, a specific inbound transport must be defined for all incoming messages
and this transport must not specify authentication. However, I get a bit fuzzy
about any distinction between "sender dependent authentication" and "no
authentication".   Presumably that will require some what different 
configuration 
than Wietse described? 

While I am not expecting anyone to "do it for me", obviously I am not familiar 
with
all the configuration items available in a product as complex and evolved as 
Postfix,
but find it difficult, at times, to attempt to discover them on my own.  
Perhaps they
are all documented and I have simply missed them?

In any event I am nagged however by what causes Postfix to attempt 
authentication, 
for this oddball email when others sent to the same user do not, with the same 
configuration.

Perhaps the answer is "it just does, you have a work around, now go away, you 
silly 
person",  

joe a.



-
   j4computers, llc
   Stone Ridge, NY 12484
845-687-3734
   www.j4computers.com
-

Re: SASL questions

[Joe Acquisto-j4]

> On Tue, Jan 18, 2022 at 07:22:40PM -0500, Joe Acquisto-j4 
>  
> wrote:
> 
>> . . .
>> > I would imagine that Postfix can only authenticate to
>> > servers that have entries in /etc/postfix/sasl_passwd.
>> > 
>> >   smtp_sasl_password_maps (default: empty)
>> > 
>> > Optional Postfix SMTP client lookup tables with one
>> > username:password entry per sender, remote hostname
>> > or next-hop domain. Per-sender lookup is done only
>> > when sender-dependent authentication is enabled. If
>> > no username:password entry is found, then the
>> > Postfix SMTP client will not attempt to
>> > authenticate to the remote host.
>> > 
>> > But it seems unlikely that you'd have put an entry there
>> > for a server of yours that doesn't authenticate.
>> > 
>> > Perhaps you need to add that server to debug_peer_list
>> > and see what the extra logs say.
>> > 
>> > cheers,
>> > raf
>> 
>> I believe I have that correct, per examples (and it is working mostly as 
> expected)
>> /etc/postfixsasl_passwd takes this form:
>> 
>> j...@aaa.comjoea@AAA:ADADAD
>> j...@aaad.comj...@aaad.com:ADADAD2
>> 
>> As said, this appears to work and does not interfer with incoming
>> email that goes to a local host, unauthenticated, in all but one case.
> 
> Yes, it has nothing to do with incoming connections.
> It's used by the Postfix SMTP client when making
> outgoing connections.
> 
> Does this mean that the problem you are seeing is with
> incoming connections? Sorry, but I was under the
> impression that your problem was that Postfix's SMTP
> client was trying to authenticate itself to a remote
> server when delivering mail somewhere (presumably
> because that remote server required it). If the problem
> is that an incoming SMTP connection is coming from a
> remote client, and your Postfix is insisting on that
> connection authenticating itself, then that's a very
> different thing.
> 
>> joe a
> 
> cheers,
> raf

Sorry for the confusion.  I will refrain from any self-deprecating attempts 
at humor. 

It is an issue with email that postfix has received, via fetchmail, and is
attempting to deliver to another system.  Authentication is being 
attempted, without it being required or requested, at least as far as I can 
tell.

Any "normal" mail that is fetched from that gmail account, or others,
delivers with no apparent attempt to authenticate.  All authentication
should fail, in any case, as it is not configured on the target server.

I have attempted to examine the subject email while in the deferred
queue (postcat) and comparing it to other examples. Nothing jumped
out at me.

Did not find a way to route mail to the deferred queue so as to revert to
smtp_sender_dependent_authentication = no and send a duplicate 
email, then compare the two. 

This may not be worth further effort as it is a rather problematic way
for me to test and maybe should be abandoned.  I've just got it in mind
there is nothing "wrong" with it and it "should" work and wonder why.   

But, what do I know?  Thanks for the follow up.   

joe a

Re: SASL per user or per host disable and, use of trace, strace

[Joe Acquisto-j4]

> Wietse Venema:
>> Joe Acquisto-j4:
>> > For version 3.7.4, is there a means of disabling for smtp per user,
>> > per domain, per IP, when "smtp_sender_dependent_authentication =
>> > yes"?
>> 
>> Postfix will search smtp_sasl_password_maps by sender first, and
>> if that is not found, then by destination.
>> 
>> If you don't want Postfix to authenticate to a specific destination,
>> then don't list that destination in smtp_sasl_password_maps.

Ah, but that seem to be the case now.  I do not have the destination for that 
user in "smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd"
yet it attempts to deliver to the correct destination and attempts to 
authenticate.

yet when "smtp_sender_dependent_authentication = no" it makes no attempt to 
authenticate to the very same target server.

> 
> It is possible to separate the per-sender and other email streams,
> but that is a bit more complicated, because most people don't have
> your requireents.
> 
> This uses sender_dependent_default_transport_maps, where all
> per-sender default transports share a customized Postfix SMTP cient
> with its own smtp_sasl_passwd_maps setting in master.cf, which has
> all the per-sender entries.
> 
> The other email streams use the 'normal' Postfix SMTP client with
> only per-destination entries in smtp_sasl_passwd_maps.
> 
>   Wietse

This does look a bit complicated and I hesitate to hack at it without further 
eyeballing.  Not sure I see how this helps "coax" postfix to not authenticate 
on this one inbound user.  Perhaps I just need to think about it more.

joe a.

Re: SASL questions

[Joe Acquisto-j4]

. . .
> I would imagine that Postfix can only authenticate to
> servers that have entries in /etc/postfix/sasl_passwd.
> 
>   smtp_sasl_password_maps (default: empty)
> 
> Optional Postfix SMTP client lookup tables with one
> username:password entry per sender, remote hostname
> or next-hop domain. Per-sender lookup is done only
> when sender-dependent authentication is enabled. If
> no username:password entry is found, then the
> Postfix SMTP client will not attempt to
> authenticate to the remote host.
> 
> But it seems unlikely that you'd have put an entry there
> for a server of yours that doesn't authenticate.
> 
> Perhaps you need to add that server to debug_peer_list
> and see what the extra logs say.
> 
> cheers,
> raf

I believe I have that correct, per examples (and it is working mostly as 
expected)
/etc/postfixsasl_passwd takes this form:

j...@aaa.comjoea@AAA:ADADAD
j...@aaad.comj...@aaad.com:ADADAD2

As said, this appears to work and does not interfer with incoming email that 
goes to a local host, unauthenticated, in all but one case.

joe a

Re: SASL per user or per host disable and, use of trace, strace

[Joe Acquisto-j4]

> Wietse Venema:
>> Joe Acquisto-j4:
>> > For version 3.7.4, is there a means of disabling for smtp per user,
>> > per domain, per IP, when "smtp_sender_dependent_authentication =
>> > yes"?
>> 
>> Postfix will search smtp_sasl_password_maps by sender first, and
>> if that is not found, then by destination.
>> 
>> If you don't want Postfix to authenticate to a specific destination,
>> then don't list that destination in smtp_sasl_password_maps.
> 
> It is possible to separate the per-sender and other email streams,
> but that is a bit more complicated, because most people don't have
> your requireents.
> 
> This uses sender_dependent_default_transport_maps, where all
> per-sender default transports share a customized Postfix SMTP cient
> with its own smtp_sasl_passwd_maps setting in master.cf, which has
> all the per-sender entries.
> 
> The other email streams use the 'normal' Postfix SMTP client with
> only per-destination entries in smtp_sasl_passwd_maps.
> 
>   Wietse

Thanks much.  I'll go searching for details/examples in a bit.

joe a.

SASL per user or per host disable and, use of trace, strace

[Joe Acquisto-j4]

For version 3.7.4, is there a means of disabling for smtp per user, per domain, 
per IP, when "smtp_sender_dependent_authentication = yes"?

Docs/supplements seem say some roughly analogous settings were available pre V 
3.x, but are now deprecated.   I've not found any current setting while 
flailing about in the deep ethereal seas.

Essentially, looking for a means to tell postfix specifically (the little 
dickens) to not attempt to authenticate to a specific host, by user, or 
hostname/IP.. By domain would seem unlikely to help resolve an annoying oddity, 
described in another post.

Any assistance in adding trace or strace. explicit or referral to recent (and 
reachable) docs would be appreciated.   The two referenced programs are all 
that are natively available in this distribution.

Thanks in advance.

joe a

Re: SASL questions

[Joe Acquisto-j4]

. . .
> OK, here goes -  
> 
> Using version 3.4.7 packaged by Suse.  I use "fetchmail" to retrieve email 
> via imap one of which is gmail.  The fetched mail is all sent to a local "off 
> box" machine, via postfix, spamassassin and clamav, all on the same server.  
> The off box machine let's call it "fubar", runs a rather dated groupware 
> product I used to support.  
> 
> I send mail to one upstream provider They require authentication.  Seem to 
> have successfully setup per user SASL authentication, with one "problem" 
> remaining.
> 
> Since I would sometimes forget to check the gmail account, added that 
> account to fetchmail.  It would deliver to fubar via the means described 
> above, with a unique fubar user, via the means mentioned above. It became 
> convenient to  occasionally use the gmail account to test changes I might 
> make to my local system.  That worked well, till now.
> 
> Now when I set "smtp_sender_dependent_authentication = yes" any email I send 
> to the gmail account from fubar, upon being "fetched", fails to deliver to 
> "fubar" with postfix reporting "501 Authentication failed" and the mail is 
> deferred. If I set "smtp_sender_dependent_authentication = no" and restart 
> postfix, the deferred mail is delivered. Any mail that arrives at the gmail 
> account by any other means delivers normally regardless of the value of 
> "smtp_sender_dependent_authentication".
> 
> Ultimately, I determined the attempt to authenticate to fubar happens with 
> any mail I send to the gmail account, where the "from" address is any valid 
> user on the fubar system.  That includes test emails sent using swaks, via 
> the same upstream provider. 
> 
> On the receiving end I can see logged information that shows fubar is 
> attempting to authenticate, which it does not attempt to do when sender 
> dependent authentication is not enabled. At least, not in any visible way or 
> even any configured way, While from the point of view of the professionals 
> this may "not be a real problem" perhaps for myriad uttered reasons including 
> "WFT dude"?, it still seems odd at the least. Probably it will be due to 
> "something you did and should have known better".
> 

Resubmitting with a bit more information, hopefully useful.  It seems 
inescapable to conclude that postfix is initiating the attempt to authenticate 
in this odd case. Why that is so escapes me at the moment. The server on the 
receiving end is set to not authenticate, which does raise the question of why 
it seems to be attempting to at all.  In any case, I submit below the output of 
postfinger and saslfinger as the debugging page suggests.  I see some of the 
information in each section is redundant, but I did not want to risk causing 
any further confusion and consternation.

-- postfinger:

postfinger - postfix configuration on Tue Jan 18 11:54:49 EST 2022
version: 1.30

--System Parameters--
mail_version = 3.4.7
hostname = auxilary
uname = Linux auxilary 5.3.18-lp152.87-default #1 SMP Sun Aug 8 21:53:57 UTC 
2021 (44d702a) x86_64 x86_64 x86_64 GNU/Linux

--Packaging information--
looks like this postfix comes from RPM package: postfix-3.4.7-lp152.2.9.1.x86_64

--Mailbox locking methods--
flock fcntl dotlock

--Supported Lookup tables--
btree cidr environ fail hash inline internal ldap lmdb memcache mysql nis pcre 
pgsql pipemap proxy randmap regexp socketmap static tcp texthash unionmap unix

--main.cf non-default parameters--
alias_maps = hash:/etc/aliases
biff = no
canonical_maps = hash:/etc/postfix/canonical
compatibility_level = 2
daemon_directory = /usr/lib/postfix/bin/
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
$daemon_directory/$process_name $process_id & sleep 5
delay_warning_time = 1h
disable_dns_lookups = yes
disable_vrfy_command = yes
html_directory = /usr/share/doc/packages/postfix-doc/html
inet_protocols = ipv4
mailbox_size_limit = 0
maillog_file = /var/log/postfix.log
manpage_directory = /usr/share/man
masquerade_exceptions = root
message_size_limit = 0
message_strip_characters = \0
milter_default_action = accept
mydestination = $myhostname, localhost.$mydomain
myhostname = AAA.AA.com
mynetworks = DDD.DDD.DDD.221/32,DDD.DDD.DDD.222,DDD.DDD.DDD.211/32,127.0.0.0/8
mynetworks_style = subnet
readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
relay_domains = $mydestination, hash:/etc/postfix/relay
relocated_maps = hash:/etc/postfix/relocated
sample_directory = /usr/share/doc/packages/postfix-doc/samples
sender_canonical_maps = hash:/etc/postfix/sender_canonical
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
setgid_group = maildrop
smtp_enforce_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = login
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/postfix/ssl/certs/cacert.pem
smtp_tls_CApath = /etc/postfix/ssl/certs/
smtp_tls_cert_file = 

Re: SASL questions

[Joe Acquisto-j4]

> On 2022-01-17 at 20:09:55 UTC-0500 (Mon, 17 Jan 2022 20:09:55 -0500)
> Joe Acquisto-j4 
> is rumored to have said:
> 
> 
>> Sorry for the garbled message.  Looking for the config files, etc that 
>> are normally requested.
> 
> 
> The non-default main.cf settings, formatted for human eyes:
> postconf -nf
> 
> The master.cf settings, formatted for human eyes:
> postconf -Mf
> 
> 
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org 
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire

OK, here goes -  

Using version 3.4.7 packaged by Suse.  I use "fetchmail" to retrieve email via 
imap one of which is gmail.  The fetched mail is all sent to a local "off box" 
machine, via postfix, spamassassin and clamav, all on the same server.  The off 
box machine let's call it "fubar", runs a rather dated groupware product I used 
to support.  

I send mail to one upstream provider They require authentication.  Seem to have 
successfully setup per user SASL authentication, with one "problem" remaining.

Since I would sometimes forget to check the gmail account, added that account 
to fetchmail.  It would deliver to fubar via the means described above, with a 
unique fubar user, via the means mentioned above. It became convenient to  
occasionally use the gmail account to test changes I might make to my local 
system.  That worked well, till now.

Now when I set "smtp_sender_dependent_authentication = yes" any email I send to 
the gmail account from fubar, upon being "fetched", fails to deliver to "fubar" 
with postfix reporting "501 Authentication failed" and the mail is deferred. If 
I set "smtp_sender_dependent_authentication = no" and restart postfix, the 
deferred mail is delivered. Any mail that arrives at the gmail account by any 
other means delivers normally regardless of the value of 
"smtp_sender_dependent_authentication".

Ultimately, I determined the attempt to authenticate to fubar happens with any 
mail I send to the gmail account, where the "from" address is any valid user on 
the fubar system.  That includes test emails sent using swaks, via the same 
upstream provider. 

On the receiving end I can see logged information that shows fubar is 
attempting to authenticate, which it does not attempt to do when sender 
dependent authentication is not enabled. At least, not in any visible way or 
even any configured way, While from the point of view of the professionals this 
may "not be a real problem" perhaps for myriad uttered reasons including "WFT 
dude"?, it still seems odd at the least. Probably it will be due to "something 
you did and should have known better".

Below is output from postconf -Mf:

smtp   inet  n   -   n   -   -   smtpd
-o content_filter=spamassassin
pickup fifo  n   -   n   60  1   pickup
cleanupunix  n   -   n   -   0   cleanup
qmgr   fifo  n   -   n   300 1   qmgr
rewriteunix  -   -   n   -   -   trivial-rewrite
bounce unix  -   -   n   -   0   bounce
defer  unix  -   -   n   -   0   bounce
trace  unix  -   -   n   -   0   bounce
verify unix  -   -   n   -   1   verify
flush  unix  n   -   n   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   n   -   -   smtp
relay  unix  -   -   n   -   -   smtp
-o smtp_fallback_relay=
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discardunix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache
spamassassin unix -  n   n   -   -   pipe flags=Rq
user=spamfilter argv=/usr/local/bin/spamass.sh -e /usr/sbin/sendmail -oi -f
${sender} -- ${recipient}
tlsmgr unix  -   -   n   1000?   1   tlsmgr
postlogunix-dgram n  -   n   -   1   postlogd

Below is output from postconf -Mf: (obfuscated)

alias_maps = hash:/etc/aliases
biff = no
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
compatibility_level = 2
content_filter =
daemon_dir

Re: SASL questions

[Joe Acquisto-j4]

>>>
>> > >  One addition:
> 
>The swaks command line you'll need to test properly will be something like 
 this:
 
 swaks -tls -t tar...@example.com  --auth-user joea --server 
 mail.example.com:587
 
>>> 
>>> Thanks, that got me over that hump. Test email went through,
>>> 
>>> Now to translate this effort into fixing my postfix configuration.
>>> 
>>> joe a
>> 
>> The old adage "read logs and be enlightened" (OK I made that up) seems to 
>> hold.
>> 
>> Eventually I emerged from my fog and found the bounce messages were via the 
>> provider 
>> IP port 25.  I thought that odd, since TLS seemed established.
>> 
>> Looking at /etc/postfix/transport(.db) found I had not used the form 
>> [some.host.com]:port.  Fixed that
>> and all seems to work.
>> 
>> Thanks again.
> 
> I have per user SASL authentication working, with one rather odd exception 
> for which I do not see a cause.   It's a bit convoluted to explain before 
> post that, please just remind me what those are.  I did make an concerted 
> effort to find them, but came up short.
> 
> Thanks.
> 
> joe a.

Sorry for the garbled message.  Looking for the config files, etc that are 
normally requested.  Time to take a rest,

joe a.

Re: SASL questions

[Joe Acquisto-j4]

>> >  One addition:

>>> The swaks command line you'll need to test properly will be something like 
>>> this:
>>> 
>>> swaks -tls -t tar...@example.com  --auth-user joea --server 
>>> mail.example.com:587
>>> 
>> 
>> Thanks, that got me over that hump. Test email went through,
>> 
>> Now to translate this effort into fixing my postfix configuration.
>> 
>> joe a
> 
> The old adage "read logs and be enlightened" (OK I made that up) seems to 
> hold.
> 
> Eventually I emerged from my fog and found the bounce messages were via the 
> provider 
> IP port 25.  I thought that odd, since TLS seemed established.
> 
> Looking at /etc/postfix/transport(.db) found I had not used the form 
> [some.host.com]:port.  Fixed that
> and all seems to work.
> 
> Thanks again.

I have per user SASL authentication working, with one rather odd exception for 
which I do not see a cause.   It's a bit convoluted to explain before post 
that, please just remind me what those are.  I did make an concerted effort to 
find them, but came up short.

Thanks.

joe a.

Re: SASL questions

[Joe Acquisto-j4]

>>  One addition:
>> 
>> The swaks command line you'll need to test properly will be something like 
>> this:
>> 
>> swaks -tls -t tar...@example.com  --auth-user joea --server 
>> mail.example.com:587
>> 
> 
> Thanks, that got me over that hump. Test email went through,
> 
> Now to translate this effort into fixing my postfix configuration.
> 
> joe a

The old adage "read logs and be enlightened" (OK I made that up) seems to hold.

Eventually I emerged from my fog and found the bounce messages were via the 
provider 
IP port 25.  I thought that odd, since TLS seemed established.

Looking at /etc/postfix/transport(.db) found I had not used the form 
[some.host.com]:port.  Fixed that
and all seems to work.

Thanks again.

Re: SASL questions

[Joe Acquisto-j4]

> One addition:
> 
> The swaks command line you'll need to test properly will be something like 
> this:
> 
> swaks -tls -t tar...@example.com  --auth-user joea --server 
> mail.example.com:587
> 

Thanks, that got me over that hump. Test email went through,

Now to translate this effort into fixing my postfix configuration.

joe a

Re: SASL questions

[Joe Acquisto-j4]

> On 2022-01-13 at 20:26:53 UTC-0500 (Thu, 13 Jan 2022 20:26:53 -0500)
> Joe Acquisto-j4 
> is rumored to have said:
> 
> [...]
>> Would it be valid to presume that an SMTP server that can be connected 
>> to,
>> securely, via Outlook, Thunderbird and the other common clients, can 
>> be
>> connected to via the postfix SASL stuff?
> 
> No. There are authentication mechanisms supported by interactive clients 
> that are not supported by Cyrus. The most important ones are OAUTHBEARER 
> and XOAUTH2, which require an out-of-band (web) interaction following 
> the OAuth2 protocol, typically to support 2FA methods that require a 
> live human interaction.
> 
>> Or is SASL/Cyrus an equine of
>> a different hue?
> 
> SASL is a broad framework used by many application protocols (SMTP, 
> IMAP, etc.) for authentication and each implementation is unique, but 
> hopefully they are interoperable when needed. As long as the relay isn't 
> requiring an authentication mechanism that is designed to exclude bots 
> (such as the those mentioned above) it should be possible to get Postfix 
> (using Cyrus) to authenticate to it.
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org 
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire

I guess this is going a bit astray, for some viewers anyway, but after 
repeated authentication failures, resorted to (or availed myself of)
SWAKS and still get authentication failures.  I did set swaks to 
echo the credentials in plaintext, to the screen and know they 
are correct.  I am unsure why they are "broken up" with "->" and 
<-" and wonder if that should provide a clue?  

Below is what is echoed to the screen.
~ # swaks
=== Trying mail.somehost.com:587...
=== Connected to mail.somehost.com.
<-  220 mail.somehost.com ESMTP Postfix
 -> EHLO auxilary
<-  250-forwardx.somehost.com
<-  250-PIPELINING
<-  250-SIZE 56789012
<-  250-VRFY
<-  250-ETRN
<-  250-STARTTLS
<-  250-AUTH PLAIN LOGIN
<-  250-AUTH=PLAIN LOGIN
<-  250-ENHANCEDSTATUSCODES
<-  250-8BITMIME
<-  250 DSN
 -> AUTH LOGIN
<-  334 bla-
 -> blah-user
<-  334 bla
 -> blah-password
<** 535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6
*** No authentication type succeeded
 -> QUIT
<-  221 2.0.0 Bye
=== Connection closed with remote host.
 
joe a.

Re: SASL questions

[Joe Acquisto-j4]

> On 2022-01-13 at 13:09:45 UTC-0500 (Thu, 13 Jan 2022 13:09:45 -0500)
> Joe Acquisto-j4 
> is rumored to have said:
> 
>> While reading the Postfix SASL doc,  
> (http://www.postfix.org/SASL_README.html#client_sasl),
>> I puzzled over a few things.
>>
>> - "The smtp_tls_security_level setting ensures that the connection to the 
> remote smtp server will be encrypted, and smtp_sasl_tls_security_options 
> removes the prohibition on plaintext passwords."
>>
>> Is that incorrect?  Surely one would not want to send passwords in plaintext 
> as this seems to state?
> 
> But only sending plaintext passwords *over an encrypted channel.*
> 
> SASL has a bunch of mechanisms that provide safe authentication over a 
> non-secure channel. It also has a few which are essentially plaintext, only 
> armoring auth credentials with Base64 encoding. Mechanisms that never send 
> the password unencrypted/unhashed over an unencrypted channel have the 
> weakness that they require both sides to store the password in a recoverable 
> form, whereas plaintext mechanisms allow the server to only store a 1-way 
> hash 
> of the password. Having the whole channel protected from sniffing and not 
> having the password in a recoverable form on the server is a better choice 
> than allowing in-the-clear transport and using a complex mechanism to just 
> protect credential in transit while storing leakable passwords on the server.
> 
>> - "With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP 
> client to send username and password information to the mail gateway server. 
> As discussed in the next section, the Postfix SMTP client supports multiple 
> ISP accounts. For this reason the username and password are stored in a table 
> that contains one username/password combination for each mail gateway 
> server."
>>
>> Figured I would ask before reading further.  Is it not possible to 
> authenticate to the same remote (receiver) with multiple sets of credentials?
> 
> Yes. The smtp_sasl_password_maps table can have full sender addresses, 
> target MX hostnames, and next-hop domains as keys. For per-sender auth to 
> work, 
> you must also enable sender-dependent authentication. See the section on 
> "Configuring Sender-Dependent SASL authentication" in the SOHO readme 
> (http://www.postfix.org/SOHO_README.html#client_sasl_sender)
> 
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org 
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire

Thanks.   

I am having some problems getting the SASL thing working.  Not looking for 
any "fix" advice, but would like to establish something in my mind.

Would it be valid to presume that an SMTP server that can be connected to,
securely, via Outlook, Thunderbird and the other common clients, can be 
connected to via the postfix SASL stuff?   Or is SASL/Cyrus an equine of 
a different hue?

joe a.

SASL questions

[Joe Acquisto-j4]

While reading the Postfix SASL doc,  
(http://www.postfix.org/SASL_README.html#client_sasl), 
I puzzled over a few things.

- "The smtp_tls_security_level setting ensures that the connection to the 
remote smtp server will be encrypted, and smtp_sasl_tls_security_options 
removes the prohibition on plaintext passwords."   

Is that incorrect?  Surely one would not want to send passwords in plaintext as 
this seems to state?

- "With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP 
client to send username and password information to the mail gateway server. As 
discussed in the next section, the Postfix SMTP client supports multiple ISP 
accounts. For this reason the username and password are stored in a table that 
contains one username/password combination for each mail gateway server."

Figured I would ask before reading further.  Is it not possible to authenticate 
to the same remote (receiver) with multiple sets of credentials?  I ask as 
preliminary discussion with a potential provider seemed to indicate a "per 
user" authentication is required.   Still waiting for clarification on that 
point.

Thanks.

Re: Can i run postfix on my home IP

[Joe Acquisto-j4]

> Hello list,
> 
> I have got a DSL from the ISP, having a static IP.
> Can I run postfix with this IP for accepting email for my own
domain?
> 
> ありがとう
> えりな

Late to the party, but, certainly. Many here do. However, exposing your
mail port "to the world"
might entice much more "unfriendly traffic" than you might imagine.  

joe a

Re: https://www.postfix.org/ in trouble

[Joe Acquisto-j4]

> Date: Tuesday, January 11, 2022 19:38:05 +0100
>> From: "Claus R. Wickinghoff" 
>> 
Today I find only a directory listing at www.postfix.org or
>>> www.postfix.com 
>> With http it's working.
>> 
>> With https I get a certificate warning (issued for
>> archive.science.uu.nl) and a directory listing.
>> 
>> So might be a regional problem?
>> 
> 
> See the list archive for a discussion of this earlier this month,
> specifically:
>   
>
> 
> Nothing is broken, https just isn't supported.

Sorry for the noise, apparently I changed something in my browser to require 
https.
Odd that.

joe a.

Re: https://www.postfix.org/ in trouble

[Joe Acquisto-j4]

> raf wrote:
>> Being flippant, it would protect against a
>> man-in-the-middle-attack where someone tricks you into
>> reading false online documentation. :-)
> 
> Why bother?  Most of us can misread the docs perfectly well all on our 
> own...  
> 
> -kgd

Today I find only a directory listing at www.postfix.org or www.postfix.com 

joe a.

Re: local system mail

[Joe Acquisto-j4]

. . .
> 
> I did not notice that adding non_smtpd_milters also caused off 
> box (smtpd) mail to be scanned twice, before and after 
> spamassassin.  
> 
> Apparently having both smtpd_milters and non_smtpd_milters 
> specified in main.cf causes that.
> 
> Initially it appeared to me that milters had to be specified main.cf.  
> Delving somewhat deeper it now appears that to me milters can 
> alternately be specified in master.cf?   Is that correct?  
> 
> joe a

Re-reading http://www.postfix.org/FILTER_README.html#principles

I think provides what I sought.  Thanks for the comments, more insight
is always useful.

joe a.

Re: local system mail

[Joe Acquisto-j4]

> On 22 Feb 2021, at 18:40, Joe Acquisto-j4 wrote:
> 
On 22 Feb 2021, at 17:27, Joe Acquisto-j4 wrote:
>>>
>>>> Post fix version 3.4.7. with Spamassassin.  While adding virus
>>>> scanning (clamav) noticed during testing
>>>> that any mail send from the postfix host does not get processed by
>>>> spamassassin.
>>>>
>>>> Postfix does accept it and passes it right thorough without any
>>>> indication it was passed through
>>>> spamd or clamd.
>>>
>>> Critical issue: what mechanisms are you using to integrate 
>>> SpamAssassin
>>> and ClamAV?
>>>
>>>> Wondering how I can fix that.  That is, cause local mail to be
>>>> scanned.
>>>>
>>>> Quick look at master.cf and main.cf, nothing jumped out to bite me.
>>>
>>> If you are using Milters, you need to set non_smtpd_milters to get
>>> locally-submitted mail to be shown to them. If that's not the 
>>> solution
>>> in your case (i.e. you're using the SMTP proxy or content_filter
>>> mechanisms) you need to explain your configuration.
>>>
>>> -- 
>>> Bill Cole
>>
>> Thanks.  Sorry for the terse post.  Figured it was such an obvious
>> amateur error not much was needed.
>>
>> Setting non_smtpd_milters did the trick for testing the virus scanner. 
>>  I
>> should have guessed that on my own.
>>
>> The content filter (spamassassin) is not a hot item. but the relevant 
>> lines
>> from master.cf are:
>> . . .
>> smtp  inet  n   -   n   -   -   smtpd -o 
>> content_filter=spamassassin
> 
> You need an analogous configuration for the pickup service to get local 
> mail piped through the spamassassin service. See 
> http://www.postfix.org/FILTER_README.html.
> 
> -- 
> Bill Cole
. . . 

I did not notice that adding non_smtpd_milters also caused off 
box (smtpd) mail to be scanned twice, before and after 
spamassassin.  

Apparently having both smtpd_milters and non_smtpd_milters 
specified in main.cf causes that.

Initially it appeared to me that milters had to be specified main.cf.  
Delving somewhat deeper it now appears that to me milters can 
alternately be specified in master.cf?   Is that correct?  

joe a

Re: ways to process HOLD queue

[Joe Acquisto-j4]

> On 24/02/21 11:47 am, Joe Acquisto-j4 wrote:
>> Added Virus scanning to a SOHO stetup.   clamav-milter is directing (?) 
> "infected" mail to postfix HOLD queue.
> 
> Perhaps rather than having clamav-milter put the message on hold, it 
> might be possible to have clamav-milter simply flag the message (by 
> adding a header), and then it could still be delivered to the user, 
> optionally using sieve to put it into a different (e.g. Junk) folder?
> 
> Nick.

One would think so, that was one of my first thoughts.  Seems there could
be such an option, but I've not found it.  

Thought also occurred that postfix might have a "queue alert" notice option
which I did not notice.  Tend to think there must be some means but often the
obvious is not.  

It's easy enough to make a have cron run a simple script that checks the queue
and alert someone for disposition.   

joe a.

ways to process HOLD queue

[Joe Acquisto-j4]

Added Virus scanning to a SOHO stetup.   clamav-milter is directing (?) 
"infected" mail to postfix HOLD queue.  

That's fine. 

First thought is to process the queue'd mail, alter the subject line, based on 
the added descriptive header line, and 
deliver it to the intended user(s).  I don't consider that a great risk in this 
case.

Is http://www.postfix.org/FILTER_README.html the proper place to be snooping 
about, a good place to start hacking
at a solution? (Thanks to Bill Cole for the link, for a different reason).

My "cybie sense" tells me this is not a unique goal and probably has "boiler 
plate" solutions, lurking every where.   

But my search skills are at odds with the SEO overlords these days. (ie, I 
can't find nothing, useful, no how, lately)

Thanks for your tolerance.

joe a.

Re: local system mail

[Joe Acquisto-j4]

> On 22 Feb 2021, at 17:27, Joe Acquisto-j4 wrote:
> 
>> Post fix version 3.4.7. with Spamassassin.  While adding virus 
>> scanning (clamav) noticed during testing
>> that any mail send from the postfix host does not get processed by 
>> spamassassin.
>>
>> Postfix does accept it and passes it right thorough without any 
>> indication it was passed through
>> spamd or clamd.
> 
> Critical issue: what mechanisms are you using to integrate SpamAssassin 
> and ClamAV?
> 
>> Wondering how I can fix that.  That is, cause local mail to be 
>> scanned.
>>
>> Quick look at master.cf and main.cf, nothing jumped out to bite me.
> 
> If you are using Milters, you need to set non_smtpd_milters to get 
> locally-submitted mail to be shown to them. If that's not the solution 
> in your case (i.e. you're using the SMTP proxy or content_filter 
> mechanisms) you need to explain your configuration.
> 
> -- 
> Bill Cole

Thanks.  Sorry for the terse post.  Figured it was such an obvious 
amateur error not much was needed.

Setting non_smtpd_milters did the trick for testing the virus scanner.  I
should have guessed that on my own.

The content filter (spamassassin) is not a hot item. but the relevant lines
from master.cf are:
. . .
smtp  inet  n   -   n   -   -   smtpd -o 
content_filter=spamassassin

. . .
spamassassin unix - nn   -   -   pipe
  flags=Rq user=spamfilter argv=/usr/local/bin/spamass.sh -e /usr/sbin/sendmail 
-oi -f ${sender} -- ${recipient}
. . .

Hopefully that is enough.  

joe a.

local system mail

[Joe Acquisto-j4]

Post fix version 3.4.7. with Spamassassin.  While adding virus scanning 
(clamav) noticed during testing
that any mail send from the postfix host does not get processed by spamassassin.

Postfix does accept it and passes it right thorough without any indication it 
was passed through
spamd or clamd.

Wondering how I can fix that.  That is, cause local mail to be scanned.

Quick look at master.cf and main.cf, nothing jumped out to bite me. 

joe a.

Re: blocking attachments. Sanity check and testing

[Joe Acquisto-j4]

> I'm revisiting blocking certain attachments.   A multi part question:  
> Implementation, logging, testing.
> 
> Seems the accepted way to do attachment blocking is something like this:
> 
> in /etc/postfix/main.cf  added, without quotes: "mime_header_checks = 
> regexp:/etc/postfix/block_attachments"
> 
> in /etc/postfix/block_attachments added, without quotes: 
> "/name=[^>]*\.(1|2|3)/ DISCARD"
> 
> I have read some discussions on DISCARD and, for my purpose, it suits.  I 
> think. 
> 
> Is the action logged anywhere?  I have not seen it. If not, can it be done?
> 
> Finally, I hope (if only to avoid further exposing my ignorance), what is a 
> simple way to test the workings, preferably with 
> actual messages that have been received?

Well, never mind on the logging and by inference, all but the "test 
immediately" thing.

"discard" clearly shows in /var/log/mail.   When one removes cranium from 
posterior that is.

blocking attachments. Sanity check and testing

[Joe Acquisto-j4]

I'm revisiting blocking certain attachments.   A multi part question:  
Implementation, logging, testing.

Seems the accepted way to do attachment blocking is something like this:

in /etc/postfix/main.cf  added, without quotes: "mime_header_checks = 
regexp:/etc/postfix/block_attachments"

in /etc/postfix/block_attachments added, without quotes: "/name=[^>]*\.(1|2|3)/ 
DISCARD"

I have read some discussions on DISCARD and, for my purpose, it suits.  I 
think. 

Is the action logged anywhere?  I have not seen it. If not, can it be done?

Finally, I hope (if only to avoid further exposing my ignorance), what is a 
simple way to test the workings, preferably with 
actual messages that have been received?

Re: adding AV scanning to working Postfix/SA system

[Joe Acquisto-j4]

> michael Schumacher wrote:
>> Joe,
>> 
Due to some recent malware (in attachments, obvious stuff) wanted to add AV 
> scanning.   I gather "Amavis-new" is the hot ticket these days,
>>> I deal with Sophos products and would like to use their linux product to do 
> the scanning.   Seems to be precious little on how to do that.
>> 
>> I am using amavis with clamav. Sorry, no additional commercial virus 
> scanners, but I noticed that amavis.conf contains setups for a lot of 
> commercial virus scanners. May be worth a look.
>> 
>> Michael
>> 
>> 
> 
> FWIW, I was going to say my impression is amavis-new was the hot ticket 
> several years ago, but is losing market share to rspamd. 
> https://rspamd.com/doc/modules/external_services.html says rspamd has 
> been tested with Sophos (via SAVDI).  My amavisd.conf says it works with 
> Sophie (unmaintained since 2004), Sophos SAVE via SAVI-Perl 
> (https://metacpan.org/release/SAVI-Perl from 2005), and as a last resort 
> Sophos sweep.

I'll have a look, thanks.  The links to those references on the amavis docs 
page seem to
be out of date, as they lead to dead ends, far as I could tell.





-
   j4computers, llc
   Stone Ridge, NY 12484
845-687-3734
   www.j4computers.com
-

adding AV scanning to working Postfix/SA system

[Joe Acquisto-j4]

Not to waste anyone's time, but I posted this on SA list and a Sophos site, 
but, came up with zip. Not even a "do-dah".  Beyond "experiences"
any leads to general "how to: guides that work in practice?

>> SOHO system, on virtual machines.   Fairly recent versions. Running openSUSE 
>> Leap 15.1.

Due to some recent malware (in attachments, obvious stuff) wanted to add AV 
scanning.   I gather "Amavis-new" is the hot ticket these days,

I deal with Sophos products and would like to use their linux product to do the 
scanning.   Seems to be precious little on how to do that.

Any experiences? 



-
   j4computers, llc
   Stone Ridge, NY 12484
845-687-3734
   www.j4computers.com
-

Re: [External] command injection by crafted recipient address

[Joe Acquisto-j4]

>>>
> kris_h:
>> Hey Wietse,
>> 
>> thank you for this clearification. 
>> 
>> What do you think about using the reject-recipient /\$\{/-rule?
> 
> As a temporary rule, it may have made sense when the Exim bug was new.
> 
> As a permanent 'deny' rule, it won't block new exploits.
> 
>   Wietse

Seems these exploits only a concern if Exim is installed?  Or am I mistaken?



-
   j4computers, llc
   Stone Ridge, NY 12484
845-687-3734
   www.j4computers.com
-

OT - smartmontools

[Joe Acquisto-j4]

Pardon the OT post, but looking for comments on smartmontools and 
GSmartControl, disk monitoring software.   Off list only replies are fine with 
me.  

SOT - Mimecast, blacklist

[Joe Acquisto-j4]

Sorry to post OT, but anyone having issues with mimecast?  

I  normally send via my providers mail server (Specturm aka TimeWarner).  Email 
to certain address never arrived, no bounce.   

Setup to send to their domain and/or IP  via their published  MX and 
immediately got "451 - IP temporarily blacklisted".   So far no response to my 
support query to them.

Re: different "relay" for specific domain

[Joe Acquisto-j4]

>>>> Wietse Venema <wie...@porcupine.org> 10/20/16 1:56 PM >>>
>Joe Acquisto-j4:
>> Currently have postifx configured to relay mail via a "relay_host"
>> (main.cf).   There is a need to send mail to a certain domain via
>> a different host.   Google has suggested a few ways, transport
>> hash, header filter.
>>
>> Since this special destination has a primary and a secondary IP,
>> how might I specify more than one IP for this "custom" domain?
>
>With multiple address records in DNS or /etc/hosts.  See also:
>http://www.postfix.org/postconf.5.html#smtp_host_lookup
>
>Wietse

/etc/hosts as it is a "private" domain.   A VPN is used.   I would need to 
"fall back" to the secondary, should the primary be unresponsive.  

joe a.

different "relay" for specific domain

[Joe Acquisto-j4]

Currently have postifx configured to relay mail via a "relay_host" (main.cf).   
There is a need to send mail to a certain domain via a different host.   Google 
has suggested a few ways, transport hash, header filter.

Since this special destination has a primary and a secondary IP, how might I 
specify more than one IP for this "custom" domain?   

was - ? Re: alterMIME

[Joe Acquisto-j4]

Perhaps it's time to change the subject line?

Re: alterMIME

[Joe Acquisto-j4]

>>> On 8/23/2016 at 1:16 AM, in message
<388d98f9-e63e-4d0a-865a-f32814510...@billmail.scconsult.com>, "Bill Cole"
<postfixlists-070...@billmail.scconsult.com> wrote:
> On 22 Aug 2016, at 16:14, Joe Acquisto-j4 wrote:
> 
>> Any chance of assistance here with alterMIME?
> 
> A slim chance, but it's worth a shot...
> 
>> There is a need to add disclaimers to outgoing mail.
> 
> Someone won't listen to reason, huh? That's unfortunate.

Yes.   Sad how common that is these days.

> You might try pointing them at 
> http://apps.americanbar.org/litigation/committees/technology/articles/winter 
> 2013-0213-do-email-disclaimers-really-work.html 
> but only you can judge whether pushing back is a better or worse 
> strategy in your circumstance than just doing a small bit of useless 
> work.

"You can lead a horse to water . . . "  
 
>> I have it configured (one supposes) to be complaint free on restart of 
>> postfix and can see from /var/log/mail that is does act on the 
>> specific email addresses (senders) that I intended.  At least it was 
>> processed by "filter". I am a bit puzzled that "relay" shows as 
>> "filter" for all users.   But mail does ultimately deliver via the 
>> normal route
> 
> Evidence of what exactly this all means would help make it easier to 
> help. I'd bet that most people here don't use alterMIME, but that's not 
> entirely dooming: many of us use tools that modify mail as it passes 
> through Postfix and generally speaking that works in a limited number of 
> ways. The fact that you're trying to use alterMIME specifically is not 
> as important as how you have configured Postfix to use it, what your log 
> is actually saying about the handling of messages, and what the raw 
> input and output messages look like.
> 
>> However, the received mail does not actually contain the disclaimer 
>> message. Google has not been my friend today with no results that 
>> seem to apply.
> 
> Based on these being the top "how to" hits for altermime disclaimers:
> 
> https://www.howtoforge.com/how-to-automatically-add-a-disclaimer-to-outgoing-emails-w
>  
> ith-altermime-postfix-on-debian-squeeze
> https://www.gypthecat.com/how-to-add-different-disclaimers-using-altermime-and-postf
>  
> ix-based-on-domain

Those were my "templates".   I had to dig a bit deeper to get this far.

> I'm guessing that you're using a similar setup: a script run as a pipe 
> transport due to a  content_filter directive in the smtpd line in 
> master.cf, which runs altermime on messages selectively and reinjects 
> them with sendmail. That's a bit inflexible and inefficient, but I guess 
> it would be OK for very modest volume and not needing the disclaimer on 
> mail generated on the server itself. That approach pipes *all* mail 
> arriving by SMTP into the filter script, avoiding loops because local 
> 'sendmail' submission doesn't use SMTP. This would explain why your log 
> shows all mail going to "filter".
> Assuming that guess is correct...  

It is. 

>I'd start by making sure that the 
> script that runs altermime is run by a user that can write to wherever 
> it tries to do its work. Once you confirm this isn't a permissions 
> problem (which I expect because that would likely cause no delivery at 
> all,) add diagnostic lines to the script so you can see what exactly it 
> is actually doing when it runs.
> 
> And for what it's worth: if you really must do this, consider using a 
> better tool. One option: the MIMEDefang milter. MIMEDefang is maybe 
> overkill if this is just an outbound system and you don't need robust 
> filtering capabilities, but it is a mature, actively maintained, and 
> well-documented piece of software that can manipulate MIME messages 
> correctly, including adding silly disclaimers selectively without 
> damaging message structure. As a milter, it acts on a message as it 
> passes through a Postfix smtpd process rather than as a next hop 
> transport and Postfix can be configured to also use it for non-SMTP 
> injections. 

That may be best.  I was put off by alterMIME, last touched in 2008 or so,
but there was precious little else I could find.   Overkill is OK as long as it
stays dead. 

I was concerned about "volume" as there are occasional "blasts" of messages 
that forced me to tinker
so mail flowed through faster.

>There may be other milters available strictly for adding 
> disclaimers, but I'm not aware of any.

I sure did not find any.   Thanks for your thorough response.   The MIMEDefang 
suggestion I will 
definitely follow up on.  

Well, off to the sulphur mines.

Re: alterMIME

[Joe Acquisto-j4]

>>> On 8/22/2016 at 7:31 PM, in message
<6d14c5d6-a707-499e-854b-5287d47b8...@kreme.com>, "@lbutlr"
<krem...@kreme.com>
wrote:
> On 22 Aug 2016, at 14:14, Joe Acquisto-j4 <j...@j4computers.com>
wrote:
>> There is a need to add disclaimers to outgoing mail.
> 
> Just as a point of information, I consider mail with attached
disclaimers to 
> be spam and classify them as such.
> 
> I used to post all the “Warning, this email is confidential”
emails to a 
> public web server.

Thanks for sharing.

alterMIME

[Joe Acquisto-j4]

Any chance of assistance here with alterMIME?There is a need to add 
disclaimers to outgoing mail.

I have it configured (one supposes) to be complaint free on restart of postfix 
and can see from /var/log/mail that is does act on the specific email addresses 
(senders) that I intended.  At least it was processed by "filter". I am a 
bit puzzled that "relay" shows as "filter" for all users.   But mail does 
ultimately deliver via the normal route

However, the received mail does not actually contain the disclaimer message.
 Google has not been my friend today with no results that seem to apply.

Re: relay oddity. - NP

[Joe Acquisto-j4]

>Please provide concrete evidence as requested.
>
>  Wietse

Entirely my misinterpreting what I observed.   Working as intended/expected.  
Sorry for the inconvenience and thanks for your gentle response.

Re: relay oddity.

[Joe Acquisto-j4]

First, thanks for the prompt response and please forgive the reply formatting.  
Web client is not helpful.  I will attempt to provide info as per the
links provided.

I drew my conclusion simply from watching "tail -f /var/log/mail" as I altered 
main.cf and did "rcpostfix restart"

Was that naive?

HTH.

>>>> Wietse Venema <wie...@porcupine.org> 08/18/16 10:10 AM >>>
>Joe Acquisto-j4:
>> Using postfix 2.5.6.
>> 
>> In main.cf, changed "relayhost" from and IP address to a valid domain.
> 
> - the "sender" changed from the original sender domain to the host
> name and domain of the postfix server.

What is the evidence that led you to to this conclusion? See
http://www.postfix.org/DEBUG_README.html#mail for how to report
Postfix logging.

> - the mail was shown as "queued" instead of "delivered"

What is the evidence that led you to to this conclusion? See
http://www.postfix.org/DEBUG_README.html#mail for how to report
Postfix logging.

> What can I do to retain the senders actual email address?

Why do you believe that POSTFIX changed the sender's email address?

Wietse

relay oddity.

[Joe Acquisto-j4]

Using postfix 2.5.6.

In main.cf, changed "relayhost" from and IP address to a valid domain.

- the "sender" changed from the original sender domain to the host name and 
domain of the postfix server.
- the mail was shown as "queued" instead of "delivered"

What can I do to retain the senders actual email address?

Re: 452 4.3.1 Insufficient system storage

[Joe Acquisto-j4]

Turns out, the actual number of recipients is closer to 3500 addressees.
That may be giving the server a belly full after all.

Presume the simplest way to deal is to add a disk (VM is wonderful) and tell 
postfix to use that space to it's hearts content via spool definition in 
/etc/postifx/main.cf ?

>>> "Joe Acquisto-j4" <j...@j4computers.com> 05/12/16 11:33 AM >>>
Postfix version 2.5.6 being used as a relay for chatty internal  processes.

Suddenly, one of them is complaining of this error, in the midst of a 250 ish 
recipient email.  With attachment of some size.

". . .postfix/smtpd[15953]: NOQUEUE: reject: MAIL from unknown[192.168.aa.bb]: 
452 4.3.1 Insufficient system storage; proto=ESMTP helo="

Seems this may be telling me the machine was out of disk space or a Queue was 
limited in some way, but I have about 4GB of free space.   I am attempting to 
determine the size of the mailing list from the sender, the attachment is 2MB 
or so.

Simple issue, eluding me?

452 4.3.1 Insufficient system storage

[Joe Acquisto-j4]

Postfix version 2.5.6 being used as a relay for chatty internal  processes.

Suddenly, one of them is complaining of this error, in the midst of a 250 ish 
recipient email.  With attachment of some size.

". . .postfix/smtpd[15953]: NOQUEUE: reject: MAIL from unknown[192.168.aa.bb]: 
452 4.3.1 Insufficient system storage; proto=ESMTP helo="

Seems this may be telling me the machine was out of disk space or a Queue was 
limited in some way, but I have about 4GB of free space.   I am attempting to 
determine the size of the mailing list from the sender, the attachment is 2MB 
or so.

Simple issue, eluding me?

Re: OT, where to turn?

[Joe Acquisto-j4]

 On 1/21/2015 at 10:37 PM, Viktor Dukhovni postfix-us...@dukhovni.org 
 wrote:
 On Wed, Jan 21, 2015 at 09:08:19PM -0500, Joe Acquisto-j4 wrote:
 
 This appeared to work fine and does, for most messages.  However,
 our org often sends an email to thousands of users with in our
 system.   These messages fail to forward, bounced by o365 as header
 exceeds static size limit or to that effect.
 
 The people doing mass the mailings are email-incompetent.  These
 MUST be done as Bcc.  They MUST NOT attempt to list all recipients
 in the To: or Cc: lines.
 
 Such mass mailings, if delivered, cause mail-storms when someone
 is foolish enough to Reply-Al.  And they do stress various email
 header limits.
 
 -- 
   Viktor.

Thanks. I appreciate the reminder.  The methodology is long standing
and should be altered.  The users have only the tools offered to them.

However, not trying to be argumentative at all - 

While I agree Bcc is correct, I am having difficulty accepting,
logically, not in fact,  that the forwarded message should fail.
After all, it is actually addressed to only one person. 

By analogy,  would UPS or FedEx be correct to refuse a shipment
as overweight if it consisted of an envelope empty except for a
sticky note that had 500 Lbs. written on it?

If the answer is: RFC says, I would feel the same, but have to shut up
and sit down. 

I should let it go, on this list at least.

joe a.

Re: OT, where to turn?

[Joe Acquisto-j4]

Please excuse the top post. the web client . . .

Thanks for expanding on this.

I've hacked a means of getting around this for the time being, until we
can change the addressing of the lists.   A simple fix, technically
but a cautious tradition exists.

Thanks for all the comments.

joe a.

 Viktor Dukhovni postfix-us...@dukhovni.org 01/22/15 9:59 AM 
On Thu, Jan 22, 2015 at 06:13:30AM -0500, Joe Acquisto-j4 wrote:

 While I agree Bcc is correct, I am having difficulty accepting,
 logically, not in fact,  that the forwarded message should fail.
 After all, it is actually addressed to only one person. 

The SMTP envelope is one person, but many MTAs (including the
venerable Sendmail) impose limits on the sizes of the message
headers, whether such limits are byte counts or recipient counts, ...

Postfix is more generous than many, and limits only the length of
individual logical header lines truncating them to ~100K bytes each
(Sendmail limits the entire set of headers to ~64K, perhaps 32K in
some versions).

 By analogy,  would UPS or FedEx be correct to refuse a shipment
 as overweight if it consisted of an envelope empty except for a
 sticky note that had 500 Lbs. written on it?

Your analogies are irrelevant.  MTAs process both the message
envelope and the headers, and resource limits vary.

The software doing the bulk mailings is broken, and that's the
problem you need to focus on.

Good luck.

-- 
Viktor.

Re: OT, where to turn?

[Joe Acquisto-j4]

 Daniel Miller dmil...@amfes.com 01/22/15 9:03 AM 
On 1/22/2015 3:13 AM, Joe Acquisto-j4 wrote:
 Thanks. I appreciate the reminder.  The methodology is long standing
 and should be altered.  The users have only the tools offered to them.

 However, not trying to be argumentative at all -

 While I agree Bcc is correct, I am having difficulty accepting,
 logically, not in fact,  that the forwarded message should fail.
 After all, it is actually addressed to only one person.

 By analogy,  would UPS or FedEx be correct to refuse a shipment
 as overweight if it consisted of an envelope empty except for a
 sticky note that had 500 Lbs. written on it?

 If the answer is: RFC says, I would feel the same, but have to shut up
 and sit down.

 I should let it go, on this list at least.

 joe a.



Are you asking to have a single copy of all mail forwarded to the o365 
account?  You could perhaps make use of the sender_bcc_maps and 
recipient_bcc_maps to do it behind the scenes.  Though if o365 is 
rejecting anything that has a header greater than a given size that 
wouldn't help.

Perhaps you could define a transport map for o365, that passed the 
message through a simple script that stripped the CC  BCC headers prior 
to sending it on.

--
Daniel

Anything one of the, say, 50 out of 5000, users get, should be forwarded to
their o365 account.   The lists used to create the various mass emailings
unfortunately were created addressing the members as To:

It's not the size apparently (as in bytes) despite the DSN message, it appears
to be the number of addressees in the TO: of the original message.   

I say this as I was able to successfully forward one of the failing messages 
with the same 
recipient address in the Bcc, but with a blank To:. 

I just did that on a whim, not expecting a blank To: to be accepted, somewhere 
along
the line.  Sigh.

There must be a number of work arounds, now that I have a clue.

A better analogy perhaps: it's as if the Postal Service refused to deliver an 
envelope with one
addressee because it contained another envelope with several addressees on it.  
 

Maybe it's just me.

joe a.

OT, where to turn?

[Joe Acquisto-j4]

Hope some find this amusing and not annoying.  Perhaps someone know how to 
approach this issue toward a resolution.

We have an in house commercial email system.  Due to a re-organization, a 
number of our users are now required to use an o365 account, yet must still 
receive internal messages.   To that end, I helped create internal account 
specific rules to forward all internal messages to the individual o365 
accounts.  We chose flat forward instead of as attachment. 

This appeared to work fine and does, for most messages.  However, our org often 
sends an email to thousands of users with in our system.   These messages fail 
to forward, bounced by o365 as header exceeds static size limit or to that 
effect.  I can see that there are individual messages sent out to each 
recipient, as expected, yet each is bounced.  If I forward the same message, as 
an attachment, it is not rejected.

The same flat forward, sent to non o365 systems, do not get rejected. 

The o365 team maintains this is to be expected as o365 has a limit on the 
number of recipients that can be addressed in a single email.  500. I believe.  
 I maintain they got a bug as each email is addressed to only one specific 
person, and should be interpreted that way, regardless of how may persons were 
addressed in the original header.  If that is the correct term.  The message 
envelope shows as well below their size limit.

Am I wrong?  If not, what can I pull of a hat to prove it?

restrict or alter to address based on from address

[Joe Acquisto-j4]

I confess to not having researched this, mainly as I have no clue how to search 
the subject effectively.  So, with great trepidation, I timidly squeak out this 
question:

Using postfix, is it possible to force a re-addressing of an email based on 
the sender of the message?   To expand a bit, we envision retiring an existing 
email system, migrating but a small portion of the existing message store to 
the cloud.

Yet, there will still be a need to access the old stuff and, occasionally, to 
act upon it.   So, I am looking for a way to allow such messages to be 
forwarded to the users new address (or to a surrogate, so to speak) and to no 
other.

Even better (he dares, as his courage builds), have the messages sent to only 
one recipient, say gategu...@someplace.com and have a virtual lookup table 
(loose terminology perhaps) to re-address the mail based on the sender address.

Simple?  or simple minded?

Re: restrict or alter to address based on from address

[Joe Acquisto-j4]

 On 11/18/2014 at 4:02 PM, Wietse Venema wie...@porcupine.org wrote:
I mis-stated the situation.  Allow me to attempt to restate.

There will be no address translation involved at all.  The email address both
user and domain will remain the same.   The current system will be retired 
to an off line status yet the message store will remain accessible for various
reasons, without the ability to actually send email to the outside world.

I was daydreaming about ways to get messages from the old system to the
new one, as might be required.  For a bit it seemed feasible to cobble up 
something  to allow messages to be sent via SMTP from the old system
to the new, in a controlled and highly restricted manner.

Having had some time to breath the free air again,  I'm not so sure I 
should be allowed out without my leash.

joe a.

Joe Acquisto-j4:
 I confess to not having researched this, mainly as I have no clue
 how to search the subject effectively.  So, with great trepidation,
 I timidly squeak out this question:
 
 Using postfix, is it possible to force a re-addressing of an
 email based on the sender of the message?
 
 This was not planned for as something that people would use a lot.
 
 But let's first find if this would really solve your problem.
 
 To expand a bit, we envision retiring an existing email system,
 migrating but a small portion of the existing message store to
 the cloud.

 Yet, there will still be a need to access the old stuff and,
 occasionally, to act upon it.   So, I am looking for a way to allow
 such messages to be forwarded to the users new address (or to a
 surrogate, so to speak) and to no other.
 
 My big question is why would this need to depend on the sender address?
 
 If the sender sends mail to us...@old.example.com or us...@old.example.com,
 would not it make more sense to forward the message to a destination
 that depends on the user1 and user2 parts of the recipient address?
 
 Even better (he dares, as his courage builds), have the messages
 sent to only one recipient, say gategu...@someplace.com and have
 a virtual lookup table (loose terminology perhaps) to re-address
 the mail based on the sender address.
 
 It's easy enough to forward mail for old addresses to a single
 graveyard email address:
 
 us...@old.example.com graveyard+us...@new.example.com 
 us...@old.example.com graveyard+us...@new.example.com 
 
 (this requires Postfix recipient_delimiter=+).
 
 You can list graveyard+user1, graveyard+user2, etc. in a virtual
 alias map, or you can process the addresses with procmail or with
 a script that is invoked from ~graveyard/.forward.
 
   Wietse

shellshock via SMTP?

[Joe Acquisto-j4]

Comments on the ZD net article that claims shellshock exploit via crafty SMTP 
headers?   Just asking, that's all . . . 

I attached a link to it below, please excuse if that is improper behavior.

http://www.zdnet.com/shellshock-attacks-mail-servers-735094/

Multiple relay?

[Joe Acquisto-j4]

New to list, been using postfix for a little while.

I would like to point a postfix install to two outbound relay's (all outbound 
mail to go thru them) so that, should one be unavailable, it will attempt to 
send via the other.   Not round robin but fail over.

This is probably simple, but have not found a clear description of how to.  Is 
it as simple as adding a second IP, comma separated?

Thanks.

illegal address syntax

[Joe Acquisto-j4]

Some mail from local (mynetworks) machines are getting mail rejected with 
warning: Illegal address syntax from blah in MAIL command: a b c 
This is despite resolve_numeric_domain = yes in main.cf, which I read was 
supposed to fix bad from address from scripts, etc.

Wrong?

joe a.

Re: illegal address syntax

[Joe Acquisto-j4]

Well, I can tell you it is  SuSe 10,  postfix 2.5 (mumble).   Beyond that, I 
cannot divulge much more without running afoul of local
security concerns.

The author of the reporting scripts is reluctant, but willing, to correct the 
known issues, but I was hoping for some simple change that would ignore any 
syntax problem in the from address of email, from local/trusted sources, as 
this is likely to surface again as time goes on.

Thanks for any assistance you can provide.

 li...@rhsoft.net li...@rhsoft.net 08/21/14 1:45 PM 

Am 21.08.2014 um 19:32 schrieb Joe Acquisto-j4:
 Some mail from local (mynetworks) machines are getting mail rejected with 
 warning: Illegal address syntax from blah in MAIL command: a b c 
 This is despite resolve_numeric_domain = yes in main.cf, which I read was 
 supposed to fix bad from address from scripts, etc.
 
 Wrong?

who knows since you don't post real logs
http://www.catb.org/esr/faqs/smart-questions.html#beprecise

in general: i have not seen illegal address syntax over
the last 11 years from any of my scripts or software used
inhouse and would throw away any device not fixable

Re: illegal address syntax

[Joe Acquisto-j4]

Please excuse the top posting, if that offends, as I am forced to use a web 
client that cannot bottom post.  Easily.

Here it is, only a bit obfuscated:

Aug 21 13:18:07 some_machine postfix/smtpd[23306]: warning: Illegal address 
syntax from somehost.domedomain[aa.bb.cc.dd] in MAIL command: A Web server 
Script

That's all there is on that line.  Thanks for the assistance.

joe a.

 DTNX Postmaster postmas...@dtnx.net 08/21/14 1:52 PM 
On 21 Aug 2014, at 19:32, Joe Acquisto-j4 j...@j4computers.com wrote:

 Some mail from local (mynetworks) machines are getting mail rejected with 
 warning: Illegal address syntax from blah in MAIL command: a b c 
 This is despite resolve_numeric_domain = yes in main.cf, which I read was 
 supposed to fix bad from address from scripts, etc.
 
 Wrong?

Post your actual error message, please. Your reinterpretation of it strips too 
much information.

Mvg,
Joni

Re: illegal address syntax

[Joe Acquisto-j4]

Thanks.

We understood that the white space was at least the largest part of the issue, 
but
since this setup was a replacement mail router for different mail system, 
which tolerated
the white space, we were looking to make this change over as transparent to end 
users,
even programmers, as painless as possible.   

Since we inflicted this burden on the apps community we were attempting to be as
fraternal as possible.   Seems to require a certain masochism on our part.  g

As you say, tho, there are limits.

joe a.

 Wietse Venema wie...@porcupine.org 08/21/14 2:36 PM 
Joe Acquisto-j4:
 Well, I can tell you it is  SuSe 10,  postfix 2.5 (mumble).   Beyond
 that, I cannot divulge much more without running afoul of local
 security concerns.
 
 The author of the reporting scripts is reluctant, but willing, to
 correct the known issues, but I was hoping for some simple change
 that would ignore any syntax problem in the from address of email,
 from local/trusted sources, as this is likely to surface again as
 time goes on.

Postfix tolerates many mistakes, but it won't parse an address with
unquoted whitespace. There is a limit to what I consider reasonable.

People who run Postfix 2.8 or later can use smtpd_command_filter
(http://www.postfix.org/postconf.5.html#smtpd_command_filter) to
make minor corrections before Postfix parses command input.  The
documentation shows some examples.

Something like:

/^RCPT\s+TO:([^[:space:]]+ .+)@([^[:space:]]+.*)/  RCPT TO:$1@$2

would deal with unquoted spaces in an address. One can make it more
precise if needed; that's left as an exercise for the reader.

Wietse