VERP rejected - Syntax error in FROM address
Daniel Feenberg
individual messages in a complex auto-generated mailing list, per
DJB's VERP method. 99% of the time it works, but 3 out of about a
thousand destinations claim that there is a syntax error in the from
address we provide. Here is a sample rejection:
... while talking to mailin.binghamton.edu.:
>>> MAIL
From:<bpmb+pmd-criw++ls++io++prod-rshannon+A+nb...@nber.org>
<<< 501 Syntax error in FROM address
501 5.6.0 Data format error
(NOTE: The From address may be broken into two lines in this posting -
it was a single line with no embedded whitespace in the actual
message). The total length of the From address, excluding the angle
brackets, is 92 characters, giving a line length of 99 characters -
but I wasn't aware of any limitation to the linelength for the SMTP
"MAIL FROM:" command. The dots, at sign, dashes and plus signs are the
only non-alphanumeric characters, and there is only one at sign. That
is also a valid address on our system, if it matters. This should
work, as far as I know. Are there any other restrictions on from
addresses?
An hour of experimentation hasn't led us to what the remote MTA is
complaining about. Sometimes shortening the address helps, sometimes
it doesn't. Sometimes similar but not exactly identical addresses are
accepted. If we could figure out which MTA it was, we would go to the
mailing list for that software, but even if we telnet to
mailin.binghamton.edu:25 it doesn't provide that information. A clue -
it doesn't support ENVID either.
Daniel Feenberg
feenberg at nber dotte org
Sam
> An hour of experimentation hasn't led us to what the remote MTA is
> complaining about. Sometimes shortening the address helps, sometimes
> it doesn't. Sometimes similar but not exactly identical addresses are
> accepted. If we could figure out which MTA it was, we would go to the
> mailing list for that software, but even if we telnet to
> mailin.binghamton.edu:25 it doesn't provide that information. A clue -
> it doesn't support ENVID either.
That MTA is not complaining about anything. That MTA is sitting behind some
crapware firewall whose name escapes me at the moment. The firewall
intercepts the SMTP stream and makes semi-random changes to it. The MTA is
not even receiving the SMTP command. The firewall intercepts it and munches
it, at will.
I've seen this obnoxious “firewall” (and I use the term loosely) before,
just can't remember it's name.
Mark Crispin
Both RFC 821 and RFC 2822 stipulate the maximum total length of the
local-part (the token to the left of the "@") is 64 characters. Your
example above is 84 characters.
Some servers may allow a longer local-part, but no server is obligated to
support such.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Daniel Feenberg
> > MAIL From:<bpmb+pmd-criw++ls++io++prod-rshannon+A+nb...@nber.org>
>
> Both RFC 821 and RFC 2822 stipulate the maximum total length of the
> local-part (the token to the left of the "@") is 64 characters. Your
> example above is 84 characters.
>
> Some servers may allow a longer local-part, but no server is obligated to
> support such.
>
Thanks. This must be the reason, and we can fix it easily. . It is
also plausible that an application firewall would do this to protect
the MTA from buffer overflows, but what the MTA would see in such a
case is beyond my guessing.
Actually, I was just able to confirm this restriction in RFC2821. It
isn't mentioned in RFC2822, as far as I can tell.
Thanks again.
Jonathan de Boyne Pollard
It's not an MTA. It's (apparently) a Cisco PIX firewall with the "MailGuard"
feature enabled, which has been long known to contain bugs that stop mail
transport from working.