We also have a FAQ for this.

http://lsoft.com/manuals/lsv-faq/416CanMAILFROMonadminmailbechang.html

The blank MAIL FROM is used for administrative messages from LISTSERV that should be dropped on the floor rather than returned to sender if they bounce for any reason.  The point is to prevent a mailing loop starting up.

Blank MAIL FROM is *not* used for list postings, which have a return path of owner-something@NODE, where "something" can be a listname, or a listname and a token (i.e., for address probes).

As an anti-spam measure, blocking MAIL FROM:<> is worse than useless because it actively blocks legitimate mail that people have requested to have sent to them (like command confirmation requests).

Nathan

-----Original Message-----
From: LISTSERV Site Administrators' Forum <[log in to unmask]> On Behalf Of Dennis Boone
Sent: Monday, December 13, 2021 4:09 PM
To: [log in to unmask]
Subject: Re: Blank Mail From

 > I am installing a fresh 17.x Listserv on RHEL and I have it mostly
 > working.  One issue though is that it the listserv is not setting the
 > from address, but instead leaving it blank.  I am trying to use Sendgrid
 > as my SMTP server and they require this field to map to an approved
 > domain, which it is not.  Can anyone guide me on how to resolve this?

In my experience, LISTSERV usually just sent bounces that way.  But
Sendgrid is breaking most of the rules by rejecting such mail.

De


RFC2505 (spam prevention), section 2, recommendation 6a:

	MUST NOT refuse "MAIL From: <>".

RFC821 (SMTP), section 3.7:

	One way to prevent loops in error reporting is to specify
	a null reverse-path in the MAIL command of a notification
	message.  When such a message is relayed it is permissible
	to leave the reverse-path null.  A MAIL command with a null
	reverse-path appears as follows:

	MAIL FROM:<>

RFC2476 (message submission), section 3.2:

	Note that a null return path, that is, MAIL FROM:<>, is
	permitted and MUST be accepted. (MUAs need to generate null
	return-path messages for a variety of reasons, including
	disposition notifications.)

RFC1904 (DSN), section 2:

	The envelope sender address of the DSN SHOULD be chosen to
	ensure that no delivery status reports will be issued in
	response to the DSN itself, and MUST be chosen so that DSNs
	will not generate mail loops.  Whenever an SMTP transaction
	is used to send a DSN, the MAIL FROM command MUST use a NULL
	return address, i.e. "MAIL FROM:<>".

RFC1891 (DSN), section 7.1:

	The DSN sender address (in the SMTP MAIL command) MUST be a
	null reverse-path ("<>"), as required by section 5.3.3 of [9].
	The DSN recipient address (in the RCPT command) is copied from
	the MAIL command which accompanied the message for which the
	DSN is being issued.  When transmitting a DSN via SMTP, the RET
	parameter MUST NOT be used.  The NOTIFY parameter MAY be used,
	but its value MUST be NEVER.  The ENVID parameter (with a newly
	generated envelope-id) and/or ORCPT parameter MAY be used.

RFC1123 (requirements for internet hosts), section 5.2.9:

	The syntax shown in RFC-821 for the MAIL FROM: command omits
	the case of an empty path:  "MAIL FROM: <>" (see RFC-821
	Page 15).  An empty reverse path MUST be supported.

############################

To unsubscribe from the LSTSRV-L list:
write to: mailto:[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTSRV-L&A=1

############################

To unsubscribe from the LSTSRV-L list:
write to: mailto:[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTSRV-L&A=1