Sendmail 553 malformed address error

[Mark Bak]

I started getting a number of emails though our server that are bombing out with the 553 malformed address error. Here is an example: 553 malformed address:

I know that the "." before the "@" symbol is causing the error but I don't know how to configure the sendmail.cf file to accommodate for this error.

[Steven E. Protter]

Quick fix.

Change the Dj directive in sendmail.cf

Djhostname

Take out any dots and whatnot.

/sbin/init.d/sendmail stop
/sbin/init.d/sendmail start

This should do it.

SEP

[David Rodman]

This post raises a lot of questions for me.
Is "NPD.Survey." a legitimate username for you?
What is it that you want sendmail to do? Deliver as is, or rewrite the address?
One last (retorical) question is... Why are you trying to fix this in sendmail? (and not where the malformed address is being generated)

Go here, and read the section on localpart
http://www.cs.tut.fi/~jkorpela/rfc/822addr.html

[Mark Bak]

Sorry, I obviously did not provide enough information.
These are not valid address on our systems. They are spam from outside sources to internal email addresses.
My systems are set to relay mail only from our domains. These emails are somehow getting through and would not be relayed except they fail with the 553 error before it gets to the decide not to relay them. Anyway, I'm tired of having to deal with them. I thought there was a way to modify the sendmail.cf file in Ruleset 3 or 4 to correct for this error. Thus I would not see them anymore.

[Steven E. Protter · Accepted solution]

You should be able to modify sendmail.cf via macros in sendmail.mc to reject all mail that is not from a valid, pubically resolvable mail server.

The place to start is here, followed by research on http://www.sendmail.org and http://tldp.org and http://www.redhat.com The red hat site has some secure mail configuiration docs that should prove pretty useful to you.

There is more work in the Linux world on this than in the HP-UX world.

The good news is in late July, I'm inheriting a D320 box. The actual intent is self education, but what I plan to do for education is set up a web/mail serving doing exactly what you want to do.

Not a fast answer, but an answer none the less.

SEP

[Christopher Caldwell]

5XX series messages should generate a reject; that is your relay should never accept the mail to begin with.

If you're front-ending an internal MX, and the internal MX is rejecting the relayed mail, resulting in queued mail on the front-end server, then your access rules on the front-end are too lax.

Give us version, etc. for sendmail on the front-end host, and we can make suggestions.

[William Wong_2]

You didn't specify which version of sendmail you are running. However if you wish to block spam you might try the following changes to the sendmail ruleset:

FR-o /etc/sendmail.cR

Scheck_rcpt
# anything terminating locally is ok
R< $+ @ $=w > $@ OK
R< $+ @ $=R > $@ OK

# anything originating locally is ok
R$* $: $(dequote "" $&{client_name} $)
R$=w $@ OK
R$=R $@ OK
R$@ $@ OK

# anything else is bogus
R$* $#error $: "550 Relaying Denied"

The caveat is mail must originate or terminate locally (on this host), with exceptions made for hosts listed, one per line, in /etc/sendmail.cR. (In this incarnation, this ruleset does not allow relaying within your domain, except for the hosts listed in /etc/sendmail.cR. Note carefully, you must list fully qualified host names for each host you wish to allow relaying.

[Mark Bak]

Thanks All, since I am already using the access file to limit the relay, it should have been obvious to me to try there first. Sometimes you grab the shotgun when a fly swatter would do fine.