Sam Morris's questions

A recent Exim upgrade added this to the default acl_smtp_data ACL:

.ifndef NO_CHECK_DATA_VERIFY_HEADER_SYNTAX
deny
  !acl = acl_local_deny_exceptions
  !verify = header_syntax
  message = header syntax
  log_message = header syntax ($acl_verify_message)
.endif

This causes some messages to be rejected. For instance, the following header from a spam message:

2020-03-02 09:22:48 1j8hHk-0000gS-3Y H=(static-181-143-69-27.une.net.co) [181.143.69.27] F=<[email protected]> rejected after DATA: header syntax (unqualified address not permitted: failing address in "From:" header is: =?utf-8?B?IkRhbmlrYSIgPERhbmlrYUB1bmUubmV0LmNvPg==?=): unqualified address not permitted: failing address in "From:" header is: =?utf-8?B?IkRhbmlrYSIgPERhbmlrYUB1bmUubmV0LmNvPg==?=

Decoding the offending header, we get:

00000000  22 58 69 6d 65 6e 61 22  20 3c 58 69 6d 65 6e 61  |"Ximena" <Ximena|
00000010  40 76 69 6c 2e 63 6f 6d  2e 75 61 3e              |@vil.com.ua>|
0000001c

Which looks like a perfectly fine value for a From header to me.

Do I risk rejecting legitimate mail by using verify = header_syntax, or are headers such as the one above invalid and safe to reject?

I'm using Apache httpd as a reverse proxy in front of a web application. Authentication is carried out by a module (mod_auth_mellon), which sets various request environment variables with details about the authenticated user (user name, display name and so on).

I use mod_headers to remove headers from the incoming request, and replace them with the value of request environment variables that were set by mod_auth_mellon.

RequestHeader unset mellon_uid
RequestHeader set mellon_uid "%{mellon_uid}e" env=mellon_uid

Thus any client-provided mellon_uid header is thrown away. If mod_auth_mellon considers the user to be logged in then a new mellon_uid request header is added to the request that is sent onward to the web application.

So far I've made this manageable by using mod_macro:

Use Attribute uid
Use Attribute display_name
Use Attribute email

... and so on, where Attribute is a macro that expands to the two RequestHeader directives above for the provided attribute.

However, some user details are multi-valued, for which mod_auth_mellon sets multiple request environment variables of the form:

mellon_foo_0 = first
mellon_foo_1 = second
mellon_foo_2 = third
mellon_foo_N = 3

Since the number of values for an attribute can vary, I can't rely on a static list of variables to process like this.

I would like to avoid using MellonMergeEnvVars, which would instead set the following:

mellon_foo = first;second;third
mellon_foo_N = 3

... because this means the web application now has to deal with the complexity of correctly parsing the mellon_foo request header, dealing with values that themselves contain semicolons, etc. Indeed, it's not clear to me that mod_auth_mellon performs any escaping, which makes unambiguous parsing impossible (if I'm right...)

I want to make Exim perform recipient verification with a callout to the LMTP server during processing of the RCPT ACL.

I have the following router:

virtual_account:
    domains = +virtual_domains
    driver = accept
    transport = dovecot

and transport:

dovecot:
    driver = lmtp
    socket = /var/run/dovecot/lmtp

When ACL processing reaches the following statement:

warn
    domains = +virtual_domains
    verify = recipient/callout

the callout is not attempted:

$ exim -d -bhc 1.2.3.4
...
RCPT TO: [email protected]
>>> using ACL "acl_check_rcpt"
...
processing "warn"
check domains = +virtual_domains
cached yes match for +virtual_domains
cached lookup data = example.com
example.com in "+virtual_domains"? yes (matched "+virtual_domains" - cached)
check verify = recipient/callout
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Verifying [email protected]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Considering [email protected]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
routing [email protected]
...
--------> virtual_account router <--------
local_part=test domain=example.com
checking domains
cached yes match for +virtual_domains
cached lookup data = example.com
example.com in "+virtual_domains"? yes (matched "+virtual_domains" - cached)
R: virtual_account for [email protected]
calling virtual_account router
virtual_account router called for [email protected]
  domain = example.com
queued for dovecot transport: local_part = test
domain = example.com
  errors_to=NULL
  domain_data=example.com localpart_data=NULL
routed by virtual_account router
  envelope to: [email protected]
  transport: dovecot
Cannot do callout: neither router nor transport provided a host list
----------- end verify ------------
warn: condition test succeeded in ACL "acl_check_rcpt"

I guess the lmtp transport is unable to do callouts, but I'd appreciate a second opinion.

I've installed MIT Kerberos 1.10 on a Debian server and happily have my Debian clients authenticating with it. I'm having some trouble getting my Windows 7 machine to do the same, however.

I've used ksetup to configure the machine as follows:

default realm = EXAMPLE.COM (external)
EXAMPLE.COM:
        (no kdc entries for this realm)
        Realm Flags = 0x5 SendAddress Delegate
Mapping all users (*) to a local account by the same name (*).

This also changed the system's name and workgroup settings:

Computer name: lysander
Full computer name: lysander.EXAMPLE.COM
Workgroup EXAMPLE.COM

According to the documentation, if there are no KDC or password entries for a realm, Windows will use the DNS, so I also have the following entries configured:

_kerberos._udp.example.com. 300 SRV 10 100 88 kdc.example.com.
_kerberos-adm._tcp.example.com. 300 SRV 10 100 749 kdc.example.com.

kdc has an A record that points at the server's IP address.

After configuring the Windows system I rebooted it and tried to log in, noting that the login screen offered to log me into the EXAMPLE domain. However, when I attempt to log in as the local user sam, which should be mapped to [email protected], after a brief pause I am told that there are no logon servers available to service the logon request. I can't see anything relevant in the Windows event log, and having examined the network traffic between the client and the server, I can't even see that the Windows machine is trying to contact the KDC.

It's not all bad news, however. What gives me hope is that I can use runas to get a TGT:

>runas /user:[email protected] cmd
Enter the password for [email protected]:
Attempting to start cmd as user "[email protected]" ...

And in the new window that appears:

>klist

Current LogonId is 0:0x14e6649

Cached Tickets: (1)

#0>     Client: sam @ EXAMPLE.COM
        Server: krbtgt/EXAMPLE.COM @ EXAMPLE.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 2/14/2012 11:54:24 (local)
        End Time:   2/14/2012 21:54:24 (local)
        Renew Time: 2/21/2012 11:54:24 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

If I then launch PuTTY from that command prompt, I can ssh into the other servers using SSPI to authenticate just fine!

I'm not even sure if I asked that right. Anytime someone mentions changing the root password, they mention changing /etc/passwd, or just using the passwd command, but I've never heard of having to change it in an authorized_keys file as well. Where might I find that, and how can I safely delete an entry or change this for root without causing havoc? Thanks!