Malformed email addresses bring server grinding to a halt (exhaust all memory)

Mark Martinec Mark.Martinec+amavis at ijs.si
Fri Jun 29 16:56:58 CEST 2012


Ben,

> I ran into an issue recently wherein an end-user attempted to send a
> message to a few dozen recipients; normally, this is not a problem.
> 
> However, he was copy/pasting the addresses from a spreadsheet, which had
> caused superfluous single-quotes to be added INSIDE the angle brackets.
> The addresses that he pasted into the "TO" field while composing his
> email message took this form:
> 
> <'user at example.com'>
> 
> When his message was received at the mail server via Postfix, Amavis
> went absolutely berserk, for lack of a better term. Amavis's memory
> consumption skyrocketed and it consumed all available memory on the
> server, causing the server to crash.
> 
> Leading up to the crash, the Postfix log was flooded with entries like
> this (one for each recipient):
> 
> Apr  5 09:29:32 example postfix/smtpd[24176]: warning: Illegal address
> syntax from unknown[50.75.163.51] in RCPT command: <'user at example.com'>
> 
> Amavis ended-up stuck in some kind of loop, as it tried to processes
> these messages over and over.
> 
> Has anyone run into this before?
> 
> Is there some way to prevent this?
> Thanks in advance,

Which version of amavisd-new was that?

I know there were some degenerated cases of a header which caused
trouble when parsing it, so the code was rewritten back in 2007
with versions 2.5.3 and 2.5.4:

- change parsing of addresses in From, To, and Cc header fields, avoiding
  complex Perl regular expressions which could crash a process on certain
  degenerate cases of these header fields; thanks for detailed problem
  reports to Carsten Lührs and Attila Nagy;

- completely rewritten parsing of Received header field to work around a
  Perl regular expression problem which could crash a process on certain
  degenerate cases of mail header fields; problem reported by Thomas Gelf;

- harden to some extent regular expressions in parse_message_id to cope
  better with degenerate cases of header fields carrying message-id;

I'm not aware of similar problem with more recent version of amavisd-new,
I'd need to see a log at level 5 if this is the case.

  Mark

Btw, please subscribe to the list in order to be able to post there.


More information about the amavis-users mailing list