some apparent problems with address parsing and SMTP response handling

From: Greg A. Woods (no email)
Date: Sun Oct 14 2001 - 15:13:43 EDT


I seem to have encountered some problems with the error handling in
recipient address parsing in Postfix, the fallout of which seems to also
indicated a potential (but minor) annoyance in SMTP server response
handling.

I'm using the following version on the machine I use to host my MUA:

        $ /usr/sbin/postconf mail_version
        mail_version = Postfix-20010228-pl03-NetBSD

All my e-mail is then forwarded through my network's SMTP relay (or
rather smarthost) running smail.

I made a typo when forwarding a spam complaint, typing a period where I
meant to type a comma.

The message was sent with the "sendmail -t" command-line interface.
Here are the original recipient headers I created:

        To: . ,
           ,

Here's how Postfix re-wrote them (note the dropped space!):

        To: .,
                ,
        Cc:

As a human I would have inserted a comma, and NEVER drop the space!
I guess the problem is what assumption to make when one finds there are
some valid commas already....

(not unsurprisingly even the latest Smail makes a very similar parsing
error, though oddly it seems to also strip the last "@host" from what it
sends in the RCPT TO: -- I'll have to try to fix that.... :-)

It then proceeded to hand off the resulting concatenated mess un-quoted
in the SMTP connection.

Finally even more surprisingly postfix complains when it gets a 5xx
reply to the resulting errant RCPT TO:

------- start of forwarded message (RFC 934 encapsulation) -------
From: (Mail Delivery System)
To: (Postmaster)
Subject: Postfix SMTP client: errors from mail.weird.com[204.92.254.2]

Unexpected response from mail.weird.com[204.92.254.2].

Transcript of session follows.

 In: 220-most.weird.com Smail-3.2.0.115-Pre (#2 2001-Oct-13)
 In: 220-ready at Sat, 13 Oct 2001 23:27:17 -0400 (EDT)
 In: 220 ESMTP supported
 Out: EHLO proven.weird.com
 In: 250-most.weird.com Hello proven.weird.com
     ([DBZVdI9KBPDzYWxBecyF7M34Cp8nE0WcM7NY0ze9xzUlut3QYugo67mLFQLfhVbj6wHWFCn41CIUF1Y3ZfJrfw==]@proven.weird.com
     from address [204.92.254.15]), here is what we support:
 In: 250-ENHANCEDSTATUSCODES
 In: 250-SIZE 153600
 In: 250-8BITMIME
 In: 250-PIPELINING
 In: 250-EXPN
 In: 250 HELP
 Out: MAIL FROM:<> SIZE=6490
 Out: RCPT TO:<>
 Out: RCPT TO:<>
 Out: RCPT TO:<.>
 Out: RCPT TO:<>
 Out: DATA
 In: 250 2.1.0 Sender Okay.
 In: 250 2.1.0 '<>' Recipient Okay.
 In: 250 2.1.0 '<>' Recipient Okay.
 In: 501 5.1.7 '<.>'
     address parse error: illegal character in unquoted mailbox local part.
 In: 250 2.1.0 '<>' Recipient Okay.
 In: 354 Enter mail, end with "." on a line by itself...
 Out: .
 Out: QUIT
 In: 250 2.6.0 Mail accepted, queue ID m15sbvv-000g6HC on most.weird.com.

------- end -------

There seem to be two Postfix bugs here:

1. I think the typo should have caused postfix to bounce the message
   right away and not even attempt any deliveries, though in any case it
   certainly shouldn't have tried to pass such an obviously incorrect
   parameter to RCPT TO:, so should at least have bounced for that one
   bogus address. In the end it did bounce the message because of the
   501 above:

----------------------------------------
Reporting-MTA: dns; proven.weird.com
Arrival-Date: Sat, 13 Oct 2001 23:27:17 -0400 (EDT)

Final-Recipient: rfc822; .
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host mail.weird.com[204.92.254.2] said: 501 5.1.7
    '<.>' address parse
    error: illegal character in unquoted mailbox local part.
----------------------------------------

   (and why didn't it get the "Status:" right? -- I assume it should be
   the "5.1.7" DSN value....)

2. I don't understand what the above message could possibly be
   complaining about. What, exactly, was unexpected?!?!?!?
   Surely Postfix isn't trying to interpret any more than the leading
   '5' in the '501' response! A '5' is a '5' is a '5', and that means
   "permanent error", no matter what the other digits are! ;-)

In case any of it is of any consequence (I doubt it -- I don't think I
have made any tweaks to the smtp client settings) here's my 'postconf
-n' (with tabs and other nonsensical whitespace collapsed to a single
space):

----------------------------------------
access_map_reject_code = 554
alias_database = hash:/etc/mail/aliases
alias_maps = hash:/etc/mail/aliases
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
debug_peer_level = 9
debug_peer_list = 127.0.0.1 204.92.254.2 204.92.254.18
default_destination_concurrency_limit = 10
default_privs = nobody
invalid_hostname_reject_code = 501
local_destination_concurrency_limit = 2
mail_owner = postfix
maps_rbl_domains = or.orbl.org, blackholes.mail-abuse.org, dialups.mail-abuse.org, relays.mail-abuse.org, relays.osirusoft.com, orbs.gst-group.co.uk, relays.ordb.org, inputs.orbz.org, outputs.orbz.org
maps_rbl_reject_code = 554
mynetworks = 204.92.254.0/24, 127.0.0.0/8
non_fqdn_reject_code = 504
notify_classes = protocol, resource, software
queue_directory = /var/spool/postfix
reject_code = 554
relay_domains_reject_code = 554
relayhost = mail.$mydomain
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_client_restrictions = reject_maps_rbl, reject_unknown_client
smtpd_delay_reject = no
smtpd_error_sleep_time = 5
smtpd_hard_error_limit = 100
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_unknown_client, reject_invalid_hostname, reject_unknown_hostname
smtpd_recipient_limit = 100
smtpd_recipient_restrictions = permit_mynetworks, reject_maps_rbl, reject_unknown_client, reject_unknown_recipient_domain, reject_unknown_hostname, reject_invalid_hostname, reject_unknown_sender_domain, reject_non_fqdn_hostname, reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unauth_pipelining, reject_unauth_destination, check_relay_domains
smtpd_sender_restrictions = reject_unknown_address, reject_unknown_client, hash:/etc/postfix/senders.ok, hash:/etc/postfix/senders.reject
smtpd_soft_error_limit = 10
smtpd_timeout = 300
unknown_address_reject_code = 554
unknown_client_reject_code = 550
unknown_hostname_reject_code = 554
virtual_maps = hash:/etc/postfix/virtual
----------------------------------------

-- 
							Greg A. Woods
+1 416 218-0098      VE3TCP      <>     <>
Planix, Inc. <>;   Secrets of the Weird <>
-
To unsubscribe, send mail to  with content
(not subject): unsubscribe postfix-users







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD